Planet Debian

Now this was quite a tease! For those who haven't seen it, I encourage you to check it out, it has a nice photo of a Debian t-shirt I did not know about, to quote the Fine Article:

Today, when going through a box of old T-shirts, I found the shirt I was looking for to bring to the occasion: [...]

For the benefit of people who read this using a non-image-displaying browser or RSS client, they are respectively:

10 years 100 countries 1000 maintainers 10000 packages

and

1 project 10 architectures 100 countries 1000 maintainers 10000 packages 100000 bugs fixed 1000000 installations 10000000 users 100000000 lines of code

20 years ago we celebrated eating grilled meat at J0rd1’s house. This year, we had vegan tostadas in the menu. And maybe we are no longer that young, but we are still very proud and happy of our project!

Now… How would numbers line up today for Debian, 20 years later? Have we managed to get the “bugs fixed” line increase by a factor of 10? Quite probably, the lines of code we also have, and I can only guess the number of users and installations, which was already just a wild guess back then, might have multiplied by over 10, at least if we count indirect users and installs as well…

Now I don't know about you, but I really expected someone to come up with an answer to this, directly on Debian Planet! I have patiently waited for such an answer but enough is enough, I'm a Debian member, surely I can cull all of this together. So, low and behold, here are the actual numbers from 2023!

• 1 project: unchanged, although we could count 129 derivatives in the current census

• ~10 architectures: number almost unchanged, but the actual architectures are of course different (woody released with i386, m68k, Alpha, SPARC, PowerPC, ARM, IA-64, hppa, mips, s390; while bookworm released with actually 9 supported architectures instead of 10: i386, amd64, aarch64, armel, armhf, mipsel, mips64el, ppc64el, s390x)

• ~100 countries: actually 63 now, but I suspect we were generously rounding up last time as well (extracted with ldapsearch -b ou=users,dc=debian,dc=org -D uid=anarcat,ou=users,dc=debian,dc=org -ZZ -vLxW '(c=*)' c | grep ^c: | sort | uniq -c | sort -n | wc -l on coccia)

• ~1000 maintainers: amazingly, almost unchanged (according to the last DPL vote, there were 831 DDs in 2003 and 996 in the last vote)

• 35000 packages: that number obviously increased quite a bit, but according to sources.debian.org, woody released with 5580 source packages and bookworm with 34782 source packages and according to UDD, there are actually 200k+ binary packages ( SELECT COUNT(DISTINCT package) FROM all_packages; => 211151)

• 1 000 000+ (OVER ONE MILLION!) bugs fixed! now that number grew by a whole order of magnitude, incredibly (934809 done, 16 fixed, 7595 forwarded, 82492 pending, 938 pending-fixed, according to UDD again, SELECT COUNT(id),status FROM all_bugs GROUP BY status;)

• ~1 000 000 installations (?): that one is hard to call. popcon has 225419 recorded installs, but it is likely an underestimate - hard to count

• how many users? even harder, we were claiming ten million users then, how many now? how can we even begin to tell, with Debian running on the space station?

• 1 000 000 000+ (OVER ONE BILLION!) lines of code: that, interestingly, has also grown by an order of magnitude, from 100M to 1B lines of code, again according to sources.debian.org, woody shipped with 143M lines of codes and bookworm with 1.3 billion lines of code

So it doesn't line up as nicely, but it looks something like this:

