Developers’ Weblog

Sponsored by
HostEurope Logo

Developers’ Weblog

All 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

A surprise to see my box booting up with the default GRUB 2.x menu, followed by “cannot find a working init”.

What happened?

Well, grub:i386 and grub:x32 are distinct packages, so APT helpfully decided to purge the GRUB config. OK. Manual boot menu entry editing later, re-adding “GRUB_DISABLE_SUBMENU=y” and “GRUB_CMDLINE_LINUX="syscall.x32=y"” to /etc/default/grub, removing “quiet” again from GRUB_CMDLINE_LINUX_DEFAULT, and uncommenting “GRUB_TERMINAL=console”… and don’t forget to “sudo update-grub”. There. This should work.

On the plus side, nvidia-driver:i386 seems to work… but not with boinc-client:x32 (why, again? I swear, its GPU detection has been driving me nuts on >¾ of all systems I installed it on, already!).

On the minus side, I now have to figure out why…

tglase@tglase:~ $ sudo ifup -v tap1
Configuring interface tap1=tap1 (inet)
run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
run-parts: executing /etc/network/if-pre-up.d/bridge
run-parts: executing /etc/network/if-pre-up.d/ethtool
ip addr add 192.168.0.3/255.255.255.255 broadcast 192.168.0.3   peer 192.168.0.4  dev tap1 label tap1
Cannot find device "tap1"
Failed to bring up tap1.

… this happens. This used to work before the cktN kernels.

Bernhard’s article on Plänet Debian about the “colon” command in the shell could use a clarification and a security-relevant correcture.

There is, indeed, no difference between the : and true built-in commands.

