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

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


  • 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 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[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.

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.

git rebase is problematic (from a version control system user point of view) because it rewrites history. We all knew that.

But did you know that git pull --rebase, commonly used before a git push, can also be harmful, destroy history, and surprise users in a negative way?

10:08⎜<Beuc:#fusionforge> Lo-lan-do, we must have committed at the same time :)  First time I rebase and my commit disappear ;)
10:11⎜«Lo-lan-do:#fusionforge» So who won?
10:11⎜«Lo-lan-do:#fusionforge» Aha, I did :-)

This does fit git’s model of managing patches and tracking content, but is just irresponsible for a version control system. (Also, imagine incensed contributors whose commits just vanish.) So, danger, beware of using git rebasing when you use git as distributed version control system!

In a related way: merge commits are good. Especially when merging between, into or from feature branches. (A friend had his .gitconfig set up to default to rebasing… ugh.) So there should have been one place where you used rebase: to avoid merge commits when people work on the same repository at the same time (but, ideally, on different files). Those were mostly annoying. But, as you can see above, the alternatives are even worse…

mksh R50b released

03.09.2014 by tg@
Tags: mksh news pcli

The MirBSD Korn Shell has got a new bugfix release. Thought you’d want to know ☺

Okay. I just created three events at tomorrow 10:00 CEST (08:00 UTC), on three different accounts on the very same Debian Lenny machine. All three use nxclient to log into KDE 3, with Kontact/KDEPIM Version 1.2.9 (enterprise35 20131030.a834355).

Then, I looked at the event invitations (METHOD:REQUEST BEGIN:VEVENT) in a simple eMail program (alpine). What I got made me beg to differ:





I should mention that I created the events at roughly 13:45 CEST today (11:45 UTC), and the system timezone on the box as well as the “Time & Date” zone in the Kontact settings are all “Europe/Berlin”.

To add insult to injury: the calendar view on the accounts that created the event all do show it for tomorrow, 10:00 local time.

I cannot possibly imagine how this could go wrong, seeing as those are all on the same machine…

WTF is going on here?

Update: .kde/share/config/korganizerrc had TimeZoneId wrong. I had to change a different timezone (such as Europe/Bratislava), hit the OK button, confirm to “Keep Times”, then re-open the settings dialogue and change back to Europe/Berlin, for it to work.

mksh R50, jupp 27 released

29.06.2014 by tg@
Tags: jupp mksh news pcli

Both the MirBSD Korn Shell and jupp – the editor which sucks less have seen new releases today. Please test them, report all bugs, and otherwise enjoy all the bugfixes.

Other subprojects will also have new releases… once I get around doing so after hacking them…

Update 03.07.2014: New release for MirCPIO, that is, cpio(1) and pax(1) and tar(1) in a somewhat portable package.

-r--r--r-- 4 tg miros-cvssrc 141973 Jul 3 19:56 /MirOS/dist/mir/cpio/paxmirabilis-20140703.cpio.gz

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


21.05.2014 by tg@
Tags: personal rant

Mein Friseur hat zugemacht. Jetzt versuche ich seit Wochen, einen neuen zu finden. Der sollte aufhaben, wenn ich von der Arbeit komme. Technisch beëinflußt suche ich zunächst im Netz… aber liebe Leute, ich will keine 20 € und mehr ausgeben und dafür beim Friseur Kaffee aus einer Saeco trinken (das mache ich auf Arbeit kostenlos), oder für 36 € das 40-Minuten-Wellness-Paket mit irgendwelchen abgedrehten Pflegen haben oder von Promi-Friseuren beackert werden.

Ich will einfach nur nen verdammten normalen sommerlichen Kurzhaarschnitt, für ein Dutzend Quakes, ggfs. ein paar mehr, gern auch mit Rasur. Und zwar abends so zwischen 18 und 19 Uhr, oder samstags am späten (lies: 14 Uhr) Vormittag, wenn ich halbwegs wach bin.
Ist das denn so schwer?

(Okay, die meisten haben vermutlich keine Webseite. Aber wie findet man die? Und die zwei mit einer Facebook- aber keiner Webseite kommen, habe ich extra von der Arbeit aus nachgesehen, auch nicht in Frage.)


More on the Vim thing

20.05.2014 by tg@
Tags: tip

As an update to the issue with Vim not treating a file as UTF-8 Benny wrote about earlier, there’s more to note:

  • The file in question contained two lines that were copied from the Other BSD, which were not UTF-8. This probably led to Vim not wanting to treat the entire file as UTF-8. (This is not normally a problem in vi(1), AFAIK (but in nvi in Debian, which truncates the file on write, with no way to recover), and jupp even has mixed-encoding files as a primary use case.)
  • When treating the file as UTF-8 forcefully, which Benny used, the file was saved with the offending bytes replaced by question marks (which was discovered by me in cvs(1) diff(1), leading to a fix and this post-mortem analysis)

This is apparently something every editor user should know about. Another lesson learned: run $VCS diff before committing!

And something for me to take from this: check file encodings when importing from poorer OSes, and in general.

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