1 project 10 architectures 30 years 100 countries (actually 63, but we'd like to have yours!) 1000 maintainers (yep, still there!) 35000 packages 211000 *binary* packages 1000000 bugs fixed 1000000000 lines of code uncounted installations and users, we don't track you

So maybe the the more accurate, rounding to the nearest logarithm, would look something like:

1 project 10 architectures 100 countries (actually 63, but we'd like to have yours!) 1000 maintainers (yep, still there!) 100000 packages 1000000 bugs fixed 1000000000 lines of code uncounted installations and users, we don't track you

I really like how the "packages" and "bugs fixed" still have an order of magnitude between them there, but that the "bugs fixed" vs "lines of code" have an extra order of magnitude, that is we have fixed ten times less bugs per line of code since we last did this count, 20 years ago.

Also, I am tempted to put 100 years in there, but that would be rounding up too much. Let's give it another 30 years first.

Hopefully, some real scientist is going to balk at this crude methodology and come up with some more interesting numbers for the next t-shirt. Otherwise I'm available for bar mitzvahs and children parties.

I recently bought an HP Chromebook from Abhas who had already flashed coreboot in it. I ran a fresh installation of Debian 12 (Bookworm) on it with KDE Plasma.

Right after installation, the Wi-Fi and bluetooth were working, but I was facing two issues:

• Playing a music file or any audio file does not give any audio.

• Keyboard buttons like the ones for brightness and audio adjustment were not working (alphabet keys were working).

So I asked my friend Alper for help on fixing the same as he has some experience with Chromebooks. Thanks a lot Alper for the help. I am documenting our steps here for helping others who are facing this issue.

Note: This works in X11. For wayland, the steps might differ.

To set system-wide keyboard configuration on Debian systems:

$ sudo dpkg-reconfigure keyboard-configuration

Choose “Chromebook” as the “Keyboard Model”.

Each DE should default to the system configuration, but might need its own configuration which would similarly be available in their GUI tools. But you can check and set it manually from the command line, for example as in this thread.

To check the keyboard model Xorg-based DEs:

$ setxkbmap -print -query | grep model: model:    pc104

To change it temporarily, until a reboot:

$ setxkbmap -model chromebook

If it’s not there in KDE settings that would be a bug, To change it persistently for KDE:

$ cat >>.config/kxkbrc <<EOF [Layout] Model=chromebook EOF

This thread was helpful.

I recently bought an HP Chromebook from Abhas who had already flashed coreboot in it. I ran a fresh installation of Debian 12 (Bookworm) on it with KDE Plasma.

Right after installation, the Wi-Fi and bluetooth were working, but I was facing two issues:

• Playing a music file or any audio file does not give any audio.

• Keyboard buttons like the ones for brightness and audio adjustment were not working (alphabet keys were working).

Fixing audio

I ran the script mentioned here and that fixed the audio.

The instructions from that link are:

git clone https://github.com/WeirdTreeThing/chromebook-linux-audio cd chromebook-linux-audio ./setup-audio Fixing keyboard

I asked my friend Alper for help on fixing the keyboard as he has some experience with Chromebooks. Thanks a lot Alper for the help. I am documenting our steps here for helping others who are facing this issue.

Note: This works in X11. For wayland, the steps might differ.

To set system-wide keyboard configuration on Debian systems:

$ sudo dpkg-reconfigure keyboard-configuration

Choose “Chromebook” as the “Keyboard Model”.

Each DE should default to the system configuration, but might need its own configuration which would similarly be available in their GUI tools. But you can check and set it manually from the command line, for example as in this thread.

To check the keyboard model Xorg-based DEs:

$ setxkbmap -print -query | grep model: model:    pc104

To change it temporarily, until a reboot:

$ setxkbmap -model chromebook

If it’s not there in KDE settings that would be a bug, To change it persistently for KDE:

$ cat >>.config/kxkbrc <<EOF [Layout] Model=chromebook EOF

This thread was helpful.

I’m one of the few folks left who run and maintain mail servers. Recently I had major troubles receiving mails from the mail servers used by a bank, and when asking my favourite search engine, I’m clearly not the only one who ran into such an issue. Actually, I should have checked off the issue and not become a customer at that bank, but the tech nerd in me couldn’t resist getting to the bottom of the problem. Since I got it working and this might be useful for others, here we are. :)

I was trying to get an online banking account set up, but the corresponding account creation mail didn’t arrive me, at all. Looking at my mail server logs, my postfix mail server didn’t accept the mail due to:

postfix/smtpd[3319640]: warning: TLS library problem: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher:../ssl/statem/statem_srvr.c:2283: postfix/smtpd[3319640]: lost connection after STARTTLS from mx01.arz.at[193.110.182.61]

Huh, what’s going on here?! Let’s increase the TLS loglevel (setting smtpd_tls_loglevel = 2) and retry. But how can I retry receiving yet another mail? Luckily, on the registration website of the bank there was a URL available, that let me request a one-time password. This triggered another mail, so I did that and managed to grab this in the logs:

postfix/smtpd[3320018]: initializing the server-side TLS engine postfix/tlsmgr[3320020]: open smtpd TLS cache btree:/var/lib/postfix/smtpd_scache postfix/tlsmgr[3320020]: tlsmgr_cache_run_event: start TLS smtpd session cache cleanup postfix/smtpd[3320018]: connect from mx01.arz.at[193.110.182.61] postfix/smtpd[3320018]: setting up TLS connection from mx01.arz.at[193.110.182.61] postfix/smtpd[3320018]: mx01.arz.at[193.110.182.61]: TLS cipher list "aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH" postfix/smtpd[3320018]: SSL_accept:before SSL initialization postfix/smtpd[3320018]: SSL_accept:before SSL initialization postfix/smtpd[3320018]: SSL3 alert write:fatal:handshake failure postfix/smtpd[3320018]: SSL_accept:error in error postfix/smtpd[3320018]: SSL_accept error from mx01.arz.at[193.110.182.61]: -1 postfix/smtpd[3320018]: warning: TLS library problem: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher:../ssl/statem/statem_srvr.c:2283: postfix/smtpd[3320018]: lost connection after STARTTLS from mx01.arz.at[193.110.182.61] postfix/smtpd[3320018]: disconnect from mx01.arz.at[193.110.182.61] ehlo=1 starttls=0/1 commands=1/2 postfix/smtpd[3320018]: connect from mx01.arz.at[193.110.182.61] postfix/smtpd[3320018]: disconnect from mx01.arz.at[193.110.182.61] ehlo=1 quit=1 commands=2

Ok, so this TLS cipher list “aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH” looked like the tls_medium_cipherlist setting in postfix, but which ciphers might we expect? Let’s see what their SMTP server would speak to us:

% testssl --cipher-per-proto -t=smtp mx01.arz.at:25 [...] Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption Bits Cipher Suite Name (IANA/RFC) ----------------------------------------------------------------------------------------------------------------------------- SSLv2 SSLv3 TLS 1 TLS 1.1 TLS 1.2 xc030 ECDHE-RSA-AES256-GCM-SHA384 ECDH 256 AESGCM 256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 xc028 ECDHE-RSA-AES256-SHA384 ECDH 256 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 xc014 ECDHE-RSA-AES256-SHA ECDH 256 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA x9d AES256-GCM-SHA384 RSA AESGCM 256 TLS_RSA_WITH_AES_256_GCM_SHA384 x3d AES256-SHA256 RSA AES 256 TLS_RSA_WITH_AES_256_CBC_SHA256 x35 AES256-SHA RSA AES 256 TLS_RSA_WITH_AES_256_CBC_SHA xc02f ECDHE-RSA-AES128-GCM-SHA256 ECDH 256 AESGCM 128 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 xc027 ECDHE-RSA-AES128-SHA256 ECDH 256 AES 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 xc013 ECDHE-RSA-AES128-SHA ECDH 256 AES 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA x9c AES128-GCM-SHA256 RSA AESGCM 128 TLS_RSA_WITH_AES_128_GCM_SHA256 x3c AES128-SHA256 RSA AES 128 TLS_RSA_WITH_AES_128_CBC_SHA256 x2f AES128-SHA RSA AES 128 TLS_RSA_WITH_AES_128_CBC_SHA TLS 1.3

Looks like a very small subset of ciphers, and they don’t seem to be talking TLS v1.3 at all? Not great. :(

A nice web service to verify the situation from another point of view is checktls, which also confirmed this:

[000.705] <-- 220 2.0.0 Ready to start TLS [000.705] STARTTLS command works on this server [001.260] Connection converted to SSL SSLVersion in use: TLSv1_2 Cipher in use: ECDHE-RSA-AES256-GCM-SHA384 Perfect Forward Secrecy: yes Session Algorithm in use: Curve P-256 DHE(256 bits) Certificate #1 of 3 (sent by MX): Cert VALIDATED: ok Cert Hostname VERIFIED (mx01.arz.at = *.arz.at | DNS:*.arz.at | DNS:arz.at) [...] [001.517] TLS successfully started on this server

I got distracted by some other work, and when coming back to this problem, the one-time password procedure no longer worked, as the password reset URL was no longer valid. :( I managed to find the underlying URL, and with some web developer tools tinkering I could still use the website to let me trigger sending further one-time password mails, phew.

Let’s continue, so my mail server was running Debian/bullseye with postfix v3.5.18-0+deb11u1 and openssl v1.1.1n-0+deb11u5, let’s see what it offers:

% testssl --cipher-per-proto -t=smtp mail.example.com:25 [...] Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption Bits Cipher Suite Name (IANA/RFC) ----------------------------------------------------------------------------------------------------------------------------- SSLv2 SSLv3 TLS 1 xc00a ECDHE-ECDSA-AES256-SHA ECDH 253 AES 256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA xc019 AECDH-AES256-SHA ECDH 253 AES 256 TLS_ECDH_anon_WITH_AES_256_CBC_SHA x3a ADH-AES256-SHA DH 2048 AES 256 TLS_DH_anon_WITH_AES_256_CBC_SHA x89 ADH-CAMELLIA256-SHA DH 2048 Camellia 256 TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA xc009 ECDHE-ECDSA-AES128-SHA ECDH 253 AES 128 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA xc018 AECDH-AES128-SHA ECDH 253 AES 128 TLS_ECDH_anon_WITH_AES_128_CBC_SHA x34 ADH-AES128-SHA DH 2048 AES 128 TLS_DH_anon_WITH_AES_128_CBC_SHA x9b ADH-SEED-SHA DH 2048 SEED 128 TLS_DH_anon_WITH_SEED_CBC_SHA x46 ADH-CAMELLIA128-SHA DH 2048 Camellia 128 TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA TLS 1.1 xc00a ECDHE-ECDSA-AES256-SHA ECDH 253 AES 256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA xc019 AECDH-AES256-SHA ECDH 253 AES 256 TLS_ECDH_anon_WITH_AES_256_CBC_SHA x3a ADH-AES256-SHA DH 2048 AES 256 TLS_DH_anon_WITH_AES_256_CBC_SHA x89 ADH-CAMELLIA256-SHA DH 2048 Camellia 256 TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA xc009 ECDHE-ECDSA-AES128-SHA ECDH 253 AES 128 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA xc018 AECDH-AES128-SHA ECDH 253 AES 128 TLS_ECDH_anon_WITH_AES_128_CBC_SHA x34 ADH-AES128-SHA DH 2048 AES 128 TLS_DH_anon_WITH_AES_128_CBC_SHA x9b ADH-SEED-SHA DH 2048 SEED 128 TLS_DH_anon_WITH_SEED_CBC_SHA x46 ADH-CAMELLIA128-SHA DH 2048 Camellia 128 TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA TLS 1.2 xc02c ECDHE-ECDSA-AES256-GCM-SHA384 ECDH 253 AESGCM 256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 xc024 ECDHE-ECDSA-AES256-SHA384 ECDH 253 AES 256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 xc00a ECDHE-ECDSA-AES256-SHA ECDH 253 AES 256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA xcca9 ECDHE-ECDSA-CHACHA20-POLY1305 ECDH 253 ChaCha20 256 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 xc0af ECDHE-ECDSA-AES256-CCM8 ECDH 253 AESCCM8 256 TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 xc0ad ECDHE-ECDSA-AES256-CCM ECDH 253 AESCCM 256 TLS_ECDHE_ECDSA_WITH_AES_256_CCM xc073 ECDHE-ECDSA-CAMELLIA256-SHA384 ECDH 253 Camellia 256 TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384 xc019 AECDH-AES256-SHA ECDH 253 AES 256 TLS_ECDH_anon_WITH_AES_256_CBC_SHA xa7 ADH-AES256-GCM-SHA384 DH 2048 AESGCM 256 TLS_DH_anon_WITH_AES_256_GCM_SHA384 x6d ADH-AES256-SHA256 DH 2048 AES 256 TLS_DH_anon_WITH_AES_256_CBC_SHA256 x3a ADH-AES256-SHA DH 2048 AES 256 TLS_DH_anon_WITH_AES_256_CBC_SHA xc5 ADH-CAMELLIA256-SHA256 DH 2048 Camellia 256 TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA256 x89 ADH-CAMELLIA256-SHA DH 2048 Camellia 256 TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA xc05d ECDHE-ECDSA-ARIA256-GCM-SHA384 ECDH 253 ARIAGCM 256 TLS_ECDHE_ECDSA_WITH_ARIA_256_GCM_SHA384 xc02b ECDHE-ECDSA-AES128-GCM-SHA256 ECDH 253 AESGCM 128 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 xc023 ECDHE-ECDSA-AES128-SHA256 ECDH 253 AES 128 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 xc009 ECDHE-ECDSA-AES128-SHA ECDH 253 AES 128 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA xc0ae ECDHE-ECDSA-AES128-CCM8 ECDH 253 AESCCM8 128 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 xc0ac ECDHE-ECDSA-AES128-CCM ECDH 253 AESCCM 128 TLS_ECDHE_ECDSA_WITH_AES_128_CCM xc072 ECDHE-ECDSA-CAMELLIA128-SHA256 ECDH 253 Camellia 128 TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256 xc018 AECDH-AES128-SHA ECDH 253 AES 128 TLS_ECDH_anon_WITH_AES_128_CBC_SHA xa6 ADH-AES128-GCM-SHA256 DH 2048 AESGCM 128 TLS_DH_anon_WITH_AES_128_GCM_SHA256 x6c ADH-AES128-SHA256 DH 2048 AES 128 TLS_DH_anon_WITH_AES_128_CBC_SHA256 x34 ADH-AES128-SHA DH 2048 AES 128 TLS_DH_anon_WITH_AES_128_CBC_SHA xbf ADH-CAMELLIA128-SHA256 DH 2048 Camellia 128 TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA256 x9b ADH-SEED-SHA DH 2048 SEED 128 TLS_DH_anon_WITH_SEED_CBC_SHA x46 ADH-CAMELLIA128-SHA DH 2048 Camellia 128 TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA xc05c ECDHE-ECDSA-ARIA128-GCM-SHA256 ECDH 253 ARIAGCM 128 TLS_ECDHE_ECDSA_WITH_ARIA_128_GCM_SHA256 TLS 1.3 x1302 TLS_AES_256_GCM_SHA384 ECDH 253 AESGCM 256 TLS_AES_256_GCM_SHA384 x1303 TLS_CHACHA20_POLY1305_SHA256 ECDH 253 ChaCha20 256 TLS_CHACHA20_POLY1305_SHA256 x1301 TLS_AES_128_GCM_SHA256 ECDH 253 AESGCM 128 TLS_AES_128_GCM_SHA256

Not so bad, but sadly no overlap with any of the ciphers that mx01.arz.at offers.

What about disabling STARTTLS for the mx01.arz.at (+ mx02.arz.at being another one used by the relevant domain) mail servers when talking to mine? Let’s try that:

% sudo postconf -nf smtpd_discard_ehlo_keyword_address_maps smtpd_discard_ehlo_keyword_address_maps = hash:/etc/postfix/smtpd_discard_ehlo_keywords % cat /etc/postfix/smtpd_discard_ehlo_keywords # *disable* starttls for mx01.arz.at / mx02.arz.at: 193.110.182.61 starttls 193.110.182.62 starttls

But the remote mail server doesn’t seem to send mails without TLS:

postfix/smtpd[4151799]: connect from mx01.arz.at[193.110.182.61] postfix/smtpd[4151799]: discarding EHLO keywords: STARTTLS postfix/smtpd[4151799]: disconnect from mx01.arz.at[193.110.182.61] ehlo=1 quit=1 commands=2

Let’s verify this further, but without fiddling with the main mail server too much. We can add a dedicated service to postfix (see serverfault), and run it in verbose mode, to get more detailled logging:

% sudo postconf -Mf [...] 10025 inet n - - - - smtpd -o syslog_name=postfix/smtpd/badstarttls -o smtpd_tls_security_level=none -o smtpd_helo_required=yes -o smtpd_helo_restrictions=pcre:/etc/postfix/helo_badstarttls_allow,reject -v [...] % cat /etc/postfix/helo_badstarttls_allow /mx01.arz.at/ OK /mx02.arz.at/ OK /193.110.182.61/ OK /193.110.182.62/ OK

We redirect the traffic from mx01.arz.at + mx02.arz.at towards our new postfix service, listening on port 10025:

% sudo iptables -t nat -A PREROUTING -p tcp -s 193.110.182.61 --dport 25 -j REDIRECT --to-port 10025 % sudo iptables -t nat -A PREROUTING -p tcp -s 193.110.182.62 --dport 25 -j REDIRECT --to-port 10025

With this setup we get very detailed logging, and it seems to confirm our suspicion that the mail server doesn’t want to talk unencrypted with us:

[...] postfix/smtpd/badstarttls/smtpd[3491900]: connect from mx01.arz.at[193.110.182.61] [...] postfix/smtpd/badstarttls/smtpd[3491901]: disconnect from mx01.arz.at[193.110.182.61] ehlo=1 quit=1 commands=2 postfix/smtpd/badstarttls/smtpd[3491901]: master_notify: status 1 postfix/smtpd/badstarttls/smtpd[3491901]: connection closed [...]

Let’s step back and revert those changes, back to our original postfix setup. Might the problem be related to our Let’s Encrypt certificate? Let’s see what we have:

% echo QUIT | openssl s_client -connect mail.example.com:25 -starttls [...] issuer=C = US, O = Let's Encrypt, CN = R3 --- No client certificate CA names sent Peer signing digest: SHA384 Peer signature type: ECDSA Server Temp Key: X25519, 253 bits --- SSL handshake has read 4455 bytes and written 427 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 384 bit [...]

We have an ECDSA based certificate, what about switching to RSA instead? Thanks to the wonderful dehydrated, this is as easy as:

% echo KEY_ALGO=rsa > certs/mail.example.com/config % ./dehydrated -c --domain mail.example.com --force % sudo systemctl reload postfix

With switching to RSA type key we get:

% echo QUIT | openssl s_client -connect mail.example.com:25 -starttls smtp CONNECTED(00000003) [...] issuer=C = US, O = Let's Encrypt, CN = R3 --- No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: X25519, 253 bits --- SSL handshake has read 5295 bytes and written 427 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 4096 bit

Which ciphers do we offer now? Let’s check:

% testssl --cipher-per-proto -t=smtp mail.example.com:25 [...] Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption Bits Cipher Suite Name (IANA/RFC) ----------------------------------------------------------------------------------------------------------------------------- SSLv2 SSLv3 TLS 1 xc014 ECDHE-RSA-AES256-SHA ECDH 253 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA x39 DHE-RSA-AES256-SHA DH 2048 AES 256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA x88 DHE-RSA-CAMELLIA256-SHA DH 2048 Camellia 256 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA xc019 AECDH-AES256-SHA ECDH 253 AES 256 TLS_ECDH_anon_WITH_AES_256_CBC_SHA x3a ADH-AES256-SHA DH 2048 AES 256 TLS_DH_anon_WITH_AES_256_CBC_SHA x89 ADH-CAMELLIA256-SHA DH 2048 Camellia 256 TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA x35 AES256-SHA RSA AES 256 TLS_RSA_WITH_AES_256_CBC_SHA x84 CAMELLIA256-SHA RSA Camellia 256 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA xc013 ECDHE-RSA-AES128-SHA ECDH 253 AES 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA x33 DHE-RSA-AES128-SHA DH 2048 AES 128 TLS_DHE_RSA_WITH_AES_128_CBC_SHA x9a DHE-RSA-SEED-SHA DH 2048 SEED 128 TLS_DHE_RSA_WITH_SEED_CBC_SHA x45 DHE-RSA-CAMELLIA128-SHA DH 2048 Camellia 128 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA xc018 AECDH-AES128-SHA ECDH 253 AES 128 TLS_ECDH_anon_WITH_AES_128_CBC_SHA x34 ADH-AES128-SHA DH 2048 AES 128 TLS_DH_anon_WITH_AES_128_CBC_SHA x9b ADH-SEED-SHA DH 2048 SEED 128 TLS_DH_anon_WITH_SEED_CBC_SHA x46 ADH-CAMELLIA128-SHA DH 2048 Camellia 128 TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA x2f AES128-SHA RSA AES 128 TLS_RSA_WITH_AES_128_CBC_SHA x96 SEED-SHA RSA SEED 128 TLS_RSA_WITH_SEED_CBC_SHA x41 CAMELLIA128-SHA RSA Camellia 128 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA TLS 1.1 xc014 ECDHE-RSA-AES256-SHA ECDH 253 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA x39 DHE-RSA-AES256-SHA DH 2048 AES 256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA x88 DHE-RSA-CAMELLIA256-SHA DH 2048 Camellia 256 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA xc019 AECDH-AES256-SHA ECDH 253 AES 256 TLS_ECDH_anon_WITH_AES_256_CBC_SHA x3a ADH-AES256-SHA DH 2048 AES 256 TLS_DH_anon_WITH_AES_256_CBC_SHA x89 ADH-CAMELLIA256-SHA DH 2048 Camellia 256 TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA x35 AES256-SHA RSA AES 256 TLS_RSA_WITH_AES_256_CBC_SHA x84 CAMELLIA256-SHA RSA Camellia 256 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA xc013 ECDHE-RSA-AES128-SHA ECDH 253 AES 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA x33 DHE-RSA-AES128-SHA DH 2048 AES 128 TLS_DHE_RSA_WITH_AES_128_CBC_SHA x9a DHE-RSA-SEED-SHA DH 2048 SEED 128 TLS_DHE_RSA_WITH_SEED_CBC_SHA x45 DHE-RSA-CAMELLIA128-SHA DH 2048 Camellia 128 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA xc018 AECDH-AES128-SHA ECDH 253 AES 128 TLS_ECDH_anon_WITH_AES_128_CBC_SHA x34 ADH-AES128-SHA DH 2048 AES 128 TLS_DH_anon_WITH_AES_128_CBC_SHA x9b ADH-SEED-SHA DH 2048 SEED 128 TLS_DH_anon_WITH_SEED_CBC_SHA x46 ADH-CAMELLIA128-SHA DH 2048 Camellia 128 TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA x2f AES128-SHA RSA AES 128 TLS_RSA_WITH_AES_128_CBC_SHA x96 SEED-SHA RSA SEED 128 TLS_RSA_WITH_SEED_CBC_SHA x41 CAMELLIA128-SHA RSA Camellia 128 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA TLS 1.2 xc030 ECDHE-RSA-AES256-GCM-SHA384 ECDH 253 AESGCM 256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 xc028 ECDHE-RSA-AES256-SHA384 ECDH 253 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 xc014 ECDHE-RSA-AES256-SHA ECDH 253 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA x9f DHE-RSA-AES256-GCM-SHA384 DH 2048 AESGCM 256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 xcca8 ECDHE-RSA-CHACHA20-POLY1305 ECDH 253 ChaCha20 256 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 xccaa DHE-RSA-CHACHA20-POLY1305 DH 2048 ChaCha20 256 TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 xc0a3 DHE-RSA-AES256-CCM8 DH 2048 AESCCM8 256 TLS_DHE_RSA_WITH_AES_256_CCM_8 xc09f DHE-RSA-AES256-CCM DH 2048 AESCCM 256 TLS_DHE_RSA_WITH_AES_256_CCM x6b DHE-RSA-AES256-SHA256 DH 2048 AES 256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 x39 DHE-RSA-AES256-SHA DH 2048 AES 256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA xc077 ECDHE-RSA-CAMELLIA256-SHA384 ECDH 253 Camellia 256 TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384 xc4 DHE-RSA-CAMELLIA256-SHA256 DH 2048 Camellia 256 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256 x88 DHE-RSA-CAMELLIA256-SHA DH 2048 Camellia 256 TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA xc019 AECDH-AES256-SHA ECDH 253 AES 256 TLS_ECDH_anon_WITH_AES_256_CBC_SHA xa7 ADH-AES256-GCM-SHA384 DH 2048 AESGCM 256 TLS_DH_anon_WITH_AES_256_GCM_SHA384 x6d ADH-AES256-SHA256 DH 2048 AES 256 TLS_DH_anon_WITH_AES_256_CBC_SHA256 x3a ADH-AES256-SHA DH 2048 AES 256 TLS_DH_anon_WITH_AES_256_CBC_SHA xc5 ADH-CAMELLIA256-SHA256 DH 2048 Camellia 256 TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA256 x89 ADH-CAMELLIA256-SHA DH 2048 Camellia 256 TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA x9d AES256-GCM-SHA384 RSA AESGCM 256 TLS_RSA_WITH_AES_256_GCM_SHA384 xc0a1 AES256-CCM8 RSA AESCCM8 256 TLS_RSA_WITH_AES_256_CCM_8 xc09d AES256-CCM RSA AESCCM 256 TLS_RSA_WITH_AES_256_CCM x3d AES256-SHA256 RSA AES 256 TLS_RSA_WITH_AES_256_CBC_SHA256 x35 AES256-SHA RSA AES 256 TLS_RSA_WITH_AES_256_CBC_SHA xc0 CAMELLIA256-SHA256 RSA Camellia 256 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256 x84 CAMELLIA256-SHA RSA Camellia 256 TLS_RSA_WITH_CAMELLIA_256_CBC_SHA xc051 ARIA256-GCM-SHA384 RSA ARIAGCM 256 TLS_RSA_WITH_ARIA_256_GCM_SHA384 xc053 DHE-RSA-ARIA256-GCM-SHA384 DH 2048 ARIAGCM 256 TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384 xc061 ECDHE-ARIA256-GCM-SHA384 ECDH 253 ARIAGCM 256 TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384 xc02f ECDHE-RSA-AES128-GCM-SHA256 ECDH 253 AESGCM 128 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 xc027 ECDHE-RSA-AES128-SHA256 ECDH 253 AES 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 xc013 ECDHE-RSA-AES128-SHA ECDH 253 AES 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA x9e DHE-RSA-AES128-GCM-SHA256 DH 2048 AESGCM 128 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 xc0a2 DHE-RSA-AES128-CCM8 DH 2048 AESCCM8 128 TLS_DHE_RSA_WITH_AES_128_CCM_8 xc09e DHE-RSA-AES128-CCM DH 2048 AESCCM 128 TLS_DHE_RSA_WITH_AES_128_CCM xc0a0 AES128-CCM8 RSA AESCCM8 128 TLS_RSA_WITH_AES_128_CCM_8 xc09c AES128-CCM RSA AESCCM 128 TLS_RSA_WITH_AES_128_CCM x67 DHE-RSA-AES128-SHA256 DH 2048 AES 128 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 x33 DHE-RSA-AES128-SHA DH 2048 AES 128 TLS_DHE_RSA_WITH_AES_128_CBC_SHA xc076 ECDHE-RSA-CAMELLIA128-SHA256 ECDH 253 Camellia 128 TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 xbe DHE-RSA-CAMELLIA128-SHA256 DH 2048 Camellia 128 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 x9a DHE-RSA-SEED-SHA DH 2048 SEED 128 TLS_DHE_RSA_WITH_SEED_CBC_SHA x45 DHE-RSA-CAMELLIA128-SHA DH 2048 Camellia 128 TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA xc018 AECDH-AES128-SHA ECDH 253 AES 128 TLS_ECDH_anon_WITH_AES_128_CBC_SHA xa6 ADH-AES128-GCM-SHA256 DH 2048 AESGCM 128 TLS_DH_anon_WITH_AES_128_GCM_SHA256 x6c ADH-AES128-SHA256 DH 2048 AES 128 TLS_DH_anon_WITH_AES_128_CBC_SHA256 x34 ADH-AES128-SHA DH 2048 AES 128 TLS_DH_anon_WITH_AES_128_CBC_SHA xbf ADH-CAMELLIA128-SHA256 DH 2048 Camellia 128 TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA256 x9b ADH-SEED-SHA DH 2048 SEED 128 TLS_DH_anon_WITH_SEED_CBC_SHA x46 ADH-CAMELLIA128-SHA DH 2048 Camellia 128 TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA x9c AES128-GCM-SHA256 RSA AESGCM 128 TLS_RSA_WITH_AES_128_GCM_SHA256 x3c AES128-SHA256 RSA AES 128 TLS_RSA_WITH_AES_128_CBC_SHA256 x2f AES128-SHA RSA AES 128 TLS_RSA_WITH_AES_128_CBC_SHA xba CAMELLIA128-SHA256 RSA Camellia 128 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256 x96 SEED-SHA RSA SEED 128 TLS_RSA_WITH_SEED_CBC_SHA x41 CAMELLIA128-SHA RSA Camellia 128 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA xc050 ARIA128-GCM-SHA256 RSA ARIAGCM 128 TLS_RSA_WITH_ARIA_128_GCM_SHA256 xc052 DHE-RSA-ARIA128-GCM-SHA256 DH 2048 ARIAGCM 128 TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256 xc060 ECDHE-ARIA128-GCM-SHA256 ECDH 253 ARIAGCM 128 TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256 TLS 1.3 x1302 TLS_AES_256_GCM_SHA384 ECDH 253 AESGCM 256 TLS_AES_256_GCM_SHA384 x1303 TLS_CHACHA20_POLY1305_SHA256 ECDH 253 ChaCha20 256 TLS_CHACHA20_POLY1305_SHA256 x1301 TLS_AES_128_GCM_SHA256 ECDH 253 AESGCM 128 TLS_AES_128_GCM_SHA256

With switching our SSL certificate to RSA, we gained around 51 new cipher options, amongst them being ones that also mx01.arz.at claimed to support.

FTR, the result from above is what you get with the default settings for postfix v3.5.18, being:

smtpd_tls_ciphers = medium smtpd_tls_mandatory_ciphers = medium smtpd_tls_mandatory_exclude_ciphers = smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3

But the delay between triggering the password reset mail and getting a mail server connect was getting bigger and bigger. Therefore while waiting for the next mail to arrive, I decided to capture the network traffic, to be able to look further into this if it should continue to be failing:

% sudo tshark -n -i eth0 -s 65535 -w arz.pcap -f "host 193.110.182.61 or host 193.110.182.62"

A few hours later the mail server connected again, and the mail went through!

postfix/smtpd[4162835]: connect from mx01.arz.at[193.110.182.61] postfix/smtpd[4162835]: Anonymous TLS connection established from mx01.arz.at[193.110.182.61]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) postfix/smtpd[4162835]: E50D6401E6: client=mx01.arz.at[193.110.182.61] postfix/smtpd[4162835]: disconnect from mx01.arz.at[193.110.182.61] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7

Now also having the captured network traffic, we can check the details there:

[...] % tshark -o smtp.decryption:true -r arz.pcap 1 0.000000000 193.110.182.61 → 203.0.113.42 TCP 74 24699 → 25 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=2261106119 TSecr=0 WS=128 2 0.000042827 203.0.113.42 → 193.110.182.61 TCP 74 25 → 24699 [SYN, ACK] Seq=0 Ack=1 Win=65160 Len=0 MSS=1460 SACK_PERM=1 TSval=3233422181 TSecr=2261106119 WS=128 3 0.020719269 193.110.182.61 → 203.0.113.42 TCP 66 24699 → 25 [ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=2261106139 TSecr=3233422181 4 0.022883259 203.0.113.42 → 193.110.182.61 SMTP 96 S: 220 mail.example.com ESMTP 5 0.043682626 193.110.182.61 → 203.0.113.42 TCP 66 24699 → 25 [ACK] Seq=1 Ack=31 Win=29312 Len=0 TSval=2261106162 TSecr=3233422203 6 0.043799047 193.110.182.61 → 203.0.113.42 SMTP 84 C: EHLO mx01.arz.at 7 0.043811363 203.0.113.42 → 193.110.182.61 TCP 66 25 → 24699 [ACK] Seq=31 Ack=19 Win=65280 Len=0 TSval=3233422224 TSecr=2261106162 8 0.043898412 203.0.113.42 → 193.110.182.61 SMTP 253 S: 250-mail.example.com | PIPELINING | SIZE 20240000 | VRFY | ETRN | AUTH PLAIN | AUTH=PLAIN | ENHANCEDSTATUSCODES | 8BITMIME | DSN | SMTPUTF8 | CHUNKING 9 0.064625499 193.110.182.61 → 203.0.113.42 SMTP 72 C: QUIT 10 0.064750257 203.0.113.42 → 193.110.182.61 SMTP 81 S: 221 2.0.0 Bye 11 0.064760200 203.0.113.42 → 193.110.182.61 TCP 66 25 → 24699 [FIN, ACK] Seq=233 Ack=25 Win=65280 Len=0 TSval=3233422245 TSecr=2261106183 12 0.085573715 193.110.182.61 → 203.0.113.42 TCP 66 24699 → 25 [FIN, ACK] Seq=25 Ack=234 Win=30336 Len=0 TSval=2261106204 TSecr=3233422245 13 0.085610229 203.0.113.42 → 193.110.182.61 TCP 66 25 → 24699 [ACK] Seq=234 Ack=26 Win=65280 Len=0 TSval=3233422266 TSecr=2261106204 14 1799.888108373 193.110.182.61 → 203.0.113.42 TCP 74 10330 → 25 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=2262906007 TSecr=0 WS=128 15 1799.888161311 203.0.113.42 → 193.110.182.61 TCP 74 25 → 10330 [SYN, ACK] Seq=0 Ack=1 Win=65160 Len=0 MSS=1460 SACK_PERM=1 TSval=3235222069 TSecr=2262906007 WS=128 16 1799.909030335 193.110.182.61 → 203.0.113.42 TCP 66 10330 → 25 [ACK] Seq=1 Ack=1 Win=29312 Len=0 TSval=2262906028 TSecr=3235222069 17 1799.956621011 203.0.113.42 → 193.110.182.61 SMTP 96 S: 220 mail.example.com ESMTP 18 1799.977229656 193.110.182.61 → 203.0.113.42 TCP 66 10330 → 25 [ACK] Seq=1 Ack=31 Win=29312 Len=0 TSval=2262906096 TSecr=3235222137 19 1799.977229698 193.110.182.61 → 203.0.113.42 SMTP 84 C: EHLO mx01.arz.at 20 1799.977266759 203.0.113.42 → 193.110.182.61 TCP 66 25 → 10330 [ACK] Seq=31 Ack=19 Win=65280 Len=0 TSval=3235222158 TSecr=2262906096 21 1799.977351663 203.0.113.42 → 193.110.182.61 SMTP 267 S: 250-mail.example.com | PIPELINING | SIZE 20240000 | VRFY | ETRN | STARTTLS | AUTH PLAIN | AUTH=PLAIN | ENHANCEDSTATUSCODES | 8BITMIME | DSN | SMTPUTF8 | CHUNKING 22 1800.011494861 193.110.182.61 → 203.0.113.42 SMTP 76 C: STARTTLS 23 1800.011589267 203.0.113.42 → 193.110.182.61 SMTP 96 S: 220 2.0.0 Ready to start TLS 24 1800.032812294 193.110.182.61 → 203.0.113.42 TLSv1 223 Client Hello 25 1800.032987264 203.0.113.42 → 193.110.182.61 TLSv1.2 2962 Server Hello 26 1800.032995513 203.0.113.42 → 193.110.182.61 TCP 1266 25 → 10330 [PSH, ACK] Seq=3158 Ack=186 Win=65152 Len=1200 TSval=3235222214 TSecr=2262906151 [TCP segment of a reassembled PDU] 27 1800.053546755 193.110.182.61 → 203.0.113.42 TCP 66 10330 → 25 [ACK] Seq=186 Ack=3158 Win=36096 Len=0 TSval=2262906172 TSecr=3235222214 28 1800.092852469 193.110.182.61 → 203.0.113.42 TCP 66 10330 → 25 [ACK] Seq=186 Ack=4358 Win=39040 Len=0 TSval=2262906212 TSecr=3235222214 29 1800.092892905 203.0.113.42 → 193.110.182.61 TLSv1.2 900 Certificate, Server Key Exchange, Server Hello Done 30 1800.113546769 193.110.182.61 → 203.0.113.42 TCP 66 10330 → 25 [ACK] Seq=186 Ack=5192 Win=41856 Len=0 TSval=2262906232 TSecr=3235222273 31 1800.114763363 193.110.182.61 → 203.0.113.42 TLSv1.2 192 Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message 32 1800.115000416 203.0.113.42 → 193.110.182.61 TLSv1.2 117 Change Cipher Spec, Encrypted Handshake Message 33 1800.136070200 193.110.182.61 → 203.0.113.42 TLSv1.2 113 Application Data 34 1800.136155526 203.0.113.42 → 193.110.182.61 TLSv1.2 282 Application Data 35 1800.158854473 193.110.182.61 → 203.0.113.42 TLSv1.2 162 Application Data 36 1800.159254794 203.0.113.42 → 193.110.182.61 TLSv1.2 109 Application Data 37 1800.180286407 193.110.182.61 → 203.0.113.42 TLSv1.2 144 Application Data 38 1800.223005960 203.0.113.42 → 193.110.182.61 TCP 66 25 → 10330 [ACK] Seq=5502 Ack=533 Win=65152 Len=0 TSval=3235222404 TSecr=2262906299 39 1802.230300244 203.0.113.42 → 193.110.182.61 TLSv1.2 146 Application Data 40 1802.251994333 193.110.182.61 → 203.0.113.42 TCP 2962 [TCP segment of a reassembled PDU] 41 1802.252034015 203.0.113.42 → 193.110.182.61 TCP 66 25 → 10330 [ACK] Seq=5582 Ack=3429 Win=63616 Len=0 TSval=3235224433 TSecr=2262908371 42 1802.252279083 193.110.182.61 → 203.0.113.42 TLSv1.2 1295 Application Data 43 1802.252288316 203.0.113.42 → 193.110.182.61 TCP 66 25 → 10330 [ACK] Seq=5582 Ack=4658 Win=64128 Len=0 TSval=3235224433 TSecr=2262908371 44 1802.272816060 193.110.182.61 → 203.0.113.42 TLSv1.2 833 Application Data, Application Data 45 1802.272827542 203.0.113.42 → 193.110.182.61 TCP 66 25 → 10330 [ACK] Seq=5582 Ack=5425 Win=64128 Len=0 TSval=3235224453 TSecr=2262908392 46 1802.338807683 203.0.113.42 → 193.110.182.61 TLSv1.2 131 Application Data 47 1802.398968611 193.110.182.61 → 203.0.113.42 TCP 66 10330 → 25 [ACK] Seq=5425 Ack=5647 Win=44800 Len=0 TSval=2262908518 TSecr=3235224519 48 1863.257457500 193.110.182.61 → 203.0.113.42 TLSv1.2 101 Application Data 49 1863.257495688 203.0.113.42 → 193.110.182.61 TCP 66 25 → 10330 [ACK] Seq=5647 Ack=5460 Win=64128 Len=0 TSval=3235285438 TSecr=2262969376 50 1863.257654942 203.0.113.42 → 193.110.182.61 TLSv1.2 110 Application Data 51 1863.257721010 203.0.113.42 → 193.110.182.61 TLSv1.2 97 Encrypted Alert 52 1863.278242216 193.110.182.61 → 203.0.113.42 TCP 66 10330 → 25 [ACK] Seq=5460 Ack=5691 Win=44800 Len=0 TSval=2262969397 TSecr=3235285438 53 1863.278464176 193.110.182.61 → 203.0.113.42 TCP 66 10330 → 25 [RST, ACK] Seq=5460 Ack=5723 Win=44800 Len=0 TSval=2262969397 TSecr=3235285438 % tshark -O tls -r arz.pcap [...] Transport Layer Security TLSv1 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 152 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 148 Version: TLS 1.2 (0x0303) Random: 4575d1e7c93c09a564edc00b8b56ea6f5d826f8cfe78eb980c451a70a9c5123f GMT Unix Time: Dec 5, 2006 21:09:11.000000000 CET Random Bytes: c93c09a564edc00b8b56ea6f5d826f8cfe78eb980c451a70a9c5123f Session ID Length: 0 Cipher Suites Length: 26 Cipher Suites (13 suites) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d) Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) [...] Transport Layer Security TLSv1.2 Record Layer: Handshake Protocol: Server Hello Content Type: Handshake (22) Version: TLS 1.2 (0x0303) Length: 89 Handshake Protocol: Server Hello Handshake Type: Server Hello (2) Length: 85 Version: TLS 1.2 (0x0303) Random: cf2ed24e3300e95e5f56023bf8b4e5904b862bb2ed8a5796444f574e47524401 GMT Unix Time: Feb 23, 2080 23:16:46.000000000 CET Random Bytes: 3300e95e5f56023bf8b4e5904b862bb2ed8a5796444f574e47524401 Session ID Length: 32 Session ID: 63d041b126ecebf857d685abd9d4593c46a3672e1ad76228f3eacf2164f86fb9 Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) [...]

