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]
|