debian tag cloud

Sponsored by
HostEurope Logo

debian tag cloud

All 1 2 3 4 5 6 7 8 9 10 11 12

Heartbleed vs. Startcom / StartSSL

09.04.2014 by tg@
Tags: bug debian news rant security work

First of all, good news, MirBSD is not vulnerable to The Heartbleed Bug due to my deliberate choice to stick to an older OpenSSL version. My inquiry (in various places) as to what precisely could leak when a vulnerable client connected to a nōn-vulnerable server has yet to be answered, though we can assume private key material is safe.

Now the bad news: while the CA I use¹ and a CA I don’t use offer free rekeying (in general), a CA I also use occasionally² refuses to do that. The ugly: they will not even revoke the certificates, so any attacker who gained your key, for example when you have been using a certificate of theirs on a Debian system, will be able to use it (e.g. to MITM your visitors traffic) unless you shell over lots of unreasonable money per certificate. (Someone wrote they got the fee waived, but others don’t, nor do I. (There’s also a great Twitter discussion-thingy about this involving Zugschlus, but I won’t link Twitter because they are not accessible to Lynx users like me and other Planet Debian authors.)

① I’ve been using GoDaddy privately for a while, paid for a wildcard certificate for *, and later also at work. I’ve stopped using it privately due to current lack of money.

② Occasionally, for nōn-wildcard gratis SSL certificates for HTTP servers. Startcom’s StartSSL certificates are unusable for real SSL as used in SMTP STARTTLS anyway, so usage isn’t much.

Now I’ve got a dilemma here. I’ve created a CA myself, to use with MirBSD infrastructure and things like that – X.509 certificates for my hosts (especially so I can use them for SMTP) and possibly personal friends (whose PGP key I’ve signed with maximum trust after the usual verification) but am using a StartSSL certificate for as my GoDaddy wildcard certificate expires in a week or so (due to the aforementioned monetary issues), and I’d rather not pay for a limited certificate only supporting a single vhost. There is absolutely no issue with that certificate and key (only ever generated and used on MirBSD, only using it in Apache mod_ssl). Then, there’s this soon-to-be tax-exempt non-profit society of public utility I’m working with, whose server runs Debian, and which is affected, but has been using a StartSSL certificate for a while. Neither the society nor I can afford to pay for revocation, and we do not see any possible justification for this especially in the face of CVE-2014-0160. I expect a rekey keeping the current validity end date, and would accept a revocation even if I were unable to get a new certificate, since even were we to get a certificate for the society’s domain from someplace else, an attacker could still MITM us with the previous one from Startcom.

The problem here is: I’d really love to see (all of!) Startcom dropped from the global list of trustworthy CAs, but then I’d not know from where to get a cert for MirBSD; Globalsign is not an option because I will not limit SSL compatibility to a level needed to pass their “quality” test… possibly GoDaddy, ISTR they offer a free year to Open Source projects… no idea about one for the society… but it would solve the problem of not getting the certificates revoked. For everyone.

I am giving Startcom time until Friday after $dayjob (for me); after that, I’ll be kicking them off MirBSD’s CA bundle and will be lobbying for Debian and Mozilla to do the same.

Any other ideas of how to deal with that? I’d probably pay 5 € for a usable certificate accepted by people (including old systems, such as MSIE 5.0 on Win2k and the likes) without questioning… most of the time, I only serve public content anyway and just use SSL to make the NSA’s job more difficult (and even when not I’m not dealing with any payment information, just the occasional login protected area).

By the way, is there any way to access the information that is behind a current-day link to with Lynx or Pine? I can’t help but praise GMane for their NNTP interface.

ObFunfact: just when I was finished writing this wlog entry, I got a new eMail “Special offer just for you.” from GoDaddy. Sadly, no offer for a 5 € SSL certificate, just the usual 20-35% off coupon code.

I would like to publicly apologise for the inconvenience caused by my recent updates to the mediawiki and mediawiki-extensions source packages in Debian wheezy (stable-security).

As for reasons… I’m doing Mediawiki-related work at my dayjob, as part of FusionForge/Evolvis development, and try to upstream as much as I can. Our production environment is a Debian wheezy-based system with a selection of newer packages, including MediaWiki from sid (although I also have a test system running sid, so my uploads to Debian are generally better tested). I haven’t had experience with stable-security uploads before, and made small oversights (and did not run the full series of tests on the “final”, permitted-to-upload, version, only beforehand) which led to the problems. The situation was a bit complicated by the need to update the two packages in lockstep, to fight an RC bug file/symlink conflict, which was hard enough to do in sid already, plus the desire to fix other possibly-RC bugs at the same time. I also got no external review, although I cannot blame anyone since I never asked anyone explicitly, so I accept this as my fault.

The issues with the updates are:

  • mediawiki 1.19.5-1+deb7u1 (the previous stable-security update) was not made by me but by Jonathan Wiltshire
  • mediawiki 1.19.11+dfsg-0+deb7u1 (made by me) was fine, fixed the bugs it was supposed to, but was delayed after being uploaded to security-master-unembargoed
  • mediawiki 1.19.14+dfsg-0+deb7u1 was supposed to be a mostly upstream update, but I decided to add changes to fix issues pointed out by lintian (not trivial ones), and mistakenly forgot to remove two lines that should not have crept in from sid
  • mediawiki 1.19.14+dfsg-0+deb7u2 was quickly uploaded to fix this issue but took about half a day to be ACCEPTed
  • mediawiki-extensions 3.5~deb7u1 should have be named 2.12 but could not, due to the aforementioned lockstep update requirement and version checks in maintainer scripts; it fixes the issues but does not add other changes from 3.5 in sid… unfortunately, the packaging uses cdbs (which I dislike quite a lot, but as the newcomer in the team I decided to accept it and go on; changing the existing packaging would be quite some effort anyway) and wants debian/control to be regenerated from… which I thought I had done, and normally do…
  • mediawiki-extensions 3.6 (in sid) fixes another dir/symlink conflict shown up after 3.5 was made. I’ve requested upload permission for regenerating debian/control and asked whether I am allowed to include this fix as well

My unfamiliarity with some of the packaging concepts used here, combined with this being something I do during $dayjob (which can limit the time I can invest, although I’m doing much more work on Mediawiki in Debian than I thought I could do on the job), can cause some of those oversights. I guess I also should install a vanilla wheezy environment somewhere for testing… I do not normally do stable uploads (jmw did them before), so I was not prepared for that.

And, while here: thanks to the Debian Security Team for putting up with me (also in this week’s FusionForge issue), and thanks to Mediawiki upstream for agreeing to support releases shipped in Debian stable for longer support, so we can easily do stable-security updates.


06.02.2014 by tg@
Tags: archaeology debian fun jupp pcli

Just saw this in my INBOX:

    B. The default init system for jessie will be a single /etc/rc script

I’d certainly vote that❣

In unrelated news, jupp 2.8 for DOS runs on cable3, which means it’ll still run on an original 8088/8086 ☻

Update 10.02.2014: The unobfuscated version of cable3 is called 8086tiny under the MIT licence. Thanks to the author for doing that (and not just dumping the IOCCC code) and to RT from the mksh(1) IRC channel for finding it on the ’net!

FOSDEM preparations… done.

20.01.2014 by tg@
Tags: debian event fun grml mksh twitxr work

I’ve produced several pin-on buttons to take with me to FOSDEM for giving away (as long as there are any left):

Several pin-on buttons I made

First row (nice projects), from left to right: MidnightBSD; Glenda, the Plan 9 bunny; Teckids e.V.

Second row (The MirOS Project): mksh; the Shilouette Dæmon; the “Triforce” (Live+Install CDs for i386 and sparc, with MirGrml); “the m” (alternative logo, vector)

Third row (things originating from tarent): Freedroidz (now a Teckids project); OSIAM (Identity and Access Management); tarent (tarent AG, tarent GmbH), who sponsored production of these buttons

Hm… jupp needs a button’able logo!

FOSDEM meetup


02.12.2013 by tg@
Tags: debian

I’ve did something I surely will (financially) regret, next year, and designated the Neo900 to be the successor to my PocketPC, due to the latter having only 64 MiB RAM and Geocaching applications being quite hungry. It’s got a lovely hardware keyboard, a “pen” display like the PocketPC (as opposed to the “wishy-washy” displays that Android and iPhone have), not only GPS but also GLONASS, fully free software with mostly free firmware (I’m okay with that, mostly), a Ctrl key (useful in ssh and locally and my text editor; ^I is Tab, so it’s useful in shell, too), WLAN, UMTS (I don’t think I need LTE and would rather it have the more RAM), USB host (OTG), and lots of other nice features.

In short, it’s a tinkerable device: one I can not only hack at, but also hack on.

Since I use a “dumbphone” for mobile phone anyway (pro: separate battery from the “toy” PocketPC/Smartphone – we’re talking two+ weeks of battery time when using it here, and easier use and less bugs, and a reliable fallback when I tinker “too much”), this is perfect for me.

I’m reposting this in the wlog mostly because it’s an interesting technical and OSS project, and because if 1000 people want one it will get less expensive for all of us (while here… shameless plug… any sponsors willing to contribute some EUR so I don’t ruin myself with this, in exchange for services of some kind?). I’ll probably run Debian on it (unless it goes systemd), maybe in a chroot – if the native OS has functionality needed that I can’t simply put into packages; they say Maemo has much better power management, but considering most use will have GPS, GLONASS and backlight on, battery isn’t going to last long anyway… – or maybe even native… I’ve been wanting to know what this “freesmartphone” stuff my m68k (Atari VM) buildd has been happily compiling, anyway… and some sort of Geocaching application (ideally a cross between something online, CacheWolf and an offline OSM (with most of Europe, but uninteresting tags stripped) and possibly access to the GS Live API but nevertheless supporting TC, NC, OC, gpsgames too), and my usual mksh(1), GNU screen, jupp(1), lynx(1), ssh(1) toolchain.)

