debian tag cloud

Sponsored by
HostEurope Logo

debian tag cloud

All 1 2 3 4 5 6 7 8 9

Apparently (the actual results have not yet been published by the Secretary), the GR is over, and the worst possible option has won. This is an absolutely ambiguous result, while at the same time sending a clear signal that Debian is not to be trusted wrt. investing anything into it, right now.

Why is this? Simply: “GR not required” means that “whatever people do is probably right”. Besides this, we have one statement from the CTTE (“systemd is default init system for jessie. Period.”) and nothing else. This means that runit, or upstart, or file-rc, or uselessd, can be the default init system for zurg^H^H^H^Hstretch, or even the only one. It also means that the vast majority of Debian Developers are sheeple, neither clearly voting to preserve freedom of choice between init systems for its users, nor clearly voting to unambiguously support systemd and progress over compatibility and choice, nor clearly stating that systemd is important but supporting other init systems is still recommended. (I’ll not go into detail on how the proposer of the apparently winning choice recommends others to ignore ftpmaster constraints and licences, and even suggests to run a GR to soften up the DFSG interpretation.) I’d have voted this as “no, absolutely not” if it was possible to do so more strongly.

Judging from the statistics, the only thing I voted above NOTA/FD is the one least accepted by DDs, although the only other proposal I considered is the first-rated of them: support for other init systems is recommended but not required. What made me vote it below NOTA/FD was: “The Debian Project makes no statement at this time on sysvinit support beyond the jessie release.” This sentence made even this proposal unbearable, unacceptable, for people wanting to invest (time, money, etc.) into Debian.

Update: Formal result announced. So 358 out of 483 voting DDs decided to be sheeple (if I understand the eMail correctly). We had 1006 DDs with voting rights, which is a bit ashaming as well. That’s 48.01% only. I wonder what’s worse.

This opens up a very hard problem: I’m absolutely stunned by this and wondering what to do now. While there is no real alternative to Debian at $dayjob I can always create customised packages in my own APT repository, and – while it was great when those were eventually (3.1.17-1) accepted into Debian, even replacing the previous packages completely – it is simpler and quicker to not do so. While $dayjob benefits from having packages I work on inside Debian itself, even though I cannot always test all scenarios Debian users would need, some work reduction due to… reactions… already led to Debian losing out on Mediawiki for jessie and some additional suffering. With my own package repository, I can – modulo installing/debootstrap – serve my needs for $dayjob much quicker, easily, etc. and only miss out on absolutely delightful user feedback. But then, others could always package software I’m upstream of for Debian. Or, if I do not leave the project, continue doing so via QA uploads.

I’m also disappointed because I have invested quite some effort into trying to make Debian better (my idea to join as DD was “if I’ve got to use it, it better be damn good!”), into packaging software and convincing people at work that developing software as Debian packages instead of (or not) thinking of packaging later was good. I’ve converted our versions of FusionForge and d-push to Debian packages, and it works pretty damn well. Sometimes it needs backports of my own, but that’s the corportate world, and no problem to an experienced DD. (I just feel bad we ($orkplace) lost some people, an FTP master along them, before this really gained traction.)

