I Use This!
Activity Not Available

News

Analyzed 3 months ago. based on code collected about 6 years ago.
Posted about 2 years ago
TL;DR: procmail is a security liability and has been abandoned upstream for the last two decades. If you are still using it, you should probably drop everything and at least remove its SUID flag. There are plenty of alternatives to chose from, and ... [More] conversion is a one-time, acceptable trade-off. Procmail is unmaintained procmail is unmaintained. The "Final release", according to Wikipedia, dates back to September 10, 2001 (3.22). That release was shipped in Debian since then, all the way back from Debian 3.0 "woody", twenty years ago. Debian also ships 25 uploads on top of this, with 3.22-21 shipping the "3.23pre" release that has been rumored since at least the November 2001, according to debian/changelog at least: procmail (3.22-1) unstable; urgency=low * New upstream release, which uses the `standard' format for Maildir filenames and retries on name collision. It also contains some bug fixes from the 3.23pre snapshot dated 2001-09-13. * Removed `sendmail' from the Recommends field, since we already have `exim' (the default Debian MTA) and `mail-transport-agent'. * Removed suidmanager support. Conflicts: suidmanager (<< 0.50). * Added support for DEB_BUILD_OPTIONS in the source package. * README.Maildir: Do not use locking on the example recipe, since it's wrong to do so in this case. -- Santiago Vila Wed, 21 Nov 2001 09:40:20 +0100 All Debian suites from buster onwards ship the 3.22-26 release, although the maintainer just pushed a 3.22-27 release to fix a seven year old null pointer dereference, after this article was drafted. Procmail is also shipped in all major distributions: Fedora and its derivatives, Debian derivatives, Gentoo, Arch, FreeBSD, OpenBSD. We all seem to be ignoring this problem. The upstream website (http://procmail.org/) has been down since about 2015, according to Debian bug #805864, with no change since. In effect, every distribution is currently maintaining its fork of this dead program. Note that, after filing a bug to keep Debian from shipping procmail in a stable release again, I was told that the Debian maintainer is apparently in contact with the upstream. And, surprise! they still plan to release that fabled 3.23 release, which has been now in "pre-release" for all those twenty years. In fact, it turns out that 3.23 is considered released already, and that the procmail author actually pushed a 3.24 release, codenamed "Two decades of fixes". That amounts to 25 commits since 3.23pre some of which address serious security issues, but none of which address fundamental issues with the code base. Procmail is insecure By default, procmail is installed SUID root:mail in Debian. There's no debconf or pre-seed setting that can change this. There has been two bug reports against the Debian to make this configurable (298058, 264011), but both were closed to say that, basically, you should use dpkg-statoverride to change the permissions on the binary. So if anything, you should immediately run this command on any host that you have procmail installed on: dpkg-statoverride --update --add root root 0755 /usr/bin/procmail Note that this might break email delivery. It might also not work at all, thanks to usrmerge. Not sure. Yes, everything is on fire. This is fine. In my opinion, even assuming we keep procmail in Debian, that default should be reversed. It should be up to people installing procmail to assign it those dangerous permissions, after careful consideration of the risk involved. The last maintainer of procmail explicitly advised us (in that null pointer dereference bug) and other projects (e.g. OpenBSD, in [2]) to stop shipping it, back in 2014. Quote: Executive summary: delete the procmail port; the code is not safe and should not be used as a basis for any further work. I just read some of the code again this morning, after the original author claimed that procmail was active again. It's still littered with bizarre macros like: #define bit_set(name,which,value) \ (value?(name[bit_index(which)]|=bit_mask(which)):\ (name[bit_index(which)]&=~bit_mask(which))) ... from regexp.c, line 66 (yes, that's a custom regex engine). Or this one: #define jj (aleps.au.sopc) It uses insecure functions like strcpy extensively. malloc() is thrown around gotos like it's 1984 all over again. (To be fair, it has been feeling like 1984 a lot lately, but that's another matter entirely.) That null pointer deref bug? It's fixed upstream now, in this commit merged a few hours ago, which I presume might be in response to my request to remove procmail from Debian. So while that's nice, this is the just tip of the iceberg. I speculate that one could easily find an exploitable crash in procmail if only by running it through a fuzzer. But I don't need to speculate: procmail had, for years, serious security issues that could possibly lead to root privilege escalation, remotely exploitable if procmail is (as it's designed to do) exposed to the network. Maybe I'm overreacting. Maybe the procmail author will go through the code base and do a proper rewrite. But I don't think that's what is in the cards right now. What I expect will happen next is that people will start fuzzing procmail, throw an uncountable number of bug reports at it which will get fixed in a trickle while never fixing the underlying, serious design flaws behind procmail. Procmail has better alternatives The reason this is so frustrating is that there are plenty of modern alternatives to procmail which do not suffer from those problems. Alternatives to procmail(1) itself are typically part of mail servers. For example, Dovecot has its own LDA which implements the standard Sieve language (RFC 5228). (Interestingly, Sieve was published as RFC 3028 in 2001, before procmail was formally abandoned.) Courier also has "maildrop" which has its own filtering mechanism, and there is fdm (2007) which is a fetchmail and procmail replacement. But procmail, of course, doesn't just ship procmail; that would just be too easy. It ships mailstat(1) which we could probably ignore because it only parses procmail log files. But more importantly, it also ships: lockfile(1) - conditional semaphore-file creator formail(1) - mail (re)formatter lockfile(1) already has a somewhat acceptable replacement in the form of flock(1), part of util-linux (which is Essential, so installed on any normal Debian system). It might not be a direct drop-in replacement, but it should be close enough. formail(1) is similar: the courier maildrop package ships reformail(1) which is, presumably, a rewrite of formail. It's unclear if it's a drop-in replacement, but it should probably possible to port uses of formail to it easily. The real challenge is, of course, migrating those old .procmailrc recipes to Sieve (basically). I added a few examples in the appendix below. You might notice the Sieve examples are easier to read, which is a nice added bonus. Conclusion There is really, absolutely, no reason to keep procmail in Debian, nor should it be used anywhere at this point. It's a great part of our computing history. May it be kept forever in our museums and historical archives, but not in Debian, and certainly not in actual release. It's just a bomb waiting to go off. It is irresponsible for distributions to keep shipping obsolete and insecure software like this for unsuspecting users. Note that I am grateful to the author, I really am: I used procmail for decades and it served me well. But now, it's time to move, not bring it back from the dead. Appendix Previous work It's really weird to have to write this blog post. Back in 2016, I rebuilt my mail setup at home and, to my horror, discovered that procmail had been abandoned for 15 years at that point, thanks to that LWN article from 2010. I would have thought that I was the only weirdo still running procmail after all those years and felt kind of embarrassed to only "now" switch to the more modern (and, honestly, awesome) Sieve language. But no. Since then, Debian shipped three major releases (stretch, buster, and bullseye), all with the same vulnerable procmail release. Then, in early 2022, I found that, at work, we actually had procmail installed everywhere, possibly because userdir-ldap was using it for lockfile until 2019. I sent a patch to fix that and scrambled to remove get rid of procmail everywhere. That took about a day. But many other sites are now in that situation, possibly not imagining they have this glaring security hole in their infrastructure. Procmail to Sieve recipes I'll collect a few Sieve equivalents to procmail recipes here. If you have any additions, do contact me. All Sieve examples below assume you drop the file in ~/.dovecot.sieve. deliver mail to "plus" extension folder Say you want to deliver [email protected] to the folder foo. You might write something like this in procmail: MAILDIR=$HOME/Maildir/ DEFAULT=$MAILDIR LOGFILE=$HOME/.procmail.log VERBOSE=off EXTENSION=$1 # Need to rename it - ?? does not like $1 nor 1 :0 * EXTENSION ?? [a-zA-Z0-9]+ .$EXTENSION/ That, in sieve language, would be: require ["variables", "envelope", "fileinto", "subaddress"]; ######################################################################## # wildcard +extension # https://doc.dovecot.org/configuration_manual/sieve/examples/#plus-addressed-mail-filtering if envelope :matches :detail "to" "*" { # Save name in ${name} in all lowercase set :lower "name" "${1}"; fileinto "${name}"; stop; } Subject into folder This would file all mails with a Subject: line having FreshPorts in it into the freshports folder, and mails from alternc.org mailing lists into the alternc folder: :0 ## mailing list freshports * ^Subject.*FreshPorts.* .freshports/ :0 ## mailing list alternc * ^List-Post.*mailto:.*@alternc.org.* .alternc/ Equivalent Sieve: if header :contains "subject" "FreshPorts" { fileinto "freshports"; } elsif header :contains "List-Id" "alternc.org" { fileinto "alternc"; } Mail sent to root to a reports folder This double rule: :0 * ^Subject: Cron * ^From: .*root@ .rapports/ Would look something like this in Sieve: if header :comparator "i;octet" :contains "Subject" "Cron" { if header :regex :comparator "i;octet" "From" ".*root@" { fileinto "rapports"; } } Note that this is what the automated converted does (below). It's not very readable, but it works. Bulk email I didn't have an equivalent of this in procmail, but that's something I did in Sieve: if header :contains "Precedence" "bulk" { fileinto "bulk"; } Any mailing list This is another rule I didn't have in procmail but I found handy and easy to do in Sieve: if exists "List-Id" { fileinto "lists"; } This or that I wouldn't remember how to do this in procmail either, but that's an easy one in Sieve: if anyof (header :contains "from" "example.com", header :contains ["to", "cc"] "[email protected]") { fileinto "example"; } You can even pile up a bunch of options together to have one big rule with multiple patterns: if anyof (exists "X-Cron-Env", header :contains ["subject"] ["security run output", "monthly run output", "daily run output", "weekly run output", "Debian Package Updates", "Debian package update", "daily mail stats", "Anacron job", "nagios", "changes report", "run output", "[Systraq]", "Undelivered mail", "Postfix SMTP server: errors from", "backupninja", "DenyHosts report", "Debian security status", "apt-listchanges" ], header :contains "Auto-Submitted" "auto-generated", envelope :contains "from" ["nagios@", "logcheck@", "root@"]) { fileinto "rapports"; } Automated script There is a procmail2sieve.pl script floating around, and mentioned in the dovecot documentation. It didn't work very well for me: I could use it for small things, but I mostly wrote the sieve file from scratch. Progressive migration Enrico Zini has progressively migrated his procmail setup to Sieve using a clever way: he hooked procmail inside sieve so that he could deliver to the Dovecot LDA and progressively migrate rules one by one, without having a "flag day". See this explanatory blog post for the details, which also shows how to configure Dovecot as an LMTP server with Postfix. Other examples The Dovecot sieve examples are numerous and also quite useful. At the time of writing, they include virus scanning and spam filtering, vacation auto-replies, includes, archival, and flags. Harmful considered harmful I am aware that the "considered harmful" title has a long and controversial history, being considered harmful in itself (by some people who are obviously not afraid of contradictions). I have nevertheless deliberately chosen that title, partly to make sure this article gets maximum visibility, but more specifically because I do not have doubts at this moment that procmail is, clearly, a bad idea at this moment in history. Developing story I must also add that, incredibly, this story has changed while writing it. This article is derived from this bug I filed in Debian to, quite frankly, kick procmail out of Debian. But filing the bug had the interesting effect of pushing the upstream into action: as mentioned above, they have apparently made a new release and merged a bunch of patches in a new git repository. This doesn't change much of the above, at this moment. If anything significant comes out of this effort, I will try to update this article to reflect the situation. I am actually happy to retract the claims in this article if it turns out that procmail is a stellar example of defensive programming and survives fuzzing attacks. But at this moment, I'm pretty confident that will not happen, at least not in scope of the next Debian release cycle. [Less]
Posted about 2 years ago
After many months of hard work by the good people involved in LinuxCNC, the system was accepted Sunday into Debian. Once it was available from Debian, I was surprised to discover from its popularity-contest numbers that people have been reporting ... [More] its use since 2012. Its project site might be a good place to check out, but sadly is not working when visiting via Tor. But what is LinuxCNC, you are probably wondering? Perhaps a Wikipedia quote is in place? "LinuxCNC is a software system for numerical control of machines such as milling machines, lathes, plasma cutters, routers, cutting machines, robots and hexapods. It can control up to 9 axes or joints of a CNC machine using G-code (RS-274NGC) as input. It has several GUIs suited to specific kinds of usage (touch screen, interactive development)." It can even control 3D printers. And even though the Wikipedia page indicate that it can only work with hard real time kernel features, it can also work with the user space soft real time features provided by the Debian kernel. The source code is available from Github. The last few months I've been involved in the translation setup for the program and documentation. Translators are most welcome to join the effort using Weblate. As usual, if you use Bitcoin and want to show your support of my activities, please send Bitcoin donations to my address 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b. [Less]
Posted about 2 years ago
In February I was assigned 16 hours of work by Freexian's Debian LTS initiative and carried over 8 hours from January. I worked 16 hours, and will carry over the remaining time to March. I spent most of my time triaging security ... [More] issues for Linux, working out which of them were fixed upstream and which actually applied to the versions provided in Debian 9 "stretch". I also rebased the Linux 4.9 (linux) package on the latest stable update, but did not make an upload this month. [Less]
Posted about 2 years ago
Testing Picolibc with the glibc tests Picolibc has a bunch of built-in tests, but more testing is always better, right? I decided to see how hard it would be to run some of the tests provided in the GNU C Library (glibc). Parallel meson build ... [More] files Similar to how Picolibc uses meson build files to avoid modifying the newlib autotools infrastructure, I decided to take the glibc code and write meson build rules that would compile the tests against Picolibc header files and link against Picolibc libraries. I decided to select a single target for this project so I could focus on getting things building and not worry too much about making it portable. I wanted to pick something that had hardware floating point so that I would have rounding modes and exception support, so I picked the ARM Cortex M7 with hard float ABI: $ arm-none-eabi-gcc -mcpu=cortex-m7 -mfloat-abi=hard It should be fairly easy to extend this to other targets, but for now, that's what I've got working. There's a cross-cortex-m7.txt file containing all of the cross compilation details which is used when running meson setup. All of the Picolibc-specific files live in a new picolibc directory so they are isolated from the main glibc code. Pre-loading a pile of hacks Adapt Picolibc to support the Glibc test code required a bunch of random hacks, from providing _unlocked versions of the stdio macros to stubbing out various unsupportable syscalls (like sleep and chdir). Instead of modifying the Glibc code, I created a file called hacks.h which is full of this stuff and used the gcc -include parameter to read that into the compiler before starting compilation on all of the files. Supporting command line parameters The glibc tests all support a range of command line parameters, some of which turned out to be quite useful for this work. Picolibc had limited semihosting support for accessing the command line, but that required modifying applications to go fetch the command line using a special semihosting function. To make this easier, I added a new crt0 variant for picolibc called (oddly) semihost. This extends the existing hosted variant by adding a call to the semihosting library to fetch the current command line and splitting that into words at each space. It doesn't handle any quoting, but it's sufficient for the needs here. Avoiding glibc headers The glibc tests use some glibc-specific extensions to the standard POSIX C library, so I needed to include those in the test builds. Headers for those extensions are mixed in with the rest of the POSIX standard headers, which conflict with the Picolibc versions. To work around this, I stuck stub #include files in the picolibc directory which directly include the appropriate headers for the glibc API extensions. This includes things like argp.h and array_length.h. For other headers which weren't actually needed for picolibc, I created empty files. Adding more POSIX to Picolibc At this point, code was compiling but failing to find various standard POSIX functions which aren't available in Picolibc. That included some syscalls which could be emulated using semihosting, like gettimeofday and getpagesize. It also included some generally useful additions, like replacing ecvtbuf and fcvtbuf with ecvt_r and fcvt_r. The _r variants provide a target buffer size instead of assuming that it was large enough as the Picolibc buf variants did. Which tests are working? So far, I've got some of the tests in malloc, math, misc and stdio-common running. There are a lot of tests in the malloc directory which cover glibc API extensions or require POSIX syscalls not supported by semihosting. I think I've added all of the tests which should be supported. For the math tests, I'm testing the standard POSIX math APIs in both float and double forms, except for the Bessel and Gamma functions. Picolibc's versions of those are so bad that they violate some pretty basic assumptions about error bounds built into the glibc test code. Until Picolibc gets better versions of these functions, we'll have to skip testing them this way. In the misc directory, I've only added tests for ecvt, fcvt, gcvt, dirname and hsearch. I don't think there are any other tests there which should work. Finally, for stdio-common, almost all of the tests expect a fully functioning file system, which semihosting really can't support. As a result, we're only able to run the printf, scanf and some of the sprintf tests. All in all, we're running 78 of the glibc test programs, which is a small fraction of the total tests, but I think it's the bulk of the tests which cover APIs that don't depend too much on the underlying POSIX operating system. Bugs found and fixed in Picolibc This exercise has resulted in 17 fixes in Picolibc, which can be classified as: Math functions taking sNaN and not raising FE_INVALID and returning qNaN. Almost any operation on an sNaN value is supposed to signal an invalid operand and replace that with a qNaN so that further processing doesn't raise another exception. This was fairly easy to fix, just need to use return x + x; instead of return x;. Math functions failing to set errno. I'd recently restructured the math library to get rid of the separate IEEE version of the functions which didn't set errno and missed a couple of cases that needed to use the errno-setting helper functions. Corner cases in string/float conversion, including the need to perform round-to-even for '%a' conversions in printf and supporting negative decimal values for fcvt. This particular exercise led to replacing the ecvtbuf and fcvtbuf APIs with glibc's ecvt_r and fcvt_r versions as those pass explicit buffer lengths, making overflow prevention far more reliable. A bunch of malloc entry points were not handling failure correctly; allocation values close to the maximum possible size caused numerous numeric wrapping errors with the usual consequences (allocations "succeed", but return a far smaller buffer than requested). Also, realloc was failing to check the return value from malloc before copying the old data, which really isn't a good idea. Tinystdio's POSIX support code was returning an error instead of EOF at end of file. Error bounds for the Picolibc math library aren't great; I had to generate Picolibc-specific ulps files. Most functions are between 0 and 3 ulps, but for some reason, the float version of erfc (ercf) has errors as large as 64 ulps. That needs investigation. Tests added to Picolibc With all of the fixes applied to Picolibc, I added some tests to verify them without relying on running the glibc tests, that includes sNaN vs qNaN tests for math functions, testing fopen and mktemp, checking the printf %a rounding support and adding a ecvt/fcvt tests. I also discovered that the github-based CI system was compiling but not testing when using clang with a riscv target, so that got added in. Where's the source code? The Picolibc changes are sitting on the glibc-testing branch. I'll merge them once the current CI pass finishes. The hacked-up Glibc bits are in a glibc mirror at github in the picolibc project on the picolibc-testing branch. It would be interesting to know what additional tests should be usable in this environment. And, perhaps, finding a way to use this for picolibc CI testing in the future. Concluding thoughts Overall, I'm pretty pleased with these results. The bugs in malloc are fairly serious and could easily result in trouble, but the remaining issues are mostly minor and shouldn't have a big impact on applications using Picolibc. I'll get the changes merged and start thinking about doing another Picolibc release. [Less]
Posted about 2 years ago
The filter rules preventing websites from portscanning the local machine have recently been tightened in Brave. It turns out there are a surprising number of ways to refer to the local machine in Chromium. localhost and friends 127.0.0.1 is the ... [More] first address that comes to mind when thinking of the local machine. localhost is typically aliased to that address (via /etc/hosts), though that convention is not mandatory. The IPv6 equivalent is [::1]. http://localhost/ http://foo.localhost/ http://127.0.0.1/ http://0177.0000.0000.0001/ (127.0.0.1 in octal) http://0x7F000001/ (127.0.0.1 in hex) http://2130706433/ (127.0.0.1 in decimal) http://[::ffff:127.0.0.1]/ (IPv4-mapped IPv6 address) http://[::ffff:7f00:1]/ (alternate of IPv4-mapped IPv6 address) http://[0000:0000:0000:0000:0000:ffff:7f00:0001]/ (fully-expanded IPv4-mapped IPv6 address) http://[::1]/ http://[0000:0000:0000:0000:0000:0000:0000:0001]/ (fully-expanded form of [::1]) 0.0.0.0 0.0.0.0 is not a routable address, but that's what's used to tell a service to bind (listen) on all network interfaces. In Chromium, it resolves to the local machine, just like 127.0.0.1. The IPv6 equivalent is [::]. http://0.0.0.0/ http://0000.0000.0000.0000/ (0.0.0.0 in octal) http://0x00000000/(0.0.0.0 in hex) http://0/ (0.0.0.0 in decimal) http://[::ffff:0.0.0.0]/ (IPv4-mapped IPv6 address) http://[::ffff:0000:0000]/ (alternate form of IPv4-mapped IPv6 address) http://[0000:0000:0000:0000:0000:ffff:0000:0000]/ (fully-expanded IPv4-mapped IPv6 address) http://[::]/ http://[0000:0000:0000:0000:0000:0000:0000:0000]/ (fully-expanded form of [::]) DNS-based Of course, another way to encode these numerical URLs is to create A / AAAA records for them under a domain you control. I've done this under my personal domain: http://t127.fmarier.org/ (127.0.0.1) http://t1aaaa.fmarier.org/ ([::1]) http://t0.fmarier.org/ (0.0.0.0) http://t0aaaa.fmarier.org/ ([::]) http://t127aaaam.fmarier.org/ ([::ffff:7f00:1]) http://t0aaaam.fmarier.org/ ([::ffff:0000:0000]) For these to work, you'll need to: Make sure you can connect to IPv6-only hosts, for example by connecting to an appropriate VPN if needed. Put nameserver 8.8.8.8 in /etc/resolv.conf since you need a DNS server that will not filter these localhost domains. (For example, Unbound will do that if you use private-address: 127.0.0.0/8 in the server config.) Go into chrome://settings/security and disable Always use secure connections to make sure the OS resolver is used. Turn off the chrome://flags/#block-insecure-private-network-requests flag since that security feature (CORS-RFC1918) is designed to protect against these kinds of requests. 127.0.0.0/8 subnet Technically, the entire 127.0.0.0/8 subnet can used to refer to the local machine. However, it's not a reliable way to portscan a machine from a web browser because it only catches the services that listen on all interfaces (i.e. 0.0.0.0). For example, on my machine, if I nmap 127.0.0.1, I get: PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.2p1 25/tcp open smtp Postfix smtpd whereas if I nmap 127.0.1.25, I only get: PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.2p1 That's because I've got the following in /etc/postfix/main.cf: inet_interfaces = loopback-only which I assume is explicitly binding 127.0.0.1. Nevertheless, it would be good to get that fixed in Brave too. [Less]
Posted about 2 years ago
Focus This month I didn't have any particular focus. I just worked on issues in my info bubble. Changes gensim: use datapath consistently, enable a test, rm cruft git-remote-hg: option to test installed code, fix shebang handling, check for ... [More] Python/Mercurial mpv-mpris: add CPPFLAGS, smoke tests purple-discord: fix dead store, fix crash zxing-cpp: drop code copy, fix crash, spelling iotop: URL cleanup, hide SWAPIN/IO when data collection is disabled, promote iotop-c, distro packages duck: indicator phrases (1 2 3) apt: bugscript cleanup Debian DDPO: fix regex Debian package uploads: mpv-mpris, sptag, glewmx, purple-discord (1 2), gensim (1 2), git-remote-hg, python-wsproto Debian wiki pages: DebianKernel/UserspaceTools, ipw2200, PrivacyIssues, RISC-V, StaticLinking, Teams/Community Issues Crashes in fwupd/libusb (1 2) Test failure in git-remote-hg Features in gh New release needed for wsproto Update to build config and postinst needed in smartmontools Breakage caused by cgroupv2 in needrestart Conffile removal in fwupd Broken links in DiskANN Outdated license references in cloudflared Outdated dependency in DiskANN Proprietary dependency in DiskANN Embedded copies in boost1.74, DiskANN (1 2) Conflict marker in DiskANN Missing links in awesome-ld-preload (1 2) Inconsistent permissions in rasdaemon Source code in binary packages for gensim Regressions in reportbug Review Spam: reported 4 Debian bug reports and 63 Debian mailing list posts Debian wiki: RecentChanges for the month Debian BTS usertags: changes for the month Debian screenshots: approved afterstep apparmor beef bless confy cream ctorrent darktable ddnet dolphin engrampa featherpad ffmpeg fnt fontforge-extras fonts-aenigma fonts-beng-extra fonts-lohit-beng-assamese fonts-lohit-beng-bengali fvwm-icons gammastep gnome-activity-journal gnuit gromit-mpx hsbrainfuck kde-config-cddb kde-config-cron kde-config-plymouth kde-config-screenlocker kde-config-sddm kde-plasma-desktop konsole kontrast ksnip ktikz labelme labelme-examples laserboy lazpaint-gtk2 libjs-schoolkit magicrescue nbsdgames os-prober prepaid-manager-applet rawtherapee remind xmonad rejected fontconfig/fonts-beng (no UI), dnsmasq (artwork), tesseract-ocr (random game), ktikz (generic file chooser), texlive-latex-extra/msc-generator (Windows), gcc (help output), chromium-browser/hicolor-icon-theme (photograph) Administration Debian BTS: fix usertags for some users, unarchive/reopen/triage bugs for reintroduced packages: horae dh-haskell shutter logging-tree openstreetmap-carto gnome-commander Debian servers: restore wiki data from backup, restarted bacula director for TLS cert update Debian wiki: restore wiki account from backup, approve accounts Communication Respond to queries from Debian users and contributors on the mailing lists and IRC Sponsors The purple-discord, gensim, DiskANN, SPTAG, wsproto work was sponsored by my employer. All other work was done on a volunteer basis. [Less]
Posted about 2 years ago
In 2008 I joined SAGE (the System Administrators’ Guild of Australia). It was a professional society for people doing sysadmin work (running computer servers). I quit when I found that the level of clue was lower than hoped and that members used ... [More] the code of ethics as nothing but a way to score points in online debates. After quitting SAGE kept emailing me and wouldn’t respect my request to be removed from all lists so I had to block their mail server. SAGE has in recent times changed it’s name to ITPA (Information Technology Professionals Association) and is still sending me email. I’ve just sent yet another unsubscribe request. How many years of sending unwanted email can be caused by incompetence and when should we assume it’s malice? They have been doing this for over a decade now. Even if it’s incompetence, that’s still damning given that it’s incompetence in the main topic of the organisation. Here is the ITPA Code of Ethics [1], as you can see there is no reference to spam. The nearest seems to be “I will continue to enlarge my understanding of the social and legal issues that arise in computing environments, and I will communicate that understanding to others when appropriate“. So it’s great that they aren’t breaking their own code of ethics :-# but I’d still like them to stop emailing me. [1] https://www.itpa.org.au/code-of-ethics/ Related posts: I Just Joined SAGE I’ve just joined SAGE AU – the System Administrators Guild... Gmail and Anti-Spam I have just received an email with a question about... Comment Policy I’ve been thinking about the comment policy for my blogs.... [Less]
Posted about 2 years ago
The World is changing. People are not satisfied with COVID-19.
Posted about 2 years ago
As many of you may be aware, I work with Lars Wirzenius on a project we call Subplot which is a tool for writing documentation which helps all stakeholders involved with a proejct to understand how the project meets its requirements. At the ... [More] start of February we had FOSDEM which was once again online, and I decided to give a talk in the Safety and open source devroom to introduce the concepts of safety argumentation and to bring some attention to how I feel that Subplot could be used in that arena. You can view the talk on the FOSDEM website at some point in the future when they manage to finish transcoding all the amazing talks from the weekend, or if you are more impatient, on Youtube, whichever you prefer. If, after watching the talk, or indeed just reading about Subplot on our website, you are interested in learning more about Subplot, or talking with us about how it might fit into your development flow, then you can find Lars and myself in the Subplot Matrix Room or else on any number of IRC networks where I hang around as kinnison. [Less]
Posted about 2 years ago
This is a bit of a sneak preview announcement since I'm waiting for the ISC mirror to update before sending the official announcement to the normal channels, but INN 2.6.5 has been released. (The release was finalized a few days ago, and I'm a ... [More] bit behind in posting it.) This is a bug fix and minor feature release over INN 2.6.4, and the upgrade should be painless. You can download the new release from ftp.isc.org (once it updates) or my personal INN pages. The latter also has links to the full changelog and the other INN documentation. As always, thanks to Julien ÉLIE for preparing this release and doing most of the maintenance work on INN! Changes in this release: A new step in INN development has been achieved with the migration of the INN project to GitHub. We now make use of the features GitHub provides: issue tracker, pull requests, continuous integration, a user-friendly interface to browse the code, etc. Our Subversion repository has therefore been migrated to Git, and our Trac tickets to the GitHub issue tracker. An up-to-date nocem.ctl file is provided with this release. You should manually update your nocem.ctl file with the new information recorded about NoCeM issuers, and make sure the right PGP keys are present on your system. Up-to-date control.ctl and moderators files are provided with this release. You should manually update them (notably for the fido7.* hierarchy). Added a stricter validation of article numbers given in NNTP commands so that numbers superior to 2^31 are correctly considered invalid. Thanks to Richard Kettlewell for the patch. Added a check in rc.news for the existence of the pathrun directory. INN won't start until this directory is writable. Previously, it bailed out quickly after starting, without clear logs about why it failed. Fixed parallel builds using make -j. Thanks to Richard Kettlewell for the path. nnrpd now properly gathers timer statistics when a compression layer is active. nnrpd now properly discards data received from a news client after a timeout when a TLS layer is active. It previously tried to read incoming data before closing the socket, leading to decoding errors from an underlying compression or SASL layer. innfeed and ovdb_stat now generate status reports in valid HTML syntax. Fixed a bug in the buffindexed overview that prevented it from working on several systems, amongst them FreeBSD. Unsupported, and useless, permission bits were given to semaphores. Fixed the detection of library paths at configure time: multilib directories (lib32 or lib64) are now also used if they exist, even it the system does not use multilib. It will notably fix the detection of the OpenSSL 3.0.0 library. The tlscertfile parameter in inn.conf now permits the use of a complete certificate chain, instead of necessarily having to use tlscafile for additional certificates. Added support for the new OpenSSL 3.0.0 API, which deprecated a few functions. The inn.conf default value for I no longer contains TLS versions 1.0 and 1.1, which have been deprecated by RFC 8996. A new inn.conf parameter has been added to tune the length of the queue of pending connections to innd, nnrpd and the ovdb overview storage method: the maxlisten parameter now permits configuring their listen backlog, whose previously hard-coded values were 128 for B and 25 for the others, which was not high enough for some uses. The default value is now 128 for all of them, and configurable in inn.conf. Thanks to Kevin Bowling for the patch. The name of seven man pages for routines built in libinn(3) are now prefixed with libinn_ so as not to consume namespace and conflict with other packages (notably, the list(3) and uwildmat(3) man pages are now named libinn_list(3) and libinn_uwildmat(3)). Other minor bug fixes and documentation improvements, notably a revised installation checklist and a section summarizing the most used configuration at the beginning of a few complex man pages. [Less]