In this network dump we see what cipher suites are offered, and the TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 here is the Cipher Suite Name in IANA/RFC speak. Whis corresponds to the ECDHE-RSA-AES256-GCM-SHA384 in openssl speak (see Mozilla’s Mozilla’s cipher suite correspondence table), which we also saw in the postfix log.

Mission accomplished! :)

Now, if we’re interested in avoiding certain ciphers and increase security level, we can e.g. get rid of the SEED, CAMELLIA and all anonymous ciphers, and could accept only TLS v1.2 + v1.3, by further adjusting postfix’s main.cf:

smtpd_tls_ciphers = high smtpd_tls_exclude_ciphers = aNULL CAMELLIA smtpd_tls_mandatory_ciphers = high smtpd_tls_mandatory_protocols = TLSv1.2 TLSv1.3 smtpd_tls_protocols = TLSv1.2 TLSv1.3

Which would then gives us:

% testssl --cipher-per-proto -t=smtp mail.example.com:25 [...] Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption Bits Cipher Suite Name (IANA/RFC) ----------------------------------------------------------------------------------------------------------------------------- SSLv2 SSLv3 TLS 1 TLS 1.1 TLS 1.2 xc030 ECDHE-RSA-AES256-GCM-SHA384 ECDH 253 AESGCM 256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 xc028 ECDHE-RSA-AES256-SHA384 ECDH 253 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 xc014 ECDHE-RSA-AES256-SHA ECDH 253 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA x9f DHE-RSA-AES256-GCM-SHA384 DH 2048 AESGCM 256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 xcca8 ECDHE-RSA-CHACHA20-POLY1305 ECDH 253 ChaCha20 256 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 xccaa DHE-RSA-CHACHA20-POLY1305 DH 2048 ChaCha20 256 TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 xc0a3 DHE-RSA-AES256-CCM8 DH 2048 AESCCM8 256 TLS_DHE_RSA_WITH_AES_256_CCM_8 xc09f DHE-RSA-AES256-CCM DH 2048 AESCCM 256 TLS_DHE_RSA_WITH_AES_256_CCM x6b DHE-RSA-AES256-SHA256 DH 2048 AES 256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 x39 DHE-RSA-AES256-SHA DH 2048 AES 256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA x9d AES256-GCM-SHA384 RSA AESGCM 256 TLS_RSA_WITH_AES_256_GCM_SHA384 xc0a1 AES256-CCM8 RSA AESCCM8 256 TLS_RSA_WITH_AES_256_CCM_8 xc09d AES256-CCM RSA AESCCM 256 TLS_RSA_WITH_AES_256_CCM x3d AES256-SHA256 RSA AES 256 TLS_RSA_WITH_AES_256_CBC_SHA256 x35 AES256-SHA RSA AES 256 TLS_RSA_WITH_AES_256_CBC_SHA xc051 ARIA256-GCM-SHA384 RSA ARIAGCM 256 TLS_RSA_WITH_ARIA_256_GCM_SHA384 xc053 DHE-RSA-ARIA256-GCM-SHA384 DH 2048 ARIAGCM 256 TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384 xc061 ECDHE-ARIA256-GCM-SHA384 ECDH 253 ARIAGCM 256 TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384 xc02f ECDHE-RSA-AES128-GCM-SHA256 ECDH 253 AESGCM 128 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 xc027 ECDHE-RSA-AES128-SHA256 ECDH 253 AES 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 xc013 ECDHE-RSA-AES128-SHA ECDH 253 AES 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA x9e DHE-RSA-AES128-GCM-SHA256 DH 2048 AESGCM 128 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 xc0a2 DHE-RSA-AES128-CCM8 DH 2048 AESCCM8 128 TLS_DHE_RSA_WITH_AES_128_CCM_8 xc09e DHE-RSA-AES128-CCM DH 2048 AESCCM 128 TLS_DHE_RSA_WITH_AES_128_CCM xc0a0 AES128-CCM8 RSA AESCCM8 128 TLS_RSA_WITH_AES_128_CCM_8 xc09c AES128-CCM RSA AESCCM 128 TLS_RSA_WITH_AES_128_CCM x67 DHE-RSA-AES128-SHA256 DH 2048 AES 128 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 x33 DHE-RSA-AES128-SHA DH 2048 AES 128 TLS_DHE_RSA_WITH_AES_128_CBC_SHA x9c AES128-GCM-SHA256 RSA AESGCM 128 TLS_RSA_WITH_AES_128_GCM_SHA256 x3c AES128-SHA256 RSA AES 128 TLS_RSA_WITH_AES_128_CBC_SHA256 x2f AES128-SHA RSA AES 128 TLS_RSA_WITH_AES_128_CBC_SHA xc050 ARIA128-GCM-SHA256 RSA ARIAGCM 128 TLS_RSA_WITH_ARIA_128_GCM_SHA256 xc052 DHE-RSA-ARIA128-GCM-SHA256 DH 2048 ARIAGCM 128 TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256 xc060 ECDHE-ARIA128-GCM-SHA256 ECDH 253 ARIAGCM 128 TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256 TLS 1.3 x1302 TLS_AES_256_GCM_SHA384 ECDH 253 AESGCM 256 TLS_AES_256_GCM_SHA384 x1303 TLS_CHACHA20_POLY1305_SHA256 ECDH 253 ChaCha20 256 TLS_CHACHA20_POLY1305_SHA256 x1301 TLS_AES_128_GCM_SHA256 ECDH 253 AESGCM 128 TLS_AES_128_GCM_SHA256