Delivery is expected for mid to end of 2014, but once it’s there I’ll keep you informed ☺

On that matter… I’ve got my PocketPC (currently in production use) and another WinCE device and wonder about tinkering with them, too. It appears to be a rather open platform (compared to Android, anyway) but most official documentation is tied to Windows® host systems, and most utilities have been taken offline after the abomination called Windows Phone has taken over. Hm I’ve got PocketPython and some sort of cross GCC but nothing to tinker with the core OS / ROM image…

FrOSCon is approaching, and all MirBSD developers will attend… but why’s there no MirBSD exhibit? The answer to that is a bit complex. First let’s state that of course we will participate in the event as well as the Open Source world. We’ll also be geocaching around the campus with other interested (mostly OSS) people (including those we won for this sport) and helping out other OSS projects we’ve become attached to.

MirOS BSD, the operating system, is a niche system. The conference on the other hand got “younger” and more mainstream. This means that almost all conference visitors do not belong to the target group of MirOS BSD which somewhat is an “ancient solution”: the most classical BSD around (NetBSD® loses because they have rc.d and PAM and lack sendmail(8), sorry guys, your attempt at being not reformable doesn’t count) and running on restricted hardware (such as my 486SLC with 12 MiB RAM) and exots (SPARCstation). It’s viable even as developer workstation (if your hardware is supported… otherwise just virtualise it) but its strength lies with SPARC support and “embedded x86”. And being run as virtual machine: we’re reportedly more stable and more performant than OpenBSD. MirBSD is not cut off from modern development and occasionally takes a questionable but justified choice (such as using 16-bit Unicode internally) or a weird-looking but beneficial one (such as OPTU encoding saving us locale(1) hassles) or even acts as technological pioneer (64-bit time_t on ILP32 platforms) or, at least, is faster than OpenBSD (newer GNU toolchain, things like that), but usually more conservatively, and yes, this is by design, not by lack of manpower, most of the time.

