From: Colin Watson Date: Tue, 27 Aug 2019 05:55:40 +0000 (+0100) Subject: man-db 2.8.7 X-Git-Url: https://www.chiark.greenend.org.uk/ucgi/~cjwatson/git?a=commitdiff_plain;h=3f74c6f718eb56098116c98ebf479d81a4bd2d56;p=blog.git man-db 2.8.7 --- diff --git a/content/man-db-2.8.7.md b/content/man-db-2.8.7.md new file mode 100644 index 00000000..ae9d53f2 --- /dev/null +++ b/content/man-db-2.8.7.md @@ -0,0 +1,49 @@ +Title: man-db 2.8.7 +Slug: man-db-2.8.7 +Date: 2019-08-27 06:55:25 +01:00 +Category: man-db +Tags: man-db, planet-debian, planet-ubuntu + +I've released man-db 2.8.7 +([announcement](https://lists.nongnu.org/archive/html/man-db-announce/2019-08/msg00002.html), +[NEWS](http://git.savannah.gnu.org/cgit/man-db.git/tree/NEWS?id=2.8.7)), +and uploaded it to Debian unstable. + +There are a few things of note that I wanted to talk about here. Firstly, I +made some further improvements to the seccomp sandbox originally introduced +in 2.8.0. I do still think it's correct to try to confine subprocesses this +way as a defence against malicious documents, but it's also been a pretty +rough ride for some users, especially those who use various kinds of VPNs or +antivirus programs that install themselves using `/etc/ld.so.preload` and +cause other programs to perform additional system calls. As well as a few +specific tweaks, a [recent discussion on +LWN](https://lwn.net/Articles/796108/) reminded me that it would be better +to make seccomp return `EPERM` rather than raising `SIGSYS`, since that's +easier to handle gracefully: in particular, it fixes [an odd corner case +related to glibc's nscd handling](https://bugs.debian.org/902257). + +Secondly, there was a [build failure on +macOS](https://savannah.nongnu.org/bugs/?56734) that took a while to figure +out, not least because I don't have a macOS test system myself. In 2.8.6 I +tried to make life easier for people on this platform with a [`CFLAGS` +tweak](https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=056e8c7c012b00261133259d6438ff8303a8c36c), +but I made it a bit too general and accidentally took away configure's +ability to detect undefined symbols properly, which caused very confusing +failures. More importantly, I hadn't really thought through why this change +was necessary and whether it was a good idea. man-db uses private shared +libraries to keep its executable size down, and it passes `-no-undefined` to +`libtool` to declare that those shared libraries have no undefined symbols +after linking, which is necessary to build shared libraries on some +platforms. But the `CFLAGS` tweak above directly contradicts this! So, +instead of playing core wars with my own build system, I did some +refactoring so that the assertion that man-db's shared libraries have no +undefined symbols after linking is actually true: this involved [moving +decompression code out of +`libman`](https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=2519d2ffe769a4059bfe475a092afa40722eb38d), +and arranging for the code in `libmandb` to take the database path as a +parameter rather than as a global variable (something I've meant to fix for +ages anyway; +[252d7cbc23](https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=252d7cbc2328b27457aafcbd6fa5958a8be9fded), +[036aa910ea](https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=036aa910ea000d716bcf0f4bcbcee3a54a848be7), +[a97d977b0b](https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=a97d977b0bfc1ed34c3021b8d6702b047e8251af)). +Lesson: don't make build system changes you don't quite understand.