While taking the tram to our favourite Croatian restaurant, I spotted something dedicated to Ada. We’ll never know which one… the language, the famous programmer, or someone else. A “Maibaum” (may pole, one of its many meanings). Click on the picture to get a slightly different one which has the text better legible.
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.