The MirPorts Framework, while technically superiour in enough places, is something that just cannot happen without manpower. I (tg@) am still using it exclusively, continuing to update ports I use and occasionally creating new ones (mupdf is in the works!), but it’s not something I’d recommend someone (other than an Mac OSX user) to use on a nōn-MirBSD system (Interix is not exactly thriving either, and the Interix support was only begun; other OSes are not widely tested).

The MirBSD Korn Shell is probably the one thing I will be remembered for. But I have absolutely no idea how one would present it on a booth at such an exhibition. A talk is much more likely. So no on that front too.

jupp, the editor which sucks less, is probably something that does deserve mainstream interest (especially considering Natureshadow is using it while teaching computing to kids) but probably more in a workshop setting. And booth space is precious enough in the FH so I think that’d be unfair.

All the other subprojects and side projects Benny and I have, such as mirₘᵢₙcⒺ, josef stalin, FreeWRT, Lunix Ewe, Shellsnippets, the fonts, etc. are interesting but share few, if any, common ground. Again, this does not match the vast majority of visitors. While we probably should push a number of these more, but a booth isn’t “it” here, either.

MirOS Linux (“MirLinux”) and MirOS Windows are, despite otherwise-saying rumours called W*k*p*d*a, only premature ideas that will not really be worked on (though MirLinux concepts are found in mirₘᵢₙcⒺ and stalin).

As you can see, despite all developers having full-time dayjobs, The MirOS Project is far from being obsolete. We hope that our website visitors understand our reasons to not have an exhibition booth of our own (even if the SPARCstation makes for a way cool one, it’s too heavy to lift all the time), and would like to point out that there are several other booths (commercial ones, as well as OSS ones such as AllBSD, Debian and (talking to) others) and other itineries we participate in. This year both Benny and I have been roped into helping out the conference itself, too (not exactly unvoluntarily though).

The best way to talk to us is IRC during regular European “geek” hours (i.e. until way too late into the night – which Americans should benefit from), semi-synchronously, or mailing lists. We sort of expect you to not be afraid to RTFM and look up acronyms you don’t understand; The MirOS Project is not unfriendly but definitely not suited for your proverbial Aunt Tilly, newbies, “desktop” users, and people who aren’t at least somewhat capable of using written English (this is by design).

