Link: A Child’s Garden of Inter-Service Authentication Schemes
A Child’s Garden of Inter-Service Authentication Schemes is an opinionated overview of service to service authentication schemes from Latacora (via, which has comments worth reading for once, including from various Latacora people). As with pretty much everything Latacora writes on their blog, it's not just informative, it's entertaining too. I find it well worth reading.
Link: About the memory management in the Bourne shell
About the memory management in the Bourne shell (via) is a collection of discussions about the original Bourne shell's creative, interesting, and infamous approach to memory management in the original Unix memory allocation scheme. If you like this kind of thing, it's worth reading through and decoding things.
(It also links to a recording of Stephen Bourne's BSDCan 2015 talk "Early days of Unix and design of sh", which I haven't watched yet but keep seeing links to. Someday.)
The mess Ubuntu 18.04 LTS has made of libreadline
I'll start with my tweet:
I see that Ubuntu still hasn't provided libreadline6 for Ubuntu 18.04 LTS, despite that being the default and best readline to compile against on both 16.04 LTS and 14.04 LTS. Binaries that work across LTS versions? Evidently we can't have that.
Even the new expanded Twitter is too little space to really explain things for people who don't already have some idea of what I'm talking about, so let's expand that out.
Let's suppose that you've built yourself a program that uses GNU Readline on an Ubuntu 14.04 or Ubuntu 16.04 machine (perhaps a custom shell). You have a mixed environment, with common binaries used across multiple hosts (for example, because you have NFS fileservers). When you try to run this program on Ubuntu 18.04, here is what will happen:
<program>: error while loading shared libraries: libreadline.so.6: cannot open shared object file: No such file or directory
What is going on here (besides there being no libreadline.so.6 on
Ubuntu 18.04) is that shared libraries on Linux have a version,
which is the digit you see after the
.so, and programs are linked
against a specific version of each shared library. This shared
library version number changes if the library's ABI changes so that
it wouldn't be safe for old programs to call the new version of the
library (for example because a structure changed size).
The standard Ubuntu (and Debian) naming scheme for shared library packages is that 'libreadline6' is the Ubuntu package for version 6 of libreadline (ie for libreadline.so.6). So you would normally fix this problem on Ubuntu 18.04 by installing the 18.04 version of libreadline6. Unfortunately no such package exists, which is the problem.
Over the years, Ubuntu has packaged various versions of GNU Readline. Of the still supported LTS releases, 14.04 and 16.04 ship libreadline5 and libreadline6, while Ubuntu 18.04 ships libreadline5 and libreadline7 and does not have libreadline6. So, can you build a program on 14.04 or 16.04 so that it uses libreadline5, which would perhaps let you run it on 18.04? Unfortunately you can't even do this, as 14.04 and 16.04 only let you build programs that use libreadline6.
(The libreadline-dev package on 14.04 and 16.04 installs libreadline6-dev, and there is no libreadline5-dev.)
The reason Debian and Ubuntu package multiple versions of GNU Readline is for backwards compatibility, so that programs compiled on older versions of the distribution, using older versions of the shared library, will still run on the new version. That's why libreadline5 is packaged even on 18.04. But this time around, Ubuntu apparently decided to throw GNU Readline backwards compatibility to 14.04 and 16.04 under the bus for some reason, or perhaps they just didn't bother to check and notice despite the fact that this should be a routine check when putting an Ubuntu release together (especially an LTS one).
If you're in this situation, the good news is that there is a simple
manual fix. Just download a suitable binary
.deb of libreadline6
by hand (for example from the 16.04 package) and install it
on your 18.04 system. This appears to work fine and hasn't blown
up on us yet. If you have a lot of 18.04 systems to install, you
probably want to add this to your install automation. Perhaps
someday you'll be able to take it out in favour of installing the
official Ubuntu 18.04 version of libreadline6, but based on the
current state of affairs I wouldn't hold my breath about that.
(There are various standard Ubuntu programs that use GNU Readline,
/usr/bin/ftp. However, they're all specific to the
particular Ubuntu release and so they all use its GNU Readline
version, whatever that is; on 18.04, they all use libreadline7.
Should you copy the 16.04
ftp binary over to an 18.04 machine
you'd have this problem with it too, but there's very little reason
to do that; 18.04 comes with its own version of
ftp, after all.)
PS: Ubuntu's Launchpad.net is such a mess that I can't even tell if this has been reported as a bug. Oh, apparently this is probably the right page, and also it looks like no such bug has been filed. It's sad that I could only find it by the 'Bug Reports' link on the packages.ubuntu.com page for it.