Don’t forget to also adjust the smpt_tls_* accordingly (for your sending side). For further information see the Postfix TLS Support documentation. Also check out options like tls_ssl_options (setting it to e.g. NO_COMPRESSION) and tls_preempt_cipherlist (setting it to yes would prefer the servers’ order of ciphers over clients).

Conclusions:

• no matter what you change in your mail server settings, be aware that the type of your SSL certificate also matters for what ciphers are offered and used
• there are mail servers out there that don’t support SSL certificates with ECDSA, using RSA for those ensure better compatibility (nowadays postfix supports parallel usage of ECDSA and RSA keys BTW, check out the smtpd_tls_eccert_file + smtpd_tls_eckey_file options)
• testssl is a very useful tool, especially with its –cipher-per-proto -t=smtp option to check SMTP servers
• if you’re uncertain what’s going on, consider capturing network data (tshark/tcpdump/… are your friends)
• review your postfix configuration and logs every now and then :)

The new 7945HX CPU from AMD is currently the most powerful. I’d love to have one of them, to replace the now aging 6 core Xeon that I’ve been using for more than 5 years. So, I’ve been searching for a laptop with that CPU.

Absolutely all of the laptops I found with this CPU also embed a very powerful RTX 40×0 series GPU, that I have no use: I don’t play games, and I don’t do AI. I just want something that builds Debian packages fast (like Ceph, that takes more than 1h to build for me…). The more cores I get, the faster all OpenStack unit tests are running too (stestr does a moderately good job at spreading the tests to all cores). That’d be ok if I had to pay more for a GPU that I don’t need, and I would have deal with the annoyance of the NVidia driver, if only I could find something with a correct size. But I can only find 16″ or bigger laptops, that wont fit in my scooter back case (most of the time, these laptops have an 17 inch screen: that’s a way too big).

Currently, I found:

• Lenovo Legion Pro 5: screen is 16.8″
• Dell Alienware m6: super heavy, 16″
• Asus ROG Zephyrus Duo 16: 16″
• MSI alpha (16 and 17): also 16″

If one of the readers of this post find a smaller laptop with a 7945HX CPU, please let me know! Even better if I can get rid of the expensive NVidia GPU.

Man, you’re no longer with us, but I am touched by the number of people you have positively impacted. Almost every DebConf presentations by locals, I saw after you carried how you were instrumental in bringing them there. How you were a dear friend and brother.

It’s a weird turn of events, that you left us during one thing we deeply cared and worked towards making possible since the past 3 years, together. Who would have known, that “Sahil, I’m going back to my apartment tonight” and casual bye post that would be the last conversation we ever had.

Things were terrible after I heard the news. I had a hard time convincing myself to come see you one last time during your funeral. That was the last time I was going to get to see you, and I kept on looking at you. You, there in front of me, all calm, gave me peace. I’ll carry that image all my life now. Your smile will always remain with me. Who’ll meet and receive me on the door at almost every Debian event (just by sheer co-incidence?). Who’ll help me speak out loud about all the Debian shortcomings (and then discuss solutions, when sober :)).

It was a testament of the amount of time we had already spent together online, that when we first met during MDC Palakkad, it didn’t feel we’re physically meeting for the first time. The conversations just continued. Now this song is associated with you now due to your speech during MiniDebConf Palakkad dinner. Hearing this keeps on reminding me of all the times we spent together chilling and talking community (which you cared deeply about). IG now we can’t stop caring for the community, because your energy was contagious.

Now, I can’t directly dial your number to listen - “Hey Sahil! What’s up?” from the other end, or “Tell me, tell me” on any mention of the problem. Nor would I be able to send ref of usage of Debian packaging guide in the wild. You already know about that text of yours. How many people that guide has helped with getting started with packaging. Did I ever tell you, I too got my first start with packaging from there. Hell, I started looking up to you from there, even before we met or talked. Now, I missed telling you, I was probably your biggest fan whenever you had the mic in hand and started speaking. You always surprised me all the insights and idea you brought and would keep on impressing me for someone who was just my age but was way more mature.

Reading recent toots from Raju Dev made me realize, how much I loved your writings. You wrote How the Future will remember Us, Doing what’s right and many more. The level of depth in your thought was unparalleled. I loved reading those, that’s why I kept pestering you to write more, which you slowly stopped. Now I fully understand why though, you were busy, really busy helping people out or just working for making things better. You were doing Debian, upstream projects, web development, designs, graphics, mentoring, evangelist while being the go-to person for almost everyone around. Everyone depended on you, because you were too kind to turn down anyone.

Man, I still get your spelling wrong :) Did I ever tell you that? That was the reason, I used to use AR instead.

You’ll be missed and will always be part of our conversations, because you have left a profound impact on me, our friends, Debian India and everyone around. See you! the coolest man around.

In memory:

• Farewell Abraham video by Vysakh Premkumar
• Tails project dedicating 5.17.1 release
• Hopscotch team dedicating 2023.8.1
• Athul dedicating 0.2.5 release of waka-readme
• Debian project

PS - Just found you even had a Youtube channel, you one heck of a talented man.

This post describes how to define and use rule templates with semantic names using extends or !reference tags, how to define manual jobs using the same templates and how to use gitlab-ci inputs as macros to give names to regular expressions used by rules.

Basic rule templates

I keep my templates in a rules.yml file stored on a common repository used from different projects as I mentioned on my previous post, but they can be defined anywhere, the important thing is that the files that need them include their definition somehow.

The first version of my rules.yml file was as follows:

.rules_common: # Common rules; we include them from others instead of forcing a workflow rules: # Disable branch pipelines while there is an open merge request from it - if: >- $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS && $CI_PIPELINE_SOURCE != "merge_request_event" when: never .rules_default: # Default rules, we need to add the when: on_success to make things work rules: - !reference [.rules_common, rules] - when: on_success

The main idea is that .rules_common defines a rule section to disable jobs as we can do on a workflow definition; in our case common rules only have if rules that apply to all jobs and are used to disable them. The example includes one that avoids creating duplicated jobs when we push to a branch that is the source of an open MR as explained here.

To use the rules in a job we have two options, use the extends keyword (we do that when we want to use the rule as is) or declare a rules section and add a !reference to the template we want to use as described here (we do that when we want to add additional rules to disable a job before evaluating the template conditions).

As an example, with the following definitions both jobs use the same rules:

job_1: extends: - .rules_default [...] job_2: rules: - !reference [.rules_default, rules] [...] Manual jobs and rule templates

To make the jobs manual we have two options, create a version of the job that includes when: manual and defines if we want it to be optional or not (allow_failure: true makes the job optional, if we don’t add that to the rule the job is blocking) or add the when: manual and the allow_failure value to the job (if we work at the job level the default value for allow_failure is false for when: manual, so it is optional by default, we have to add an explicit allow_failure = true it to make it blocking).

The following example shows how we define blocking or optional manual jobs using rules with when conditions:

.rules_default_manual_blocking: # Default rules for optional manual jobs rules: - !reference [.rules_common, rules] - when: manual # allow_failure: false is implicit .rules_default_manual_optional: # Default rules for optional manual jobs rules: - !reference [.rules_common, rules] - when: manual allow_failure: true manual_blocking_job: extends: - .rules_default_manual_blocking [...] manual_optional_job: extends: - .rules_default_manual_optional [...]

The problem here is that we have to create new versions of the same rule template to add the conditions, but we can avoid it using the keywords at the job level with the original rules to get the same effect; the following definitions create jobs equivalent to the ones defined earlier without creating additional templates:

manual_blocking_job: extends: - .rules_default when: manual allow_failure: false [...] manual_optional_job: extends: - .rules_default when: manual # allow_failure: true is implicit [...]

As you can imagine, that is my preferred way of doing it, as it keeps the rules.yml file smaller and I see that the job is manual in its definition without problem.

Rules with allow_failure, changes, exists, needs or variables

Unluckily for us, for now there is no way to avoid creating additional templates as we did on the when: manual case when a rule is similar to an existing one but adds changes, exists, needs or variables to it.

So, for now, if a rule needs to add any of those fields we have to copy the original rule and add the keyword section.

Some notes, though:

• we only need to add allow_failure if we want to change its value for a given condition, in other cases we can set the value at the job level.
• if we are adding changes to the rule it is important to make sure that they are going to be evaluated as explained here.
• when we add a needs value to a rule for a specific condition and it matches it replaces the job needs section; when using templates I would use two different job names with different conditions instead of adding a needs on a single job.

Defining rule templates with semantic names

I started to use rule templates to avoid repetition when defining jobs that needed the same rules and soon I noticed that giving them names with a semantic meaning they where easier to use and understand (we provide a name that tells us when we are going to execute the job, while the details of the variables names or values used on the rules are an implementation detail of the templates).

We are not going to define real jobs on this post, but as an example we are going to define a set of rules that can be useful if we plan to follow a scaled trunk based development workflow when developing, that is, we are going to put the releasable code on the main branch and use short-lived branches to test and complete changes before pushing things to main.

Using this approach we can define an initial set of rule templates with semantic names:

.rules_mr_to_main: rules: - !reference [.rules_common, rules] - if: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == 'main' .rules_mr_or_push_to_main: rules: - !reference [.rules_common, rules] - if: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == 'main' - if: >- $CI_COMMIT_BRANCH == 'main' && $CI_PIPELINE_SOURCE != 'merge_request_event' .rules_push_to_main: rules: - !reference [.rules_common, rules] - if: >- $CI_COMMIT_BRANCH == 'main' && $CI_PIPELINE_SOURCE != 'merge_request_event' .rules_push_to_branch: rules: - !reference [.rules_common, rules] - if: >- $CI_COMMIT_BRANCH != 'main' && $CI_PIPELINE_SOURCE != 'merge_request_event' .rules_push_to_branch_or_mr_to_main: rules: - !reference [.rules_push_to_branch, rules] - if: >- $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME != 'main' && $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == 'main' .rules_release_tag: rules: - !reference [.rules_common, rules] - if: $CI_COMMIT_TAG =~ /^([0-9a-zA-Z_.-]+-)?v\d+.\d+.\d+$/ .rules_non_release_tag: rules: - !reference [.rules_common, rules] - if: $CI_COMMIT_TAG !~ /^([0-9a-zA-Z_.-]+-)?v\d+.\d+.\d+$/

With those names it is clear when a job is going to be executed and when using the templates on real jobs we can add additional restrictions and make the execution manual if needed as described earlier.

Using inputs as macros

On the previous rules we have used a regular expression to identify the release tag format and assumed that the general branches are the ones with a name different than main; if we want to force a format for those branch names we can replace the condition != 'main' by a regex comparison (=~ if we look for matches, !~ if we want to define valid branch names removing the invalid ones).

When testing the new gitlab-ci inputs my colleague Jorge noticed that if you keep their default value they basically work as macros.

The variables declared as inputs can’t hold YAML values, the truth is that their value is always a string that is replaced by the value assigned to them when including the file (if given) or by their default value, if defined.

If you don’t assign a value to an input variable when including the file that declares it its occurrences are replaced by its default value, making them work basically as macros; this is useful for us when working with strings that can’t managed as variables, like the regular expressions used inside if conditions.

With those two ideas we can add the following prefix to the rules.yaml defining inputs for both regular expressions and replace the rules that can use them by the ones shown here:

spec: inputs: # Regular expression for branches; the prefix matches the type of changes # we plan to work on inside the branch (we use conventional commit types as # the branch prefix) branch_regex: default: '/^(build|ci|chore|docs|feat|fix|perf|refactor|style|test)\/.+$/' # Regular expression for tags release_tag_regex: default: '/^([0-9a-zA-Z_.-]+-)?v\d+.\d+.\d+$/' --- [...] .rules_push_to_changes_branch: rules: - !reference [.rules_common, rules] - if: >- $CI_COMMIT_BRANCH =~ $[[ inputs.branch_regex ]] && $CI_PIPELINE_SOURCE != 'merge_request_event' .rules_push_to_branch_or_mr_to_main: rules: - !reference [.rules_push_to_branch, rules] - if: >- $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ $[[ inputs.branch_regex ]] && $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == 'main' .rules_release_tag: rules: - !reference [.rules_common, rules] - if: $CI_COMMIT_TAG =~ $[[ inputs.release_tag_regex ]] .rules_non_release_tag: rules: - !reference [.rules_common, rules] - if: $CI_COMMIT_TAG !~ $[[ inputs.release_tag_regex ]] Creating rules reusing existing ones

I’m going to finish this post with a comment about how I avoid defining extra rule templates in some common cases.

The idea is simple, we can use !reference tags to fine tune rules when we need to add conditions to disable them simply adding conditions with when: never before referencing the template.

As an example, in some projects I’m using different job definitions depending on the DEPLOY_ENVIRONMENT value to make the job manual or automatic; as we just said we can define different jobs referencing the same rule adding a condition to check if the environment is the one we are interested in:

deploy_job_auto: rules: # Only deploy automatically if the environment is 'dev' by skipping this job # for other values of the DEPLOY_ENVIRONMENT variable - if: $DEPLOY_ENVIRONMENT != "dev" when: never - !reference [.rules_release_tag, rules] [...] deploy_job_manually: rules: # Disable this job if the environment is 'dev' - if: $DEPLOY_ENVIRONMENT == "dev" when: never - !reference [.rules_release_tag, rules] when: manual # Change this to `false` to make the deployment job blocking allow_failure: true [...]

If you think about it the idea of adding negative conditions is what we do with the .rules_common template; we add conditions to disable the job before evaluating the real rules.

The difference in that case is that we reference them at the beginning because we want those negative conditions on all jobs and that is also why we have a .rules_default condition with an when: on_success for the jobs that only need to respect the default workflow (we need the last condition to make sure that they are executed if the negative rules don’t match).

Last week tragedy struck, and I saw the very best of the Debian community at work.

I heard first hand testimony about how helpless so many people felt at being physically unable to help their friend. I heard about how they couldn’t bear to leave and had to be ushered away to make space for rescue services to do their work. I heard of those who continued the search with private divers, even after the official rescue was called off.

I saw the shock and grief which engulfed everybody who I saw that night and in the following days. I watched friends comfort each other when it became too much. I read the messages we wrote in memory and smiled at how they described the person I’d only just started to know.

When I felt angry, and helpless, and frustrated that I couldn’t do more, the people around me caught me, comforted me, and cared for me.

Debian, you are like family and nobody can claim otherwise. You bicker and argue about the silliest things and sometimes it feels like we’ll never get past them. But when it comes to simple human compassion for each other, you always surprise me with your ability to care.

Official logo of DebConf23 Introduction

DebConf23, the 24th annual Debian Conference, was held in India in the city of Kochi, Kerala from 3 September - 17 September 2023. I was excited to attend DebConf in my home country ever since I got to know about it (more than an year ago). This was my second DebConf as I attended one last year in Kosovo. I was very happy that I don’t need to apply for a visa to attend the conference. This time I submitted two talks - one on Debian packaging for beginners and the other on ideas on sustainable solutions for self-hosting. I got full bursary to attend the event (thanks a lot to debian for that!) which is always helpful in covering the expenses, especially if the venue is a five star hotel :)

My friend Suresh, who is enthusiastic about debian and free software, also wanted to attend the DebConf. When the registration started, I reminded him to apply. We landed in Kochi on 28 August 2023 during the Onam festival. Then, we celebrated Onam in Kochi, had a trip to Wayanad and returned to Kochi. On 3 September evening, we reached the venue - Four Points Hotel by Sheraton, Infopark Kochi, Ernakulam, Kerala, India.

Hotel overview

The hotel had 14 floors, and featured a swimming pool and gym - these were included in our package. The hotel gave us elevator access only for our floor and public spaces like reception, gym, swimming pool and meals. The temperature inside the hotel was pretty cold and I had to buy a jacket to survive. Perhaps the hotel had tie up with warm clothing sellers :)

Meals

On the first day, Suresh and I went to dinner which was at the eatery on the third floor. At the entrance, there was a staff who asked us about how many people we want the table for. I told her that it’s just the two [of us] at the moment, but we might be joined by others, as we are attending a conference, more people may join us. Even so, they gave us a table for two. Within a few minutes, Alper (from Turkey) and urbec (Germany) showed up and joined us. So we shifted to a larger table, and even more people joined, so we were busy adding more chairs to our table. urbec was already in Kerala since 5-6 days and was very happy already with the quality and taste of bananas in Kerala, and also afraid of the spicy food :)

Two days later, the lunch and dinner got shifted to the All Spice Restaurant at the 14th floor, but the breakfast was still at eatery. Since eatery (on 3rd floor) had much more options than the other venue, this move made breakfast the best meal for me and many others. Many attendees from outside India were not accustomed to the “spicy” and hot food. It is difficult for locals to help because what they find non spicy can be spicy for non Indians. It is not easy to satisy everyone at the dining table but I think the organizing team did a very good job in the food department. Well, it didn’t matter for me after a point and you will know why. The pappadam were really good, I liked the rice labelled “Kerala rice”. I actually brought that exact rice and pappadam home during my last trip to Kochi and everyone at my home liked it (thanks to Abhijit PA). I also wished to eat all types of payasams from Kerala and this really happened (thanks to Sruthi who designed the menu). Every meal had a different variety of payasam and it was awesome, although I didn’t like some of them mostly because of them being very sweet. Meals were later shifted to the ground floor (taking away the best breakfast option which was eatery).

Swag bag was excellent

The debconf registration desk was at the second floor. We got a very nice swag bag. The swag bags were available in multiple colors - grey, green, blue, red. The bag included an umbrella, a steel mug, a multiboot USB drive by Mostly Harmless, a thermal flask, a mug by Canonical, a [paper] coaster and stickers. It rained almost everyday in Kochi when we were there so handing out an umbrella to every attendee was a good idea.

Picture of awesome swag bag we got in debconf23. Nattie got a gift

One day during the breakfast, Nattie said she wants to buy a coffee filter. Next time when I went to the market, I bought a coffee filter for her as a gift. She seemed happy with the gift and was flattered to receive a gift from a young man :)

Mentoring by me

There were many newbies and they were eager to learn and contribute to debian. So, I mentored whoever came to me and was interested to learn. I took a packaging workshop in the bootcamp but could only cover how to setup debian unstable environment, not how to package (but I covered in my talk). Carlos (Brazil) gave a keysigning session in the bootcamp. Praveen was also mentoring in the bootcamp. I helped people in understanding why we sign gpg keys and how to sign it. I planned to take a workshop on it but cancelled it later.

My talk

My debian packaging talk was on 10 September 2023. I had not prepared slides for my debian packaging talk in advance and I thought I can do it during the trip but I didn’t get time for that. So I prepared them within a day before the talk. Since it was mostly a tutorial, it didn’t need so much preparation for the slides. it was possible to do in a hurry because Suresh helped me with the slides. Thanks to him.

My talk was well received by the audience as implied by their comments. I am glad that I could give an interesting presentation.

My presentation photo. Credits: Valessio A visit to saree shop

After my talk, I went with Anisa and Kristi (both from Albania), whose fascination for the Indian culture is never ending :), (along with Suresh and Alper) as they wanted to buy sarees for themselves. We took autos to Kakkanad market and found a shop with lots of variety of sarees. Obviously, I got a little familiar with the area surrounding the hotel as I was there since a week. Indian women usually don’t try sarees on themselves while buying, they only select the design. But Anisa wanted to put one on along with a photoshoot. The shop staff weren’t ready with a trial saree for this, so they took a saree from a mannequin. It took about an hour for the lady at the shop to get that saree on her. Anyone can tell that she felt in heaven while wearing that saree and immediately bought that one :) Alper also bought a saree to take back to Turkey for his mother. Me and Suresh wanted to buy a kurta which can go along mundu we already had, but we didn’t find anything that we liked.

Selfie with Anisa and Kristi. Cheese and Wine Party

11 September was Cheese and Wine Party, a tradition of every debconf. I brought Kaju Samosa and Nankhatai from home. Many attendees told me they liked the samosa. During the party, I was with Abhas and had a lot of fun. Abhas brought paan packets and put them for the Cheese and Wine Party. We discussed interesting things and ate burgers. But due to the restrictive alcohol laws in the state, it was not the same as in previous debconf because you can only drink alcohol served by the hotel in public places. If you buy your own alcohol, you can only drink in private places like in your room or friend’s room but not in public places.

Me helping with the Cheese and Wine Party Party at my room

Last year, Joenio (Brazilian) brought pastis from France which I liked. He brought the same alocholic drink this year too. So I invited him to my room after Cheese and Wine party to have pastis. My idea was to have this with my roommate Suresh and Joenio. But then we permitted Joenio to bring as many people as he wants. He brought some ten people I think and suddenly it was crowded. I was having good time in the party, serving them snacks that Abhas gave me. The news of an alcohol party at my room spread like wildfire. Soon there were so many people that the AC was not cooling anymore and I was sweating. I left the room and roamed around in the hotel for some fresh air. I came back after 1.5 hours, after sitting mostly at the ground floor with someone whose name I can’t remember. And then I met Abraham near the gym (which was my last meeting with him). I came back to my room at around 02:30 AM and nobody seems to have realized that I was gone. They were thanking me for hosting such a good party. A lot of people left at that point and the remaining people were playing songs and dancing (everyone was dancing all along!). I had no energy left to dance and to join them. They left around 03:00 AM. But I am glad that people enjoyed partying in my room.

This picture was taken when there were few people in my room for the party. Sadhya Thali

On 12 September, we got sadhya thali in lunch. It is vegetarian thali served on banana leaf and served on the eve of Thiruvonam. That day was not thiruvonam but we got a special filling lunch. Rasam and payasam were especially yummy.

Sadhya Thali: A vegetarian meal served on banana leaf. Payasam and rasam were especially yummy! Day trip

13 September was the daytrip. I chose the daytrip Houseboat in Allepey. Suresh also chose the same and we registered for that daytrip as soon as it was open. This was the most preferred daytrip by debconf attendees (80 people registered for it). Our bus was set to leave at 9 AM on 13 September. Me and Suresh woke up at 08:40 and hurried to get the bus in time. It took two hours to reach the venue where we get the houseboat.

The houseboat experience was good. The trip featured some good scenery. I was having experience of the renowned Kerala backwaters. We were served food on the boat. We also stopped at a place and had coconut water. We came back to the place where we boarded the boat by evening.

Group photo of our daytrip. Credits: Radhika Jhalani Lost a good friend during daytrip

When we came back from the daytrip, we got the news that Abhraham Raji died due to drowning. He went to the kayaking daytrip. I am not sure what exactly happened but the story goes that he jumped into the water for swimming and drowned.