TANSTA “softlink”. ITYM: symlink(7)

Actually, there’s “link” (also “hardlink”) and “symbolic link” (short “symlink”). (Oh, and reparse points, but let’s not get there, lest we mention *.lnk files…)

Inspired by a posting on the klibc mailing list.

Following the Wiki I put “discard” entries into my fstab(5) for swap (but not / as it’s suggested to use fstrim instead, and I had noatime for /boot and relatime for / already) and changed the scheduler. What wasn’t written there was to set vm.swappiness=0 in sysctl.d/local.conf *shrug* but it helps.

What they also didn't mention:

mount -t tmpfs swap /var/cache/apt/archives

And in sid, which my dayjob-laptop is running, APT _finally_ creates the missing “partial/” subdirectory itself. Thanks!

I had the filesystems already created, so I changed the ext options with tune2fs:

tune2fs -E stride=1024,stripe_width=1024 /dev/sda2 # 1 KiB blocks: /boot
tune2fs -E stride=256,stripe_width=256 /dev/sda4   # 4 KiB blocks: /

I wonder how well that works. I also did _not_ manage to find out my device’s flash block size (search engine fodder: erase block size), so I assumed 1 MiB (also used for partition alignment already) as worst-case scenario. Input welcome on how to find *that* out.


18.07.2013 by tg@

Michael Langguth and Scalaris AG asked me to publish the mksh/Win32 Beta 14 source and binary archive, and it is with joy I’m doing this.

Checksums and Hashes

  • RMD160 (ports/ = 0dc8ef6e95592bd132f701ca77c4e0a3afe46f24
  • TIGER (ports/ = 966e548f9e9c1d5b137ae3ec48e60db4a57c9a0ed15720fb
  • 1181543005 517402 /MirOS/dist/mir/mksh/ports/
  • MD5 (ports/ = b57367b0710bf76a972b493562e2b6b5

Just a few words on it (more in the README.1st file included): this is a port of The MirBSD Korn Shell R39 to the native WinAPI; it’s not quite got the full Unix feel (especially as it targets the Weihenstephan unxutils instead of a full Interix or Cygwin environment) but doesn’t need a full POSIX emulation layer either. It’s intended to replace MKS ksh and the MKS Toolkit. Source for the compatibility library is also included under The MirOS Licence; we aim at publishing it as OSI Certified Open Source Software like mksh itself. (There is a situation with dlmalloc/nedmalloc being resolved, and the icon is derived from the BSD dæmon which is a protected unregistered trademark, but we’re not Mozilla and allow distro packages to keep using it ☺) Rebasing it on a newer mksh(1) followed by (partial) integration into the main source code is a goal.

Have fun trying it out and hacking on it. It’s currently built with -DMKSH_NOPROSPECTOFWORK (so coprocesses and a few other minor things won’t work), but a SIGCHLD emulation is being worked on – but if you want to help out, I’m sure it’s welcome, just come on IRC or post on the mailing list, and I’ll forward things to Michael as needed. Reports on testing with other toolchain and OS versions are also welcome.


07.07.2013 by tg@
Tags: debian fun


Time for more neighbours’ cat posts, apparently. It’s warm, so the cat’s sleeping outside. Not disturbed by much.

Me envious. Too warm to go to the ice salon (bike’s in repair, car’s hot enough to boil eggs on it, public transport not better).

virsh send-key guestname KEY_LEFTALT KEY_SYSRQ KEY_H

This doesn’t work in virt-manager, but the virsh CLI tool is just fine.

PS: zerofree rocks! And can be installed in Grml 2011.05 just finely.

Okay, so imagine this: you just generated an SSH RSA key and threw its public part on system B into ~foo/.ssh/authorized_keys and its private part on system A into ~bar/.ssh/id_rsa but can’t login. Why?

Automated processes (Jenkins *cough*) often need you to ssh(1) manually once, to accept the remote host’s server key. Do that.

The id_rsa file on system A must be owned by the user bar and chmod 0600 or 0400 (similarily, the .ssh directory has strict permission checks, and everything in the path until there). Check those.

And, the most surprising one of the day: if there’s an it will be used for offering a key to the remote host (B) even if it does not match the secret key. Deleting A:~bar/.ssh/ apparently makes OpenSSH generate the public part from the secret key each time (or just put the correct pubkey there), but if one’s there, it seems to like to use them. (That was the only part of this post that was news to even me, of course ☺)

And, as bottom line: hello to Planet Debian from “mirabilos at work”, too. I’ll occasionally tag posts so they show up here, if I think they’re of interest, since I’m doing Debian work at the dayjob, too.

All 1 2 3 4 5 6 7 8 9 10 11 12

MirOS Logo