I was out, seeing something that wasn’t there yet when I was at school (the “web” was not ubiquitous, back then), and decided to have a look:
Ugh. Oh well, PocketIE doesn’t provide a “View Source” thingy, so I asked Natureshadow (who got the same result on his Android, and had no “View Source” either apparently, so he used cURL to see it). We saw (here, re-enacted using ftp(1)):
tg@blau:~ $ ftp -Vo - http://www.draitschbrunnen.de/ <!-- pageok --> <!-- managed by puppet --> <html> <pre>pageok</pre> </html>
This is the final straw… after puppet managed to trash a sudoers(5) at work (I warned people to not introduce it) now it breaks websites. ☺
(Of course, tools are useful, but at best to the skill of their users. Merely dumbly copying recipes from “the ’net” without any understanding just makes debugging harder for those of us with skills.)
ObQuestion: Does anyone have ⓐ a transcript (into UTF-8)
and ⓑ a translation for the other half of the OpenBSD
2.8 poster? (I get asked this regularily.)
Update: One person sent me the Kanji and Kana for it in UTF-8 「俺のマシンに手を出すな！」, and they and one more person told me it’s “Hands off my machine!” or “Don’t lay a hand on my machine!”. Now I’m not studying Japanese, but it LGTM in FixedMisc [MirOS], and JMdict from MirPorts says: ore no mashin ni te (w)o dasu na (roughly: my machine; particle; hands; particle; put out; prohibition) ☺ Thanks all, now I know what to tell visitors who wonder about that poster on my wall.
ObTip: I can install a few hundred Debian VMs at work manually before the effort needed to automate d-i would amortise. So I decided not to. Coworkers are shocked. I keep flexibility (can decide to have machines differ), and the boss accepts my explanations. Think before doing automation just for the sake of automation!
I’ve been only sleeping, cooking and geocaching this weekend. Rather productive. Better than being angry at idiots, slowpokes (StartCom and Mozilla in particular), etc.
Food was rather tasty, although I held back and put only ten pieces of garlic into it; gecko2 added some Pul Biber to his…
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 *.mirbsd.org, 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 www.mirbsd.org 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 groups.google.com 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 control.in… 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.
ObRant: DST (Sommerzeit) sucks!
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❣
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!
As a workaround to the build problem of mksh R49 with some host shells, you can try removing every sequence of backslash + newline in rlimits.opt and sh_flags.opt, for example with the following sequence:
cd /path/to/mksh for f in *.opt; do tr '\n' '`' <"$f" | \ sed 's/\\`//g' | \ tr '`' '\n' >"$f.out" mv "$f.out" "$f" done
This will apply to every upcoming mksh(1) release until such time as this code has been rewritten in (host) C. Another thing that could be done is to add -r to both IFS= read line occurences in Build.sh, function do_genopt.
Meh. I announced a tree breaker. Would be nice if I actually found enough spare time to hack on it before, I think, end of March (which is roughly when I’m planning to decommission both eurynome and, for monetary reasons (not going to do an OpenBSD here and cry about needing funds, as those who know me know this is a constant), the manitu server).
Took me 62 minutes to write a functioning OSIAM installer in mksh(1) after getting annoyed that the Puppet-lovers are either ill, not able to work on the project I have to finish by Friday, or not yet skilled enough to help. Got the entire thing working (but this week sees way too many overlong days at the workplace), estimate finishing with full success by tomorrow afternoon, with zero puppet but lots of mksh. Maintainable, too.
I’ve produced several pin-on buttons to take with me to FOSDEM for giving away (as long as there are any left):
Hm… jupp needs a button’able logo!
Thanks to Robert Scheck, jupp – the Editor which sucks less (a WordStar™-compatible Unix editor with lots of features, including a hex editor) is currently on its way to Fedora and EPEL (RHEL/CentOS 5 and 6).
Depending on your distribution, you will have it available within one to two weeks, I’m being told.
This adds another distribution to the list; jupp has been available in Debian and its derivates (some of which may not be named) for some time (due to user request), and the webpage contains Win32 binaries (made with Cygwin, an oldish version to be compatible to Win9x).
jupp is especially useful as programmers’ editor, but also used in teaching school-aged kids the joys of IT; Natureshadow has prepared a cheat sheet, which we will internationalise and localise, then link from the jupp homepage – so stay tuned! (I guess we’ll also need a concise list of jupp features, in lieu of advertising.)
There has been an ongoing discussion in the NetBSD community about migrating away from CVS (something that is not in question here, I know I know)—to the point that the tech-repository mailing list has been set up specifically for this discussion.
Eric S. Raymond recently posted an article titled "bzr is dying; Emacs needs to move" on emacs-devel. Thomas Klausner remarked that if you apply sed -e "s/emacs/NetBSD/g" -e "s/bzr/CVS/g" to the post, then the same applies, frighteningly accurate in fact:
In practice, I judge that sticking with CVS would have social and signaling effects damaging to NetBSD's prospects. Sticking to a moribund version-control system will compound and exacerbate the project's difficulty in attracting new talent.
The uncomfortable truth is that many younger hackers already think CVS is a dinosaur – difficult, bulky, armor-plated, and generally stuck in the last century. If we're going to fight off that image, we cannot afford to make or adhere to choices that further cast the project as crusty, insular, and backward-looking.
This is what I wrote in reply:
Scary how spot-on this is after the above substitution. I fully agree.
I know that this may spawn another centithread but: how about we use a "canary" for a VCS migration? For example, moving pkgsrc-wip to git would probably be trivial, considering that it's sourceforge that hosts it. Last time I checked, sourceforge supports hosted git repositories.
As a new data point, I did some hacking on pkgsrc on MirBSD during 30c3 using a clone of github.com/jsonn/pkgsrc. This was in part to work around the freeze, in part to see how git copes with the typical pkgsrc workflows. I was positively surprised, I must say. Some observations:
- you want distfiles/ and packages/ in gitignore.
- not ignoring work directories is actually a convenient way to find stale work directories quickly.
- downgrading a single package (in my case, to get autoconf-2.61 for some configure script) is easy to do, using git checkout $revision devel/autoconf This set the working copy back to the given revision and put the changes to HEAD into the index.
- branch/rebase/merge is a good workflow for upgrading single packages.
Thus, even if the NetBSD project is not prepared to move to git outright, we could do a move for pkgsrc-git, then pkgsrc. src could come later.
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…