Stéphane Chazelas points out that writing : ${VARNAME:=default} is bad, : "${VARNAME:=default}" is correct. Reason: someone could preset $VARNAME with, for example, /*/*/*/*/../../../../*/*/*/*/../../../../*/*/*/* which will exhaust during globbing.

Besides that, the article is good. Thanks Bernhard for posting it!

PS: I sometimes use the colon as comment leader in the last line of a script or function, because it, unlike the octothorpe, sets $? to 0, which can be useful.

Update: As jilles pointed out in IRC, “colon” (‘:’) is a POSIX special built-in (most importantly, it keeps assignments), whereas “true” is a regular built-in utility.

Munzee-Plazierungen

03.12.2014 by tg@
Tags: geocache

Wenn ich meine Geocaches so „genau“ ausmessen würde wie die Munzees hier in der Ecke sind, würden mir wütende Finder die Bude einrennen…

Und wieso überhaupt kann ich in der Ähpp ein DNF als Logtyp auswählen, aber beim Sync sagt er dann, ginge nicht? (NM geht. Note sollte auch.)

Alles in allem: besser als Ingress (nicht schwer…), aber ähnlich stromfressend; nerviger als Geocaching (die Ähpp ist auch furchtbar lahm). Und: it’s all about the numbers, aber teilt sich bei mir nunmal mit anderen GPS-Spielen die Statistik…

Wußtest Du schon, daß eine Abzweigung (eine andere Straße oder sogar auch nur ein Feldweg) dadurch markiert wird, daß sie zwischen Pöllern mit orangefarbenen statt weißen Reflektoren steht?

(tg@ continuing…) Nein, wußte ich nicht, aber jetzt wo Du’s sagst… danke! Hilfreich! Daß die Pöller links wie ein Doppelpunkt und rechts wie ein senkrechter Strich geformt sind wußte ich immerhin schon. Ja, kann mir vorstellen, daß es bei der Navigation im Schnee hilft. Nein, in der Fahrschule hörte ich dies, und so manches anderes, nicht… komme mir im Nachhinein betrogen vor…

RNG for MirBSD and subprojects

29.11.2014 by tg@
Tags: plan

Feel free to ignore those semi-unsorted ramblings of mine, they are unfinished, not binding, notes of plans that may come if I ever learn 影分身の術 (Kage Bunshin no Jutsu) or bilocality…

We currently have arc4random(9) in the kernel and arc4random(3) in userspace. We also have the urandom(4) stuff, but nobody should use them really. OpenBSD simplified theirs, but lost functionality like arc4random_addrandom(3) during that. I complicated ours, to get e.g. arc4random_pushb_fast(3), and for using userspace as additional pools, but that grew complex too, and few applications really add to their state other than using it anyway.

My idea thus far is to begin with those applications. That would be mksh(1) and ntpd(8) only, AFAICT. On the basis of the recently Spritz, an aRC4 successor with great sponge properties, I plan on creating s4random, which could serve their specific needs: an output state Spritz (like arc4random has); an input Spritz (which corresponds to the arc4random_roundhash) tweaked to have, every time Shuffle() is called by the absorption functions, four bytes sent to a BAFH state from Drip(); that 32-bit state is then used to randomly drop from the output state (in addition to a value from the output state itself like arc4random uses) for faster feedback (think state recovery attacks). The output state can then be seeded less often but in larger blocks, taking from the input state as well as arc4random(3) or sysctl(3) KERN_ARND or OpenBSD getentropy() or Linux getrandom() or /dev/urandom, with the usual pushback. It could also need only 16 bytes instead of 128/256 bytes from the kernel on such calls (possibly lowering the a4s_count equivalent for the first two trips). It would also need to work on lesser operating systems, so it can probably have a function to determine seed status (2 = third trip, kernel entropy; 1 = first or second trip, or Win32 CryptGenRandom; 0 = untrusted). Also consider skipping initialisation by hardcoding one at compile time, facilitated through Mirtoconf v2. (Also, reducing the maximum Squeeze() parameter to 64 before random dropping engages, instead of 256, makes sense. The BAFH state also needs feedback from the output state…)

Then, I could simplify MirBSD libc arc4random(3) as all other applications than those mentioned above (and maybe libcrypto, but that’s a special case anyway) don’t need this sort of fast feedback loop. I’ve not yet planned that part out. – Finally, the kernel may or may not adopt Spritz but I’ve got ideas wrt. that, faster feedback loops, less overhead for interrupt handlers, etc. as well. This can wait a bit, as Spritz is still very new, so I’d prefer to not lower the security level accidentally, but it can be prototyped for something eventually ending up in ntpd(8) where it has low impact, and mksh, where the MirJSON and Mirkev code will need it.

OpenSSL’s libcrypto is another case. Just using arc4random(3) now has effectively reduced its state size from about 8184 bit to about 1700 bit of aRC4 state while a Spritz state has about 1476‒1604 bit. Of course, it reads from the kernel, which doesn’t offer more anyway, and people say about security levels, but there’s still always EGD and, more importantly, ~/.rnd (or RANDFILE to be exact). So, an upscaling solution is needed, too, but I can construct one, similar to how arc4random_roundhash is comprised of 32 32-bit BAFH states with appropriate (but slow) mixing. But that’s specific to MirBSD anyway, and can take time.

Meh. Reminds me, I probably should add getentropy() before upgrading OpenSSH to a version doing the sandboxing. And let arc4random(3) use the new MAP_INHERIT_ZERO stuff; at least minherit(2) throws EINVAL as safe fallback but it still requires updating the kernel first. But then it has been there for months already.

d-i preseeding is not the answer

25.11.2014 by tg@
Tags: debian rant work

This post details what the d-i team currently shows as the only way.

It has several shortcomings and one missing documentation part.

Shortcoming: --purge is missing from the apt-get invocation. This leaves packages in “rc” state (requiring a manual dpkg --purge to completely remove them later, as they are then invisible to apt).

Worse shortcoming: this still leaves all dependencies pulled in by systemd around on the system, because packages installed by debootstrap are not eligible for “apt-get --purge autoremove”. Additionally, it does not influence debootstrap’s (nōn-existent, see #557322, #668001, #768062) dependency resolver, leading to possibly pessimistic package selections.

Missing: you can just hit Alt-F2 and enter the command…

	in-target apt-get --purge -y install sysvinit-core
 

… there, no need to preseed. But this does not eliminate the aforementioned shortcomings, of course.

Another PSA: something surprising about XML.

As you might all know, XML must be valid UTF-8 (or UTF-16 (or another encoding supported by the parser, but one which yields valid Unicode codepoints when read and converted)). Some characters, such as the ampersand ‘&’, must be escaped (“&#38;” or “&#x26;”, although “&amp;” may also work, depending on the domain) or put into a CDATA section (“<![CDATA[&]]>”).

A bit surprisingly, a literal backspace character (ASCII 08h, Unicode U+0008) is not allowed in the text. I filed a bugreport against libxml2, asking it to please encode these characters.

A bit more research followed. Surprisingly, there are characters that are not valid in XML “documents” in any way, not even as entities or in CDATA sections. (xmlstarlet, by the way, errors out somewhat nicely for an unescaped literal or entity-escaped backspace, but behaves absolutely hilarious for a literal backspace in a CDATA section.) Basically, XML contains a whitelist for the following Unicode codepoints:

  • U+0009
  • U+000A
  • U+000D
  • U+0020‥U+D7FF
  • U+E000‥U+FFFD
  • U-00010000‥U-0010FFFF

Additionally, a certain number of codepoints is discouraged: U+007F‥U+0084 (IMHO wise), U+0086‥U+009F (also wise, but why allow U+0085?), U+FDD0‥U+FDEF (a bit surprisingly, but consistent with disallowing the backspace character), and the last two codepoints of every plane (U+FFFE and U+FFFF were already disallowed, but U-0001FFFE, U-0001FFFF, …, U-0010FFFF weren’t; this is extremely wise).

The suggestion seems to be to just strip these characters silently from the XML “document”.

I’m a bit miffed about this, as I don’t even use XML directly (I’m extending a PHP “webapplication” that is a SOAP client and talks to a Java™ SOAP-WS) and would expect this to preserve my strings, but, oh my. I’ve forwarded the suggestion to just strip them silently to the libxml2 maintainers in the aforementioned bug report, for now, and may even hack that myself (on customer-paid time). More robust than hacking the PHP thingy to strip them first, anyway – I’ve got no control over the XML after all.

Sharing this so that more people know that not all UTF-8 is valid in XML. Maybe it saves someone else some time. (Now wondering whether to address this in my xhtml_escape shell function. Probably should. Meh.)

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

We already edit /etc/tomcat7/server.xml after installing the tomcat7 Debian package, to get it to talk AJP instead of HTTP (so we can use libapache2-mod-jk to put it behind an Apache 2 httpd, which also terminates SSL):

We already comment out the block…

    <Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               URIEncoding="UTF-8"
               redirectPort="8443" />

… and remove the comment chars around the line…

    <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />

… so all we need to do is edit that line to make it look like…

    <Connector address="127.0.0.1" port="8009" protocol="AJP/1.3" redirectPort="8443" />

… and we’re all set.

(Your apache2 vhost needs a line JkMount /?* ajp13_worker and everything Just Works™ with the default configuration.)

Now, tomcat7 is only accessible from localhost (Legacy IP), and we don’t need to firewall the AJP (or HTTP/8080) port. Do make sure your Apache 2 access configuration works, though ☺

Debian is a bit like a school class…

09.10.2014 by tg@
Tags: personal rant

… which has never quite taken you as-is, bordering bullying maybe, and has now made up rules to include some new kids, using these as excuse to bully you around even more. You stay the outsider, having tried to struggle along for a while, except of course when they want to copy off your homework. Or, as happened to me, during a Maths test, with carbon paper. Then you're thanked for a short while, and after some time, you're alone again.

… except, it all happened in the city, not in the internet, which happily multiplies negative voices and likes to take things out of context, especially if part of the context was in private mail or other threads or long buried (closed as ignored/WONTFIX) bugreports.

Of course, some sorts of misbehaviour are okay, as long as those who do toe the party line ‒ and aren't outcast, to start with.

I still pride myself as independent thinker and like to play the devil's advocate rule (heh, double entendree, being a BSD person). Critically looking at something new has led to lots of tys moments. If people listened to my criticism in the first place, effort could have been saved.

It seems to be an anglo-american-australian thing, putting political correctness in expressions over real niceness. And the opinion about cursing, in general. And this SJW thing. You know, a good friend is someone who you can be silent with, while being happy together. One whom you can insult, be it in jest or in anger, and still stay friends.

And look at those newcomers! Shiny, with makeup that promises faster boot times (eh? I fail to see how this is relevant in a Unix…) and all that. But these superficial people, always jumping from one thing (HAL, consolekit) to the next, giving up their own projects which they forced upon others the minute before ‒ no consistency.

I'm too old for this shit. Ignore my rambling. Couldn't sleep.

I just installed, for work, Hanno Böck’s bashcheck utility on our monitoring system, and watched all¹ systems go blue.

① All but two. One is not executing remote scripts from the monitoring for security reasons, the other is my desktop which runs Debian “sid” (unstable).

(Update, 2014-10-20: jessie, precise, trusty are also green now.)

This means that all those distributions still have unfixed #shellshock bugs.

  • lenny (with Md’s packages): bash (3.2-4.2) = 3.2.53(1)-release
    • CVE-2014-6277 (lcamtuf bug #1)
  • squeeze (LTS): bash (4.1-3+deb6u2) = 4.1.5(1)-release
    • CVE-2014-6277 (lcamtuf bug #1)
  • wheezy (stable-security): bash (4.2+dfsg-0.1+deb7u3) = 4.2.37(1)-release
    • CVE-2014-6277 (lcamtuf bug #1)
    • CVE-2014-6278 (lcamtuf bug #2)
  • jessie (testing): bash (4.3-10) = 4.3.27(1)-release
    • CVE-2014-6277 (lcamtuf bug #1)
    • CVE-2014-6278 (lcamtuf bug #2)
  • sid (unstable): bash (4.3-11) = 4.3.30(1)-release
    • none
  • CentOS 5.5: bash-3.2-24.el5 = 3.2.25(1)-release
    • extra-vulnerable (function import active)
    • CVE-2014-6271 (original shellshock)
    • CVE-2014-7169 (taviso bug)
    • CVE-2014-7186 (redir_stack bug)
    • CVE-2014-6277 (lcamtuf bug #1)
  • CentOS 5.6: bash-3.2-24.el5 = 3.2.25(1)-release
    • extra-vulnerable (function import active)
    • CVE-2014-6271 (original shellshock)
    • CVE-2014-7169 (taviso bug)
    • CVE-2014-7186 (redir_stack bug)
    • CVE-2014-6277 (lcamtuf bug #1)
  • CentOS 5.8: bash-3.2-33.el5_10.4 = 3.2.25(1)-release
    • CVE-2014-6277 (lcamtuf bug #1)
  • CentOS 5.9: bash-3.2-33.el5_10.4 = 3.2.25(1)-release
    • CVE-2014-6277 (lcamtuf bug #1)
  • CentOS 5.10: bash-3.2-33.el5_10.4 = 3.2.25(1)-release
    • CVE-2014-6277 (lcamtuf bug #1)
  • CentOS 6.4: bash-4.1.2-15.el6_5.2.x86_64 = 4.1.2(1)-release
    • CVE-2014-6277 (lcamtuf bug #1)
  • CentOS 6.5: bash-4.1.2-15.el6_5.2.x86_64 = 4.1.2(1)-release
    • CVE-2014-6277 (lcamtuf bug #1)
  • lucid (10.04): bash (4.1-2ubuntu3.4) = 4.1.5(1)-release
    • CVE-2014-6277 (lcamtuf bug #1)
  • precise (12.04): bash (4.2-2ubuntu2.5) = 4.2.25(1)-release
    • CVE-2014-6277 (lcamtuf bug #1)
    • CVE-2014-6278 (lcamtuf bug #2)
  • quantal (12.10): bash (4.2-5ubuntu1) = 4.2.37(1)-release
    • extra-vulnerable (function import active)
    • CVE-2014-6271 (original shellshock)
    • CVE-2014-7169 (taviso bug)
    • CVE-2014-7186 (redir_stack bug)
    • CVE-2014-6277 (lcamtuf bug #1)
    • CVE-2014-6278 (lcamtuf bug #2)
  • trusty (14.04): bash (4.3-7ubuntu1.4) = 4.3.11(1)-release
    • CVE-2014-6277 (lcamtuf bug #1)
    • CVE-2014-6278 (lcamtuf bug #2)

I don’t know if/when all distributions will have patched their packages ☹ but thought you’d want to know the hysteria isn’t over yet…

… however, I hope you were not stupid enough to follow the advice of this site which suggests you to download some random file over the ’net and execute it with superuser permissions, unchecked. (I think the Ruby people were the first to spread this extremely insecure, stupid and reprehensible technique.)

Updates:

  • rsc points out that CentOS only supports 5.«latest» and 6.«latest», and paying RHEL get 5.«x».«y» but only occasionally. We updated one of the two systems in question and shut the other down due to lack of use.
  • trusty (14.04): bash (4.3-7ubuntu1.5) = 4.3.11(1)-release
    • none
  • Yes, comments on this blog are disabled; mail t.glaser@tarent.de for feedback.
  • Since I was asked (twice): the namespace patches by Florian Weimer protect from most exploits. The bugs are, nevertheless, present:
    root@debian-wheezy:~ # env 'BASH_FUNC_foo()=() { x() { _; }; x() { _; } <<'"$(perl -e '{print "A"x1000}'); }" bash -c :
    Segmentation fault
    139|root@debian-wheezy:~ # dmesg | tail -1
    [3121102.362274] bash[1699]: segfault at dfdfdfdf ip 00000000f766df36 sp 00000000ffe90b34 error 4 in libc-2.13.so[f75ee000+15d000]
     
  • To one eMail sender: If you do not understand why a CGI or something else could invoke a shell, or what a segmentation fault trap is, do not bother me. Especially not in that tone.
  • To another eMail sender: Yes, quantal is end of life. It’s also upgraded. First and last time I ever used *buntu’s “do-release-upgrade”. Broke kernel and GRUB, and upgraded to saucy. I manually “apt-get --purge dist-upgrade”d to trusty (went surprisingly well).
  • precise (12.04): bash (4.2-2ubuntu2.6) = 4.2.25(1)-release
    • none
  • jessie (testing): bash (4.3-11) = 4.3.30(1)-release
    • none
  • Update 27.10.2014: Clearly, distributions are not fixing the lcamtuf bug series (Debian stable, CentOS), believing that the affix patch makes them invulnerable, while it just removes the most common/popular/exposed attack vector. Sad story.

Thanks to ↳ tarent for letting me do this work during $dayjob time!

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.

All 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

MirOS Logo