Abraham Raji was a very good friend of mine. In my trip to Albania - Kosovo - Dubai last year, he was my roommate in the apartment in Tirana, had lot of discussions during DebConf22 Kosovo and I roamed around in Dubai with him. In fact, the photo of me on the homepage of this blogpost was taken by Abraham. Then I met him in MiniDebConf22 Palakkad and MiniDebConf23 Tamil Nadu. I also went to his flat in Kochi this year in June. Plus we had many projects in common. He was also a Free Software activist and was the designer of the DebConf23 logo. He also designed logos for other debian events in India.

A selfie in memory of Abraham.

We all got pretty shocked by the news. As far as I am concerned, I have still not recovered (9 days after the incident) and still cannot believe it happened. Food does not taste anything and sleep is hard to come by. That night, Anisa and Kristi cheered me up and gave me company. Thanks a lot to them. Next day, Joenio also tried to console me. I thank him for doing a great job. I thank everyone who helped me in coping the difficult situation.

Next day (14 September), Debian project leader Jonathan Carter addressed and announced the news officially. Debian project also published it on their website. In fact, Abraham was supposed to give a talk at that time. All the talks were cancelled on that day. The conference dinner was also cancelled. I was totally devastated!

A visit to Abraham’s house

On 15 September, the conference ran two buses from the hotel to Abraham’s house in Kottayam (2 hours ride). I hopped in the first bus and my mood was not very good. Evangelos (Germany) was sitting in front of me and he started discussing with me. The distraction helped and I was back to normal for a while. Thanks to Evangelos as he supported me a lot on that trip. He was also very impressed by my use of the StreetComplete app which I was using to edit OpenStreetMap.

In two hours, we reached Abraham’s house. Obviously, I bursted into tears and couldn’t control myself. Then I went to see the dead body. I met his family (mother, father and sister). I had nothing to say and I felt helpless. I had no energy left, mainly due to lack of sleep since last few days and my shrinking apetite, so I didn’t think it was good idea for me to stay there. I went back by taking the bus after one hour and had lunch at the hotel. I withdrew my talk scheduled on 16th September.

A Japanese gift

I got a nice Japanese gift from Niibe Yutaka (Japan) - a folder to keep papers which had ancient Japanese manga characters. He said he felt guilty as he swapped his talk with me and so it got rescheduled from 12th September to 16 September which I withdrew later.

Thanks to Niibe Yutaka (the person towards your right hand) from Japan (FSIJ) gave me a wonderful Japanese gift during debconf23: A folder to keep pages with ancient Japanese manga characters printed on it. I realized I immediately needed that :) This is the japanese gift I recieved. Group photo

On 16th September, we had a group photo and I am glad this year I was more clear in the picture than debconf22.

Click to enlarge Volunteer work and talks attended

I went to training for video team and I worked as a camera operator. The Bits from DPL was nice. I enjoyed Abhas’ presentation on home automation. He basically demonstrated how he liberated home devices which work with internet. I also liked Kristi’s presentation on ways to engage with the GNOME community.

Kristi on GNOME community. Abhas' talk on home automation

I also attended lightning talks on the last day. Me, Badri and Wouter gave a demo on how to register on prav app. Prav app also got its fair share of advertising during last few days.

17 September night

On 17 September night, Suresh left the hotel and Badri joined me in my room. That night I wore a mundu (thanks to Abhijit PA, Kiran and Ananthu).

Me in mundu. Picture credits: Abhijith PA

Then I joined Kalyani, Mangesh, Ruchika, Anisa, Ananthu and Kiran. We took pictures and this marked the last night of debconf.

Departure Day

18 September was departure day. Badri slept in my room and left early morning (06:30 AM). I dropped him at the hotel gate. The breakfast was at the eatery (3rd floor) again and it was good.

Me, Sahil, Saswata, Nilesh hanged out sometime at the ground floor.

From left: Nilesh, Saswata, me, Sahil

I had a 8 PM flight from Kochi to Delhi. So I took a cab with Rhonda (Austria), Michael (Nigeria) and Yash (India). We were also joined by other debconf attendees at the Kochi airport. We took another selfie at the airport:

Ruchika (taking the selfie) and from left to right: Yash, Joost (Netherlands), me, Rhonda

Joost had the same flight with me and we sat next to each other. He then took a connecting flight from Delhi to Netherlands. And I went with Yash to New Delhi station and we took our respective trains. I reached home in the morning of 19 September 2023.

Joost and me going to Delhi Big thanks to the organizers

DebConf23 was hard to organize - strict alcohol laws, wierd hotel rules, death of a close friend (almost a family member) and a scary notice by the immigration bureau. People from the team are my close friends and I am proud that they organized such a good event. None of this would have been possible without the organizers who put more than a year long voluntary effort to produce this. In the meanwhile, many of them had organized local events in the run up before debconf.

Shoutout for them.

The organizers also tried their best to get clearance for countries the ministry didn’t approve. I am also sad that people from China, Kosovo, Iran could not join. Especially, I feel bad for people from Kosovo who wanted to attend but could not (as India does not consider their passport as a valid travel document) as we Indians were well received last year in their country.

Note about myself

I am writing this on 22 September 2023 and it took three days to put up this post. This was one of the tragic and hard to write posts for me. I have literally forced myself to write this. I have still not recovered from the loss of my friend. Thanks a lot to all those who helped me.

PS: Credits to contrapuntus for correcting grammatical mistakes.

With user edition out the door last week, this week was spent stabilizing unstable!

Spent some time sorting out our Calamares installer being quite grumpy which is now fixed by reverting an upstream change. Unstable and developer ISO rebuilt and installable. Spent some time sorting out some issues with using an unreleased appstream ( thanks ximion for help with packagekit! ) KDE applications are starting to switch to Qt6 in master this week, the big one being KDE PIM! This entails an enormous amount of work re-packaging. I have made a dent, sorta. To be continued next week. I fixed our signond / kaccounts line for qt6 which entailed some work on upstream code that uses QStringList.toSet which was removed in Qt6! Always learning new things!

I have spent some time working on the KF6 content snap, working with Jarred to make sure his qt6 content snap will work for us. Unfortunately, I do not have much time for this as I must make money to survive, donations help free up time for this Our new proposal with Kevin’s super awesome management company has been submitted and we will hopefully hear back next week.

Thanks for stopping by! Till next week.

If you can spare some change, consider a donation

Thank you!

https://gofund.me/b8b69e54

Almost a month ago, I went to my always loved Rancho Electrónico to celebrate the 30th anniversary of the Debian project. Hats off to Jathan for all the work he put into this! I was there for close to 3hr, and be it following up an install, doing a talk, or whatever — he was doing it. But anyway, I only managed to attend with one of my (great, beautiful and always loved) generic Debian or DebConf T-shirts.

Today, when going through a box of old T-shirts, I found the shirt I was looking for to bring to the occasion. A smallish print, ~12cm wide, over the heart:

And as a larger print, ~25cm wide, across the back:

For the benefit of people who read this using a non-image-displaying browser or RSS client, they are respectively:

10 years 100 countries 1000 maintainers 10000 packages

and

1 project 10 architectures 100 countries 1000 maintainers 10000 packages 100000 bugs fixed 1000000 installations 10000000 users 100000000 lines of code

20 years ago we celebrated eating grilled meat at J0rd1’s house. This year, we had vegan tostadas in the menu. And maybe we are no longer that young, but we are still very proud and happy of our project!

Now… How would numbers line up today for Debian, 20 years later? Have we managed to get the “bugs fixed” line increase by a factor of 10? Quite probably, the lines of code we also have, and I can only guess the number of users and installations, which was already just a wild guess back then, might have multiplied by over 10, at least if we count indirect users and installs as well…

I very, very nearly didn’t make it to DebConf this year, I had a bad cold/flu for a few days before I left, and after a negative covid-19 test just minutes before my flight, I decided to take the plunge and travel.

This is just everything in chronological order, more or less, it’s the only way I could write it.

DebCamp

I planned to spend DebCamp working on various issues. Very few of them actually got done, I spent the first few days in bed further recovering, took a covid-19 test when I arrived and after I felt better, and both were negative, so not sure what exactly was wrong with me, but between that and catching up with other Debian duties, I couldn’t make any progress on catching up on the packaging work I wanted to do. I’ll still post what I intended here, I’ll try to take a few days to focus on these some time next month:

Calamares / Debian Live stuff:

• #980209 – installation fails at the “install boot loader” phase
• #1021156 – calamares-settings-debian: Confusing/generic program names
• #1037299 – “Install Debian” -> “Untrusted application launcher”
• #1037123 – “Minimal HD space required’ too small for some live images”
• #971003– Console auto-login doesn’t work with sysvinit

At least Calamares has been trixiefied in testing, so there’s that!

Desktop stuff:

• #1038660 – please set a placeholder theme during development, different from any release
• #1021816 – breeze: Background image not shown any more
• #956102 – desktop-base: unwanted metadata within images
• #605915 – please mtheake it a non-native package
• #681025 – Put old themes in a new package named desktop-base-extra
• #941642 – desktop-base: split theme data files and desktop integrations in separate packages