I’d convert to OpenBSD because, despite MirBSD’s history with them, they’re the only technically sound alternative, but apparently tedu (whom I respect technically, and who used to offer good advice to even me when asked, and who I think wouldn’t choose systemd himself) still (allying with the systemd “side” (I’m not against people being able to choose systemd, for the record, I just don’t want to be forced into it myself!)) has some sort of grudge against me. Plus, it’d be hard to get customers to follow. So, no alternative right now. But I’m used to managing my own forks of software; I’m doomed to basically hack and fix anything I use (I recently got someone who owns a licence to an old-enough Visual Studio version to transfer that to me, so I can hack on the Windows Mobile 6 version of Cachebox, to fix bugs in one of the geocaching applications I use. Now I “just” need to learn C# and the .NET Compact Framework. So I’m also used to some amount of pain.)

I’m still unresolved wrt. the attitude I should show the Debian project now. I had decided to just continue to live on, and work on the things I need done, but that was before this GR non-result. I absolutely cannot recommend anyone to “invest” into Debian (without sounding hypocriet), but I cannot recommend anything else either. I cannot justify leaving but don’t know if I want to stay. I think I should sleep over it.

One thing I promised, and thus will do, is to organise a meeting of the Debian/m68k people soonish. But then, major and important and powerful forces inside Debian still insist that Debian-Ports are not part of it… [Update: yes, DSA is moving it closer, thanks for that by the way, but that doesn’t mean anything to certain maintainers or the Release Team, although, the latter is actually understandable and probably sensible.] yet, all forks of Debian now suffer from the systemd adoption in it instead of having a freedom-of-choice upstream. I’ve said, and I still feel that systemd adoption should have done in a Debian downstream / (pure?) blend, and maybe (parts of) GNOME removed from Debian itself for it. (Adding cgroups support to the m68k kernel to support systemd was done. I adviced against it, on the grounds of memory and code size. But no downstream can remove it now.)

On a closing note: an Ewok told me I should not be surprised because of my communication style on the mailing lists. I just got private mails telling me that, indeed, I’ve been more civilised recently, plus I’ve not started out as aggressively as it became in the end of the heated systemd debate (with this GR result, I precisely lost what I had feared), plus I’ve hung on Usenet for too long… and I’m sometimes terse when I don’t want to repeat the, for me, same topic once again (I’ve usually looked at the things before and decided they’re just another hype, and know from experience to avoid them). So I feel this should not be held against me. Listen to advice, please. (I’m also somewhat shocked by certain people asserting systemd is “unavoidable”, now.)

mksh R50d released

07.10.2014 by tg@
Tags: bug debian mksh news pcli

The last MirBSD Korn Shell update broke update-initramfs because I accidentally introduced a regression in field splitting while fixing other bugs – sorry!

mksh R50d was just released to fix that, and a small NULL pointer dereference found by Goodbox on IRC. Thanks to my employer tarent for a bit of time to work on it.

mksh R50c released, security fix

03.10.2014 by tg@
Tags: android bug debian mksh news pcli release security

The MirBSD Korn Shell has got a new security and maintenance release.

This release fixes one mksh(1)-specific issue when importing values from the environment. The issue has been detected by the main developer during careful code review, looking at whether the shell is affected by the recent “shellshock” bugs in GNU bash, many of which also affect AT&T ksh93. (The answer is: no, none of these bugs affects mksh.) Stephane Chanzelas kindly provided me with an in-depth look at how this can be exploited. The issue has not got a CVE identifier because it was identified as low-risk. The problem here is that the environment import filter mistakenly accepted variables named “FOO+” (for any FOO), which are, by general environ(7) syntax, distinct from “FOO”, and treated them as appending to the value of “FOO”. An attacker who already had access to the environment could so append values to parameters passed through programs (including sudo(8) or setuid) to shell scripts, including indirectly, after those programs intended to sanitise the environment, e.g. invalidating the last $PATH component. It could also be used to circumvent sudo’s environment filter which protected against the vulnerability of an unpatched GNU bash being exploited.

tl;dr: mksh not affected by any shellshock bugs, but we found a bug of our own, with low impact, which does not affect any other shell, during careful code review. Please do update to mksh R50c quickly.

Dear FSF, stop recommending Enigmail.

05.06.2014 by tg@
Tags: debian pcli rant security tip work

Dear FSF, stop recommending Enigmail, please. It is broken, simple as that. Even if you switch everything HTML-related off, it still defaults to the latin9 (ISO-8859-15) encoding instead of UTF-8, and possibly some other nasties. Worse, it’s based upon obsolete Thunderbird/Icedove technology, which is dead since the release of Firefox® 17 and will only degrate over time.

Side note: I was asked recently how much entropy is used while generating a PGP key using GnuPG on Windows®, after having done the same for OpenSSL on Debian (and possibly almost all other OSes). I had to try to find out which was the actual code (GnuPG 2 with libgcrypt, it turns out), and it was not pretty. (You are hereby adviced to create a 600-byte file ${GNUPGHOME:-~/.gnupg}/random_seed from a good source before even attempting to use GnuPG 2 for the first time. OK, you can run gpg -k once, to create the GNUPGHOME directory from a skeleton.)

I’m holding a Debian packaging workshop for our trainees at work tomorrow, and have prepared a sample package for a simple PHP web application (just a handful of files) with DB connection (PostgreSQL of course), automatic setup via dbconfig-common, and with support for both Apache 2.2 (wheezy, precise) and Apache 2.4 (jessie/sid), configuration-wise. (It is possible to install this without Apache, just it does not configure the webserver then.) Schema updates on software updates are also tested (there is neither Flyway nor Liquibase – which are the tools we use at work for this, other than Roland Mas’ wonderful scripts for FusionForge – in Debian, but to my delight I discovered that dbconfig-common can also do this).

Comments, suggestions, flames, etc. welcome. I know that this should not be a native package, and will address this tomorrow, but I wanted something that serves as decent example for how to do this easily, Policy conformant and using modern techniques (even those I dislike myself – for the sake of simplicity).

Permission was granted by the business administration to reproduce this all under a BSD-style licence, so, enjoy sharing!

Thanks to Roland Mas, for making FusionForge such a nice project, and Arno Töll for some instant IRC help on the Apache side of this.

This is my first time using dbconfig-common, and now, I finally feel I know enough to finish the packaging of Kivitendo which I’ve started earlier. Beta testers for that welcome, too.

(And next week or so, I’ll need this for a Maven thingy. I’ll probably opt out on the DB side, there, though. Never did anything with that, either, not being a Java™ guy. I guess something web to go with tomcat7… anyone got this already?)

Lügen haben lange Leitern

13.05.2014 by tg@
Tags: debian fun politics rant twitxr

Photo von Laternenmast mit Wahlplakaten, oben Pro NRW, unten…

Endlich tut mal jemand was gegen die rechte Hetzpartei! – Ein Arbeitskollege fragt, ob man die nicht einfach mit einem langen Heckenschneider abmachen kann… aber sie so lächerlich zu machen hat auch was ☺

Finally, someone is doing something against this Nazi party! A coworker wondered whether it’s legal to cut them off with a long tool, but making them ridiculous like this is also funny ☻

(Explanation: the “Pro NRW” people put their campaign thingies (sorry, I don’t speak English well) up on lamp posts very high, because they are taken down by other citizens immediately otherwise, so there’s now people making fun of them for using long ladders (to put them up there, so the offended citizens need equally long ladders or tools with long arms) in leaning on the saying that lies have long legs ⇒ here: ladders.)

Maibaum für Ada

04.05.2014 by tg@
Tags: debian fun twitxr

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.

Ada-Maibaum

Stay off my computer, puppet!

18.04.2014 by tg@
Tags: bug debian fun geocache pcli rant tip work

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:

pageok

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!

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 *.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.

KISS

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

All 1 2 3 4 5 6 7 8 9

MirOS Logo