The “Egg” theme that I want to develop for testing/unstable is based on Juliette Taka’s Homeworld theme that was used for Bullseye. Egg, as in, something that hasn’t quite hatched yet. Get it? (for #1038660)

Debian Social:

• Set up Lemmy instance
  • I started setting up a Lemmy instance before DebCamp, and meant to finish it.
• Migrate PeerTube to new server
  • We got a new physical server for our PeerTube instance, we should have more space for growth and it would help us fix the streaming feature on our platform.

Loopy:

I intended to get the loop for DebConf in good shape before I left, so that we can spend some time during DebCamp making some really nice content, unfortunately this went very tumbly, but at least we ended up with a loopy that kind of worked and wasn’t too horrible. There’s always another DebConf to try again, right?

So DebCamp as a usual DebCamp was pretty much a wash (fitting with all the rain we had?) for me, at least it gave me enough time to recover a bit for DebConf proper, and I had enough time left to catch up on some critical DPL duties and put together a few slides for the Bits from the DPL talk.

DebConf

Bits From the DPL

I had very, very little available time to prepare something for Bits fro the DPL, but I managed to put some slides together (available on my wiki page).

I mostly covered:

• A very quick introduction of myself (I’ve done this so many times, it feels redundant giving my history every time), and some introduction on what it is that the DPL does. I declared my intent not to run for DPL again, and the reasoning behind it, and a few bits of information for people who may intend to stand for DPL next year.
• The sentiment out there for the Debian 12 release (which has been very positive). How we include firmware by default now, and that we’re saying goodbye to architectures both GNU/KFreeBSD and mipsel.
• Debian Day and the 30th birthday party celebrations from local groups all over the world (and a reminder about the Local Groups BoF later in the week).
• I looked forward to Debian 13 (trixie!), and how we’re gaining riscv64 as a release architecture, as well as loongarch64, and that plans seem to be forming to fix 2k38 in Debian, and hopefully largely by the time the Trixie release comes by.
• I made some comments about “Enterprise Linux” as people refer to the RHEL eco-system these days, how really bizarre some aspects of it is (like the kernel maintenance), and that some big vendors are choosing to support systems outside of that eco-system now (like CPanel now supporting Ubuntu too). I closed with the quote below from Ian Murdock, and assured the audience that if they want to go out and make money with Debian, they are more than welcome too.

Job Fair

I walked through the hallway where the Job Fair was hosted, and enjoyed all the buzz. It’s not always easy to get this right, but this year it was very active and energetic, I hope lots of people made some connections!

Cheese & Wine

Due to state laws and alcohol licenses, we couldn’t consume alcohol from outside the state of Kerala in the common areas of the hotel (only in private rooms), so this wasn’t quite as big or as fun as our usual C&W parties since we couldn’t share as much from our individual countries and cultures, but we always knew that this was going to be the case for this DebConf, and it still ended up being alright.

Day Trip

I opted for the forest / waterfalls daytrip. It was really, really long with lots of time in the bus. I think our trip’s organiser underestimated how long it would take between the points on the route (all in all it wasn’t that far, but on a bus on a winding mountain road, it takes long). We left at 8:00 and only found our way back to the hotel around 23:30. Even though we arrived tired and hungry, we saw some beautiful scenery, animals and also met indigenous river people who talked about their struggles against being driven out of their place of living multiple times as government invests in new developments like dams and hydro power.

Photos available in the DebConf23 public git repository.

Losing a beloved Debian Developer during DebConf

To our collective devastation, not everyone made it back from their day trips. Abraham Raji was out to the kayak day trip, and while swimming, got caught by a whirlpool from a drainage system.

Even though all of us were properly exhausted and shocked in disbelief at this point, we had to stay up and make some tough decisions. Some initially felt that we had to cancel the rest of DebConf. We also had to figure out how to announce what happened asap both to the larger project and at DebConf in an official manner, while ensuring that due diligence took place and that the family is informed by the police first before making anything public.

We ended up cancelling all the talks for the following day, with an address from the DPL in the morning to explain what had happened. Of all the things I’ve ever had to do as DPL, this was by far the hardest. The day after that, talks were also cancelled for the morning so that we could attend his funeral. Dozens of DebConf attendees headed out by bus to go pay their final respects, many wearing the t-shirts that Abraham had designed for DebConf.

A book of condolences was set up so that everyone who wished to could write a message on how they remembered him. The book will be kept by his family.

Today marks a week since his funeral, and I still feel very raw about it. And even though there was uncertainty whether DebConf should even continue after his death, in hindsight I’m glad that everyone pushed forward. While we were all heart broken, it was also heart warming to see people care for each other in all of this. If anything, I think I needed more time at DebConf just to be in that warm aura of emotional support for just a bit longer. There are many people who I wanted to talk to who I barely even had a chance to see.

Abraham, or Abru as he was called by some people (which I like because “bru” in Afrikaans” is like “bro” in English, not sure if that’s what it implied locally too) enjoyed artistic pursuits, but he was also passionate about knowledge transfer. He ran classes at DebConf both last year and this year (and I think at other local events too) where he taught people packaging via a quick course that he put together. His enthusiasm for Debian was contagious, a few of the people who he was mentoring came up to me and told me that they were going to see it through and become a DD in honor of him. I can’t even remember how I reacted to that, my brain was already so worn out and stitching that together with the tragedy of what happened while at DebConf was just too much for me.

I first met him in person last year in Kosovo, I already knew who he was, so I think we interacted during the online events the year before. He was just one of those people who showed so much promise, and I was curious to see what he’d achieve in the future. Unfortunately, we was taken away from us too soon.

Poetry Evening

Later in the week we had the poetry evening. This was the first time I had the courage to recite something. I read Ithaka by C.P. Cavafy (translated by Edmund Keely). The first time I heard about this poem was in an interview with Julian Assange’s wife, where she mentioned that he really loves this poem, and it caught my attention because I really like the Weezer song “Return to Ithaka” and always wondered what it was about, so needless to say, that was another rabbit hole at some point.

Group Photo

Our DebConf photographer organised another group photo for this event, links to high-res versions available on Aigar’s website.

BoFs

I didn’t attend nearly as many talks this DebConf as I would’ve liked (fortunately I can catch up on video, should be released soon), but I did make it to a few BoFs.

In the Local Groups BoF, representatives from various local teams were present who introduced themselves and explained what they were doing. From memory (sorry if I left someone out), we had people from Belgium, Brazil, Taiwan and South Africa. We talked about types of events a local group could do (BSPs, Mini DC, sprints, Debian Day, etc. How to help local groups get started, booth kits for conferences, and setting up some form of calendar that lists important Debian events in a way that makes it easier for people to plan and co-ordinate. There’s a mailing list for co-ordination of local groups, and the irc channel is #debian-localgroups on oftc.

If you got one of these Cheese & Wine bags from DebConf, that’s from the South African local group!

In the Debian.net BoF, we discussed the Debian.net hosting service, where Debian pays for VMs hosted for projects by individual DDs on Debian.net. The idea is that we start some form of census that monitors the services, whether they’re still in use, whether the system is up to date, whether someone still cares for it, etc. We had some discussion about where the lines of responsibility are drawn, and we can probably make things a little bit more clear in the documentation. We also want to offer more in terms of backups and monitoring (currently DDs do get 500GB from rsync.net that could be used for backups of their services though). The intention is also to deploy some form of configuration management for some essentials across the hosts. We should also look at getting some sponsored hosting for this.

In the Debian Social BoF, we discussed some services that need work / expansion. In particular, Matrix keeps growing at an increased rate as more users use it and more channels are bridged, so it will likely move to its own host with big disks soon. We might replace Pleroma with a fork called Akkoma, this will need some more home work and checking whether it’s even feasible. Some services haven’t really been used (like Writefreely and Plume), and it might be time to retire them. We might just have to help one or two users migrate some of their posts away if we do retire them. Mjolner seems to do a fine job at spam blocking, we haven’t had any notable incidents yet. WordPress now has improved fediverse support, it’s unclear whether it works on a multi-site instance yet, I’ll test it at some point soon and report back. For upcoming services, we are implementing Lemmy and probably also Mobilizon. A request was made that we also look into Loomio.

More Information Overload

There’s so much that happens at DebConf, it’s tough to take it all in, and also, to find time to write about all of it, but I’ll mention a few more things that are certainly worth of note.

During DebConf, we had some people from the Kite Linux team over. KITE supplies the ICT needs for the primary and secondary schools in the province of Kerala, where they all use Linux. They decided to switch all of these to Debian. There was an ad-hoc BoF where locals were listening and fielding questions that the Kite Linux team had. It was great seeing all the energy and enthusiasm behind this effort, I hope someone will properly blog about this!

I learned about the VGLUG Foundation, who are doing a tremendous job at promoting GNU/Linux in the country. They are also training up 50 people a year to be able to provide tech support for Debian.

I came across the booth for Mostly Harmless, they liberate old hardware by installing free firmware on there. It was nice seeing all the devices out there that could be liberated, and how it can breathe new life into old harware.

Some hopefully harmless soldering.

Overall, the community and their activities in India are very impressive, and I wish I had more time to get to know everyone better.

Food

Oh yes, one more thing. The food was great. I tasted more different kinds of curry than I ever did in my whole life up to this point. The lunch on banana leaves was interesting, and also learning how to eat this food properly by hand (thanks to the locals who insisted on teaching me!), it was a… fruitful experience? This might catch on at home too… less dishes to take care of!

Special thanks to the DebConf23 Team

I think this may have been one of the toughest DebConfs to organise yet, and I don’t think many people outside of the DebConf team knows about all the challenges and adversity this team has faced in organising it. Even just getting to the previous DebConf in Kosovo was a long and tedious and somewhat risky process. Through it all, they were absolute pro’s. Not once did I see them get angry or yell at each other, whenever a problem came up, they just dealt with it. They did a really stellar job and I did make a point of telling them on the last day that everyone appreciated all the work that they did.

Back to my nest

I bought Dax a ball back from India, he seems to have forgiven me for not taking him along.

I’ll probably take a few days soon to focus a bit on my bugs and catch up on my original DebCamp goals. If you made it this far, thanks for reading! And thanks to everyone for being such fantastic people.

(I wrote this up for an internal work post, but I figure it’s worth sharing more publicly too.)

I spent last week at DebConf23, this years instance of the annual Debian conference, which was held in Kochi, India. As usual, DebConf provides a good reason to see a new part of the world; I’ve been going since 2004 (Porto Alegre, Brazil), and while I’ve missed a few (Mexico, Bosnia, and Switzerland) I’ve still managed to make it to instances on 5 continents.

This has absolutely nothing to do with work, so I went on my own time + dime, but I figured a brief write-up might prove of interest. I first installed Debian back in 1999 as a machine that was being co-located to operate as a web server / email host. I was attracted by the promise of easy online upgrades (or, at least, upgrades that could be performed without the need to be physically present at the machine, even if they naturally required a reboot at some point). It has mostly delivered on this over the years, and I’ve never found a compelling reason to move away. I became a Debian Developer in 2000. As a massively distributed volunteer project DebConf provides an opportunity to find out what’s happening in other areas of the project, catch up with team mates, and generally feel more involved and energised to work on Debian stuff. Also, by this point in time, a lot of Debian folk are good friends and it’s always nice to catch up with them.

On that point, I felt that this year the hallway track was not quite the same as usual. For a number of reasons (COVID, climate change, travel time, we’re all getting older) I think fewer core teams are achieving critical mass at DebConf - I was the only member physically present from 2 teams I’m involved in, and I’d have appreciated the opportunity to sit down with both of them for some in-person discussions. It also means it’s harder to use DebConf as a venue for advancing major changes; previously having all the decision makers in the same space for a week has meant it’s possible to iron out the major discussion points, smoothing remote implementation after the conference. I’m told the mini DebConfs are where it’s at for these sorts of meetings now, so perhaps I’ll try to attend at least one of those next year.

Of course, I also went to a bunch of talks. I have differing levels of comment about each of them, but I’ve written up some brief notes below about the ones I remember something about. The comment was made that we perhaps had a lower level of deep technical talks, which is perhaps true but I still think there were a number of high level technical talks that served to pique ones interest about the topic.

Finally, this DebConf was the first I’m aware of that was accompanied by tragedy; as part of the day trip Abraham Raji, a project member and member of the local team, was involved in a fatal accident.

Talks (videos not yet up for all, but should appear for most)

• Opening Ceremony
  Not much to say here; welcome to DebConf!

• Continuous Key-Signing Party introduction
  I ended up running this, as Gunnar couldn’t make it. Debian makes heavy use of the OpenPGP web of trust (no mass ability to send out Yubikeys + perform appropriate levels of identity verification), so making sure we’re appropriately cross-signed, and linked to local conference organisers, is a dull but important part of the conference. We use a modified keysigning approach where identity verification + fingerprint confirmation happens over the course of the conference, so this session was just to explain how that works and confirm we were all working from the same fingerprint list.

• State of Stateless - A Talk about Immutability and Reproducibility in Debian
  Stateless OSes seem to be gaining popularity, so I went along to this to see if there was anything of note. It was interesting, but nothing earth shattering - very high level.

• What’s missing so that Debian is finally reproducible?
  Reproducible builds are something I’ve been keeping an eye on for a long time, and I continue to be impressed by the work folks are putting into this - both for Debian, and other projects. From a security standpoint reproducible builds provide confidence against trojaned builds, and from a developer standpoint knowing you can build reproducibly helps with not having to keep a whole bunch of binary artefacts around.

• Hello from keyring-maint
  In the distant past the process of getting your OpenPGP key into the Debian keyring (which is used to authenticate uploads + votes, amongst other things) was a clunky process that was often stalled. This hasn’t been the case for at least the past 10 years, but there’s still a residual piece of project memory that thinks keyring is a blocker. So as a team we say hi and talk about the fact we do monthly updates and generally are fairly responsive these days.

• A declarative approach to Linux networking with Netplan
  Debian’s /etc/network/interfaces is a fairly basic (if powerful) mechanism for configuring network interfaces. NetworkManager is a better bet for dynamic hosts (i.e. clients), and systemd-network seems to be a good choice for servers (I’m gradually moving machines over to it). Netplan tries to provide a unified mechanism for configuring both with a single configuration language. A noble aim, but I don’t see a lot of benefit for anything I use - my NetworkManager hosts are highly dynamic (so no need to push shared config) and systemd-network (or /etc/network/interfaces) works just fine on the other hosts. I’m told Netplan has more use with more complicated setups, e.g. when OpenVSwitch is involved.

• Quick peek at ZFS, A too good to be true file system and volume manager.
  People who use ZFS rave about it. I’m naturally suspicious of any file system that doesn’t come as part of my mainline kernel. But, as a longtime cautious mdraid+lvm+ext4 user I appreciate that there have been advances in the file system space that maybe I should look at, and I’ve been trying out btrfs on more machines over the past couple of years. I can’t deny ZFS has a bunch of interesting features, but nothing I need/want that I can’t get from an mdraid+lvm+btrfs stack (in particular data checksumming + reflinks for dedupe were strong reasons to move to btrfs over ext4).

• Bits from the DPL
  Exactly what it says on the tin; some bits from the DPL.

• Adulting
  Enrico is always worth hearing talk; Adulting was no exception. Main takeaway is that we need to avoid trying to run the project on martyrs and instead make sure we build a sustainable project. I’ve been trying really hard to accept I just don’t have time to take on additional responsibilities, no matter how interesting or relevant they might seem, so this resonated.

• My life in git, after subversion, after CVS.
  Putting all of your home directory in revision control. I’ve never made this leap; I’ve got some Ansible playbooks that push out my core pieces of configuration, which is held in git, but I don’t actually check this out directly on hosts I have accounts on. Interesting, but not for me.

• EU Legislation BoF - Cyber Resilience Act, Product Liability Directive and CSAM Regulation
  The CRA seems to be a piece of ill informed legislation that I’m going to have to find time to read properly. Discussion was a bit more alarmist than I personally feel is warranted, but it was a short session, had a bunch of folk in it, and even when I removed my mask it was hard to make myself understood.

• What’s new in the Linux kernel (and what’s missing in Debian)
  An update from Ben about new kernel features. I’m paying less attention to such things these days, so nice to get a quick overview of it all.

• Intro to SecureDrop, a sort-of Linux distro
  Actually based on Ubuntu, but lots of overlap with Debian as a result, and highly customised anyway. Notable, to me, for using OpenPGP as some of the backend crypto support. I managed to talk to Kunal separately about some of the pain points around that, which was an interesting discussion - they’re trying to move from GnuPG to Sequoia, primarily because of the much easier integration and lack of requirement for the more complicated GnuPG features that sometimes get in the way.

• The Docker(.io) ecosystem in Debian
  I hate Docker. I’m sure it’s fine if you accept it wants to take over the host machine entirely, but when I’ve played around with it that’s not been the case. This talk was more about the difficulty of trying to keep a fast moving upstream with lots of external dependencies properly up to date in a stable release. Vendoring the deps and trying to get a stable release exception seems like the least bad solution, but it’s a problem that affects a growing number of projects.

• Chiselled containers
  This was kinda of interesting, but I think I missed the piece about why more granular packaging wasn’t an option. The premise is you can take an existing .deb and “chisel” it into smaller components, which then helps separate out dependencies rather than pulling in as much as the original .deb would. This was touted as being useful, in particular, for building targeted containers. Definitely appealing over custom built userspaces for containers, but in an ideal world I think we’d want the information in the main packaging and it becomes a lot of work.

• Debian Contributors shake-up
  Debian Contributors is a great site for massaging your ego around contributions to Debian; it’s also a useful point of reference from a data protection viewpoint in terms of information the project holds about contributors - everything is already public, but the Contributors website provides folk with an easy way to find their own information (with various configurable options about whether that’s made public or not). Tássia is working on improving the various data feeds into the site, but realistically this is the responsibility of every Debian service owner.

• New Member BOF
  I’m part of the teams that help get new folk into Debian - primarily as a member of the New Member Front Desk, but also as a mostly inactive Application Manager. It’s been a while since we did one of these sessions so the Front Desk/Debian Account Managers that were present did a panel session. Nothing earth shattering came out of it; like keyring-maint this is a team that has historically had problems, but is currently running smoothly.

just testing, please ignore

The still new package RcppInt64 (announced two weeks ago in this post, with this followup last week) arrived on CRAN earlier today in its second update and relase 0.0.3. RcppInt64 collects some of the previous conversions between 64-bit integer values in R and C++, and regroups them in a single package by providing a single header. It offers two interfaces: both a more standard as<>() converter from R values along with its companions wrap() to return to R, as well as more dedicated functions ‘from’ and ‘to’.

This release adds support for the corresponding nanotime conversion between R and C++. nanotime is leveraging the same bit64-based reprensentation of 64-bit integers for nanosecond resolution timestamps. A thorough S4 wrapping the offers R based access for convenient and powerful operations at nanosecond resolution. And as tweeted (here and here), tooted (here and here), and skeeted (here and here) in a quick preview last Sunday, it makes for easy and expressive code.

The brief NEWS entry follows:

Changes in version 0.0.3 (2023-09-19)

• The as<>() and wrap() converters are now declared inline.

• Conversion to and from nanotime has been added.

Courtesy of my CRANberries, there is a diffstat report relative to previous release.

If you like this or other open-source work I do, you can sponsor me at GitHub.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

live demo

As far as I know this is the first Haskell program compiled to Webassembly (WASM) and using the browser DOM.

ghc's WASM backend is solid, but it only provides very low-level FFI bindings when used in the browser. Ints and pointers to WASM memory. (See here for details and for instructions on getting the ghc WASM toolchain I used.)

I imagine that in the future, WASM code will interface with the DOM by using a WASI "world" that defines a complete API (and browsers won't include Javascript engines anymore). But currently, WASM can't do anything in a browser without calling back to Javascript.

For this project, I needed 63 lines of (reusable) javascript (here). Plus another 18 to bootstrap running the WASM program (here). (Also browser_wasi_shim)

But let's start with the Haskell code. A simple program to pop up an alert in the browser looks like this:

{-# LANGUAGE OverloadedStrings #-} import Wasmjsbridge foreign export ccall hello :: IO () hello :: IO () hello = do alert <- get_js_object_method "window" "alert" call_js_function_ByteString_Void alert "hello, world!"

A larger program that draws on the canvas and generated the image above is here.

The Haskell side of the FFI interface is a bunch of fairly mechanical functions like this:

foreign import ccall unsafe "call_js_function_string_void" _call_js_function_string_void :: Int -> CString -> Int -> IO () call_js_function_ByteString_Void :: JSFunction -> B.ByteString -> IO () call_js_function_ByteString_Void (JSFunction n) b = BU.unsafeUseAsCStringLen b $ \(buf, len) -> _call_js_function_string_void n buf len

Many more would need to be added, or generated, to continue down this path to complete coverage of all data types. All in all it's 64 lines of code so far (here).

Also a C shim is needed, that imports from WASI modules and provides C functions that are used by the Haskell FFI. It looks like this:

void _call_js_function_string_void(uint32_t fn, uint8_t *buf, uint32_t len) __attribute__(( __import_module__("wasmjsbridge"), __import_name__("call_js_function_string_void") )); void call_js_function_string_void(uint32_t fn, uint8_t *buf, uint32_t len) { _call_js_function_string_void(fn, buf, len); }

Another 64 lines of code for that (here). I found this pattern in Joachim Breitner's haskell-on-fastly and copied it rather blindly.

Finally, the Javascript that gets run for that is:

call_js_function_string_void(n, b, sz) { const fn = globalThis.wasmjsbridge_functionmap.get(n); const buffer = globalThis.wasmjsbridge_exports.memory.buffer; fn(decoder.decode(new Uint8Array(buffer, b, sz))); },

Notice that this gets an identifier representing the javascript function to run, which might be any method of any object. It looks it up in a map and runs it. And the ByteString that got passed from Haskell has to be decoded to a javascript string.

In the Haskell program above, the function is document.alert. Why not pass a ByteString with that through the FFI? Well, you could. But then it would have to eval it. That would make running WASM in the browser be evaling Javascript every time it calls a function. That does not seem like a good idea if the goal is speed. GHC's javascript backend does use Javascript`FFI snippets like that, but there they get pasted into the generated Javascript hairball, so no eval is needed.

So my code has things like get_js_object_method that look up things like Javascript functions and generate identifiers. It also has this:

call_js_function_ByteString_Object :: JSFunction -> B.ByteString -> IO JSObject

Which can be used to call things like document.getElementById that return a javascript object:

getElementById <- get_js_object_method (JSObjectName "document") "getElementById" canvas <- call_js_function_ByteString_Object getElementById "myCanvas"

Here's the Javascript called by get_js_object_method. It generates a Javascript function that will be used to call the desired method of the object, and allocates an identifier for it, and returns that to the caller.

get_js_objectname_method(ob, osz, nb, nsz) { const buffer = globalThis.wasmjsbridge_exports.memory.buffer; const objname = decoder.decode(new Uint8Array(buffer, ob, osz)); const funcname = decoder.decode(new Uint8Array(buffer, nb, nsz)); const func = function (...args) { return globalThis[objname][funcname](...args) }; const n = globalThis.wasmjsbridge_counter + 1; globalThis.wasmjsbridge_counter = n; globalThis.wasmjsbridge_functionmap.set(n, func); return n; },

This does mean that every time a Javascript function id is looked up, some more memory is used on the Javascript side. For more serious uses of this, something would need to be done about that. Lots of other stuff like object value getting and setting is also not implemented, there's no support yet for callbacks, and so on. Still, I'm happy where this has gotten to after 12 hours of work on it.

I might release the reusable parts of this as a Haskell library, although it seems likely that ongoing development of ghc will make it obsolete. In the meantime, clone the git repo to have a play with it.

This blog post was sponsored by unqueued on Patreon.

Posted on September 20, 2023

And another half-written article I had in my repo. (Am I doing #FallFinishAlong with blog articles instead of / in addition to craft projects? it feels so).

I was in need of snacks. I wanted something bready, but with a bit less carbs and more proteins. I had a bag of chickpea flour.

Ingredients were:

• 100 g wheat flour
• 100 g chickpea flour
• 100 g water
• 3 g salt
• 1 g dry yeast

Mix everything as usual for bread, leave to rise for 4-6 hours.

Divide in 4 parts, roll them out to a thickness of about 1 – 2 mm, prick them with a fork (or the fancy cracker pricking tool that you don’t really need but I may have bought).

Optionally spray with a bit of water and sprinkle with salt (coarse or flake is best).

Preheat the oven to 240°C and cook for 5 minutes, or preheat the oven to 210°C and cook for 10 minutes for a dryer version.

I’ve tried both cooking temperatures: the 210°C had the big advantage of being the same as the common bread I was already making, so no additional oven time was required (it was summer. this was a consideration.), but I’m not sure which version I like best, so I think in winter I will alternate between the two.

Put it in a cotton (linen?) bag and keep it in a dry place, where it will keep for weeks (assuming you’ve made a bigger batch :D ).

This is now part of my staples.

Posted on September 19, 2023

I’ve found the draft of this article I almost completely wrote (checks) more than 3 months ago, and I guess it’s time to finish and publish it.

The very first A10 based device that entered our home, before they started to use it for SBCs, was a Chinese media server with a slot for a 3.5" hard disk and a few analogue audio outputs.

Of course from the time it entered our home it has always been running Debian.

Now that we may have a few, more powerful, A20 SBCs available, it has been fully dedicated to music: it is connected to the stereo, the hard disk has a clone of the git-annex repository where I’ve ripped all of my CDs1 and is played by connecting via ssh and running alsaplayer.

It’s simple (for my tastes). it works. Unless you’re in a different room than the one with the stereo.

And then I read this post on the fediverse that suggested installing minidlna on an old Raspberry Pi, and on a whim I decided I needed it.

I installed the package from Debian, set a few easy settings in the configuration file (such as which directories to serve), restarted the service.

And that’s it, it just worked.

The only thing I had to take care about is that to use git-annex repositories as the source of media files either the root of the repository should be used as media-dir, or the wide_links options should be set to yes, otherwise the symbolic links that point outside of the media-dir won’t be served.

As a client I used VLC (note for myself in case I ever forget, it’s under View → Playlist and then Local Network → Universal Plug ‘n’ Play), mostly because I already had it around.

Now that I’ve used it for a few months I have to say that it isn’t a perfect solution: the main format I store my music in is in flac 2, which isn’t supported by dlna; for a significant part of it I’ve also already generated single-song ogg files for convenience 3, and at least it works for those.

I don’t store (yet?) my video collection on the A10 device, but I did a quick test, and no, of course a raw dump of a DVD as generated by dvdbackup isn’t supported, so I would have to convert those too. And there is some support for subtitles as a separate file (which is something else I tend to have around), but only one file, with strict requirements for the name, which is a bit restrictive.

On the other hand, the hassle to set this up was so low that the functionality / hassle ratio is most definitely worth, and I’m quite happy I did and plan to continue using it.

1. (yes, I’m still using CDs, I have objections to those newfangled streaming services)↩︎

2. full CD rip in a single file, with an embedded cuesheet, to preserve as much as possible of the original disc.↩︎

3. in theory the flac was supposed to be future-proof storage, with the ogg files for actual use, but then I always listen to full albums, so the flac just work, and I only tend to bother generating the ogg when I’m already generating mp3 for the car.↩︎

I'm writing hash tables again; it seemingly never goes out of fashion. (Like malloc or sorting, we can always improve the implementation of these super-old concepts.) There are so many different tradeoffs you can make, and I thought it would be interesting to summarize the options on one of them: Hash reductions. I.e., you have your hash value (assume it's 32 bits, but this generalizes readily) and want to figure out which of N buckets this reduces to; what do you choose? (I'll assume a standard open-addressing scheme with linear probing, but most of this can be adapted to pretty much anything.) As far as I know, your options are:

• Mask lower bits: Something like x & (N - 1), where N is the table size. Assumptions: N is a power of two. Advantages: Super-fast. Probably the preferred variation of every gung-ho coder out there, very widely used. Problems: The lower bits of your hash must be of good quality (all others are discarded). Power-of-two requirement can mean lower load factor, and can be problematic for very large tables (e.g. if you have 64 GB RAM, you may want to support 60 GB hash tables and not just 32).
• Modulo prime: x % N. Assumptions: Generally that N is a prime (there's no big reason not to make it so). Advantages: Flexible on table size. Uses all bits of the hash, so is fairly robust against bad hash functions (the only big problem is if your hash is always a multiple of N, really). Disadvantages: Modulo is frequently slow, especially on older or less powerful CPUs. If you have fast multiplication, you can get around it by precomputation and numerical tricks, to a certain extent.
• Fibonacci hashing: (x * q) >> (32 - B), where q is some magic constant (usually a prime close to the inverse of the golden ratio, but other values can work well, too), and S is the number of bits you want. Assumptions: N is a power of two. Advantages: Much better hash mixing than just masking (enough that it often can compensate for a bad hash, or just hash integers directly). Faster than the modulo option. Problems: Needs fast multiplication and variable-length shifts, and again, the power-of-two demand may be a problem.
• Range partition: ((uint64_t)x * N) >> 32. (It's surprising that it works, but essentially, you consider x as a 0.32 fixed-point number [0,1), multiply by N and then truncate. Popularized by Daniel Lemire.) Assumptions: You have access to a “high mul” somehow, either through 64-bit muls or a CPU that will give you high and low parts of the result separately (this is common, although not all compilers have perfect code generation here). Advantages: Fast, even more so if the high mul gives you the shift for free. Completely arbitrary table size. Problems: Need fast high-mul. Assumes the high bits of the hash are of good quality, analogous to the issue with masking off the lower bits.

In a sense, my favorite is the range partition one. But it puts some trust in your hash, so it might not be the best for e.g. a generic library implementation.

On Sunday 17 September 2023, the annual Debian Developers and Contributors Conference came to a close.

Over 474 attendees representing 35 countries from around the world came together for a combined 89 events made up of Talks, Discussons, Birds of a Feather (BoF) gatherings, workshops, and activities in support of furthering our distribution, learning from our mentors and peers, building our community, and having a bit of fun.

The conference was preceded by the annual DebCamp hacking session held September 3d through September 9th where Debian Developers and Contributors convened to focus on their Individual Debian related projects or work in team sprints geared toward in-person collaboration in developing Debian.

In particular this year Sprints took place to advance development in Mobian/Debian, Reproducible Builds, and Python in Debian. This year also featured a BootCamp that was held for newcomers staged by a team of dedicated mentors who shared hands-on experience in Debian and offered a deeper understanding of how to work in and contribute to the community.

The actual Debian Developers Conference started on Sunday 10 September 2023.

In addition to the traditional 'Bits from the DPL' talk, the continuous key-signing party, lightning talks and the announcement of next year's DebConf4, there were several update sessions shared by internal projects and teams.

Many of the hosted discussion sessions were presented by our technical teams who highlighted the work and focus of the Long Term Support (LTS), Android tools, Debian Derivatives, Debian Installer, Debian Image, and the Debian Science teams. The Python, Perl, and Ruby programming language teams also shared updates on their work and efforts.

Two of the larger local Debian communities, Debian Brasil and Debian India shared how their respective collaborations in Debian moved the project forward and how they attracted new members and opportunities both in Debian, F/OSS, and the sciences with their HowTos of demonstrated community engagement.

The schedule was updated each day with planned and ad-hoc activities introduced by attendees over the course of the conference. Several activities that were unable to be held in past years due to the Global COVID-19 Pandemic were celebrated as they returned to the conference's schedule: a job fair, the open-mic and poetry night, the traditional Cheese and Wine party, the group photos and the Day Trips.

For those who were not able to attend, most of the talks and sessions were videoed for live room streams with the recorded videos to be made available later through the Debian meetings archive website. Almost all of the sessions facilitated remote participation via IRC messaging apps or online collaborative text documents which allowed remote attendees to 'be in the room' to ask questions or share comments with the speaker or assembled audience.

DebConf23 saw over 4.3 TiB of data streamed, 55 hours of scheduled talks, 23 network access points, 11 network switches, 75 kb of equipment imported, 400 meters of gaffer tape used, 1,463 viewed streaming hours, 461 T-shirts, 35 country Geoip viewers, 5 day trips, and an average of 169 meals planned per day.

All of these events, activies, conversations, and streams coupled with our love, interest, and participation in Debian annd F/OSS certainly made this conference an overall success both here in Kochi, India and On-line around the world.

The DebConf23 website will remain active for archival purposes and will continue to offer links to the presentations and videos of talks and events.

Next year, DebConf24 will be held in Haifa, Israel. As tradition follows before the next DebConf the local organizers in Israel will start the conference activites with DebCamp with particular focus on individual and team work towards improving the distribution.

DebConf is committed to a safe and welcome environment for all participants. See the web page about the Code of Conduct in DebConf23 website for more details on this.

Debian thanks the commitment of numerous sponsors to support DebConf23, particularly our Platinum Sponsors: Infomaniak, Proxmox, and Siemens.

We also wish to thank our Video and Infrastructure teams, the DebConf23 and DebConf commitiees, our host nation of India, and each and every person who helped contribute to this event and to Debian overall.

Thank you all for your work in helping Debian continue to be "The Universal Operating System".

See you next year!

About Debian

The Debian Project was founded in 1993 by Ian Murdock to be a truly free community project. Since then the project has grown to be one of the largest and most influential open source projects. Thousands of volunteers from all over the world work together to create and maintain Debian software. Available in 70 languages, and supporting a huge range of computer types, Debian calls itself the universal operating system.

About DebConf

DebConf is the Debian Project's developer conference. In addition to a full schedule of technical, social and policy talks, DebConf provides an opportunity for developers, contributors and other interested people to meet in person and work together more closely. It has taken place annually since 2000 in locations as varied as Scotland, Argentina, and Bosnia and Herzegovina. More information about DebConf is available from https://debconf.org/.

About Infomaniak

Infomaniak is a key player in the European cloud market and the leading developer of Web technologies in Switzerland. It aims to be an independent European alternative to the web giants and is committed to an ethical and sustainable Web that respects privacy and creates local jobs. Infomaniak develops cloud solutions (IaaS, PaaS, VPS), productivity tools for online collaboration and video and radio streaming services.

About Proxmox

Proxmox develops powerful, yet easy-to-use open-source server software. The product portfolio from Proxmox, including server virtualization, backup, and email security, helps companies of any size, sector, or industry to simplify their IT infrastructures. The Proxmox solutions are based on the great Debian platform, and we are happy that we can give back to the community by sponsoring DebConf23.

About Siemens

Siemens is technology company focused on industry, infrastructure and transport. From resource-efficient factories, resilient supply chains, smarter buildings and grids, to cleaner and more comfortable transportation, and advanced healthcare, the company creates technology with purpose adding real value for customers. By combining the real and the digital worlds, Siemens empowers its customers to transform their industries and markets, helping them to enhance the everyday of billions of people.

Contact Information

For further information, please visit the DebConf23 web page at https://debconf23.debconf.org/ or send mail to press@debian.org.