Samuel Henrique (samueloph)

Bringing HTTP/3 to curl on Amazon Linux

2026-04-02T00:00:00+00:00

[email protected]> - 8.17.0-1.amzn2023.0.2 - Enable HTTP/3 support in the full build using ngtcp2 and nghttp3 - HTTP/3 is explicitly disabled in the minimal build - Add runtime dependencies on libnghttp3 and libngtcp2 with minimum version pinning - Run tests in parallel via upstream make test-nonflaky, with serial fallback for race-prone tests" width="1596" height="226" loading="lazy" />

tl;dr</h4>

Starting with curl 8.17.0-1.amzn2023.0.2 in Amazon Linux 2023, you can now use HTTP/3.

dnf</span> swap</span> -y</span> libcurl-minimal libcurl-full</span></span>
dnf</span> swap</span> -y</span> curl-minimal curl-full</span></span>
curl</span> --http3-only</span> https://example.com</span></span></code></pre>
(HTTP/3 is only enabled in the curl -full builds)</em></p>
Or, if you would like to try it out in a container:</p>
podman</span> run amazonlinux:2023 /bin/sh</span> -c</span> '</span>dnf upgrade -y --releasever=latest && dnf swap -y libcurl-minimal libcurl-full && dnf swap -y curl-minimal curl-full && curl --http3-only https://example.com</span>'</span></span></code></pre>
For a list of test endpoints, you can refer to
https://bagder.github.io/HTTP3-test/</a></p>
The Upgrade I Didn't Have to Make</h1>
My teammate Steve Zarkos, who previously worked on upgrading OpenSSL in Amazon
Linux from 3.0 to 3.2, spent the last few months on the complex task of bumping
OpenSSL again, this time to 3.5. A bump like this only happens after extensive
code analysis and testing, something that I didn't foresee happening when
AL2023 was released but that was a notable request from users.</p>
Having enabled HTTP/3 on
Debian</a>, I was
always keeping an eye on when I would get to do the same for Amazon Linux (mind
you, I work at AWS, in the Amazon Linux org). The bump to OpenSSL 3.5 was the
perfect opportunity to do that, for the first time Amazon Linux is shipping an
OpenSSL version that is supported by ngtcp2 for HTTP/3 support.</p>
Non-Intrusive Change</h1>
In order to avoid any intrusive changes to existing users of AL2023, I've only
enabled HTTP/3 in the full build of curl, not in the minimal one, this means
there is no change for the minimal images.</p>
The way curl handles HTTP/3 today also does not lead to any behavior changes
for those who have the full variants of curl installed, this is due to the fact
that HTTP/3 is only used if the user explicitly asks for it with the flags
--http3</code> or --http3-only</code>.</p>
Side Quests</h1>
Supporting HTTP/3 on curl also requires building it with ngtcp2 and nghttp3,
two packages which were not shipped in Amazon Linux, besides, my team doesn't
even own the curl package, we are a security team so our packages are the
security related stuff such as OpenSSL and GnuTLS. Our main focus is the
services behind Amazon Linux's vulnerability handling, not package maintenance.</p>
I worked with the owners of the curl package and got approvals on a plan to
introduce the two new dependencies under their ownership and to enable the
feature on curl, I appreciate their responsiveness.</p>
Amazon Linux 2023 is forked from Fedora, so while introducing ngtcp2, I also
sent a couple of Pull Requests upstream to keep things in sync:</p>
[ngtcp2] package latest release 1.21.0</a></p>
[ngtcp2] do not skip tests</a></p>
While building the curl package in Amazon Linux, I've noticed the build was
taking 1 hour from start to end, and the culprit was something well known to
me; tests.</p>
The curl test suite is quite extensive, with more than 1600 tests, all of that
running without parallelization, running two times for each build of the
package; once for the minimal build and again for the full build.</p>
I had previously enabled parallel tests in Debian back in 2024 but never got
around to submit the same improvements to Amazon Linux or Fedora, this is now
fixed. The build times for Amazon Linux came down to 10 minutes under the same
host (previously 1 hour), and Fedora promptly merged my PR to do the same
there:</p>
[curl] run tests in parallel</a></p>
All of this uncovered a test which is timing-dependent, meaning it's not
supposed to be run with high levels of parallelism, so there goes another PR,
this time to curl:</p>
Flag test 766 as timing-dependent#21155</a></p>
What started as enabling a single feature turned into improvements that landed
in curl, Fedora, and Amazon Linux alike. I did this in a mix of work and
volunteer time, mostly during work hours (work email address used when this was
the case), but I'm glad I put in the extra time for the sake of improving curl
for everyone.</p>
Release Notes</h1>
Amazon Linux 2023 release notes for 2023.10.20260330</a></p>

Latest NVIDIA Drivers for Debian (Packaged with AI) 2026-03-29T00:00:00+00:00 tl;dr</h4> This is not an official package, it's good enough for me and it might be good enough for you, confirmed as working in Debian Testing but I don't have a Stable machine to test there. You can use my custom repo to install the latest NVIDIA drivers on Debian Stable, Testing or Unstable (install from Sid repository): https://deb.debusine.debian.net/debian/r-samueloph-nvidia-ai/</a> The page above contains the APT sources you need, just add the one for your release to /etc/apt/sources.list.d/r-samueloph-nvidia-ai.sources</code>, run sudo apt update</code> and install the packages, you might need to disable Secure Boot. This is not about AI</h1> Discussions about AI are quite divisive in the Free Software communities, and there's so much to be said about it that I'm not willing to go into in this blog post. This is rather just me telling people that if they need up-to-date NVIDIA packages for Debian, they could check if my custom repository gets the job done. The AI part is a means to an end, I've been careful to note in the repository names that the packages were produced with AI to respect people who do not want to run it for any reason. RTX 5000 series support</h1> Back in May 2025 I opened a bug report</a> asking for the NVIDIA drivers on Debian to be updated to support the RTX 5000 series. The Nouveau drivers might be good enough for some people, but I need the NVIDIA drivers because I want to play games and do experiments with open weight models. Opening a bug report doesn't guarantee anything, at the end of the day Debian Developers are volunteers, so if I really wanted the newer drivers, I would have to do something about it, ideally submitting a merge request. I briefly looked into the NVIDIA packaging, which involves 3 source packages (and one extra git repo for tarballs), unfortunately this was going to take more time and effort than what I was willing to spend. What I Did</h1> After a few weeks of lamenting that I wasn't running the NVIDIA drivers, I figured I was willing to put in more effort than I originally thought, just enough to instruct the Claude Code agent to package the latest releases. I'm skilled enough with agentic tools that I knew how to use it to save time; providing a clear instruction on how to build the package and explaining the packaging layout, then letting the agent iterate until it gets a working build. The agent was running inside a VM that didn't have any of my credentials. After a little bit of back and forth, where I was reviewing the changes guiding the agent into how to fix certain issues, I ended up with a working set of packages. Once I installed it on my machine and confirmed they worked, I set up a debusine</a> repository to make it easier to install future updates, and let others test it out. Debusine is analogous to Ubuntu's famous PPA, or Fedora's EPEL, it's a relatively new project but it has been working fine for this. Matheus Polkorny helped me test the packages and did spot a few issues which are fixed now. The Debusine developers were also always quick to respond to my questions and bug reports</a>. How Good Is It?</h1> Short answer: good enough for daily use, but not a substitute for an official Debian package. The whole point of doing this is because I don't have enough free time to maintain the package myself. All of this work was done as a volunteer, on my personal time. This means I'm trusting the agent to some degree; I review its commits but I don't go too deep into it, the quality will be dictated by the fact that I'm a Debian Developer and so by how easily I can spot issues without double checking everything. I only have a single machine with an NVIDIA GPU, this machine runs Debian Testing and so I don't have a way to test the Stable packages. I can do my best to address problems but at this point there is a risk that new updates break something. Installing NVIDIA drivers has always been a bit risky regardless, if you're comfortable with reverting updates and handling a system without a graphical interface (in case you end up in a tty), you will be fine. You will likely need to disable Secure Boot in order to use them, or set up your BIOS so that a MOK can be used to sign the DKMS modules. When choosing the version strings for the packages, I was careful enough to pick something that would sort lower than an official Debian package, meaning that whenever that same version is packaged in Debian, your system will see it as an upgrade. If you have any other methods of installing the NVIDIA drivers on your Debian system that is working for you, you should likely stick to that. I have a strong preference for installing them through .deb packages, making the package sort out configuration changes and dependency updates, besides handling the DKMS modules. Ultimately I'm not happy with the amount of difficulty that Debian users have in installing up-to-date NVIDIA drivers, and I hope this makes it easier for some. How To Install</h1> Head over to the Debusine page that contains both repos for Trixie (Debian Stable) and Sid (for Debian Testing and Unstable): https://deb.debusine.debian.net/debian/r-samueloph-nvidia-ai/</a> If you are running Debian Testing, then pick the Sid repository. That page contains the contents of the apt .sources</code> file you need, create the file /etc/apt/sources.list.d/r-samueloph-nvidia-ai.sources</code> with the sources for your release. Run sudo apt update</code> and install the packages you need, if you already have a previous version installed, sudo apt upgrade --update</code> would update them. If there are no upgrades, meaning you don't have a previous version installed, then you need to explicitly install them. sudo apt install nvidia-open-kernel-dkms nvidia-driver</code></pre> If you run into issues in Debian Stable, consider using the Linux kernel package from the backports repository, if you need an up-to-date NVIDIA driver, you likely should also be running the backports kernel package (if you can't upgrade to Debian Testing). Future Plans</h1> I currently have no means of measuring how many people are using the debusine repositories, so if you do end up using it feel free to let me know somehow. I don't know for how long I will keep managing this repository, and how much effort I will spend, but my machine needs it and for now I will keep it up-to-date with the latest production-grade NVIDIA drivers. Sources</h1> The sources of the packages are available under a namespace in Salsa (Debian's GitLab instance): https://salsa.debian.org/samueloph-forks-team/nvidia-drivers-forks-with-ai</a> You can also get the exact sources used in the repositories from debusine: https://debusine.debian.net/debian/r-samueloph-nvidia-ai/collection/debian:suite/sid-nvidia-ai/search/?category=debian:source-package</a> https://debusine.debian.net/debian/r-samueloph-nvidia-ai/collection/debian:suite/trixie-nvidia-ai/search/?category=debian:source-package</a> I use curl with ECH btw (in Debian) 2026-03-27T00:00:00+00:00 tl;dr</h4> This is an experimental feature that, for the first time, brings full ECH support to curl on Debian using OpenSSL. Starting with curl 8.19.0-3+exp2 (Debian Experimental), you can now use ECH, with HTTPS-RR and DoH for maximum privacy. curl 8.19.0-3+exp2 is quite fresh at the time of writing, bear in mind that your repository might not have synced the package yet, all mirrors should have it by March 27th 14:00 UTC. # defo.ie is a test server that confirms whether ECH was successfully used curl -v --ech hard https://defo.ie/ech-check.php # For Encrypted Client Hello (ECH) + DNS over HTTPS (DoH) curl -v --ech hard --doh-url https://1.1.1.1/dns-query https://defo.ie/ech-check.php</code></pre> "--ech hard" tells curl to refuse the connection entirely if ECH cannot be negotiated. Or, if you would like to try it out in a container: podman run debian:experimental /bin/bash -c 'apt install --update -t experimental -y curl && curl -v --ech hard --doh-url https://1.1.1.1/dns-query https://defo.ie/ech-check.php'</code></pre> (in case you haven't noticed, apt now has the --update</code> option for the upgrade</code> and install</code> commands) For Privacy</h1> CloudFlare calls it "the last puzzle piece to privacy" in their must-read announcement: https://blog.cloudflare.com/announcing-encrypted-client-hello/</a>. Encrypted Client Hello (rfc9849)</a> encrypts the "which website are you connecting to?" part of the TLS handshake that was previously visible in plaintext. HTTPS-RR (rfc9460)</a> is a DNS record type that publishes connection parameters for a service, including the public key clients need to perform ECH. DNS Over HTTPS (rfc8484)</a> encrypts DNS queries by tunneling them over HTTPS, hiding what domains you're looking up from network observers. When all three operate together over a CDN with shared IP space, the target domain name is hidden from passive observers; the HTTPS-RR record is queried over DoH in order to retrieve the ECH key (rfc9848)</a> for the TLS handshake. Seems like quite an important feature, and in fact the major browsers have it enabled for some time now, the trick is that they do not use OpenSSL (Chrome uses BoringSSL and Firefox uses NSS). For everyone else, the only option is to patch OpenSSL or wait until 4.0.0 is released, and so part of the reason Debian is the first distro to enable it (curl + OpenSSL + ECH) is that the OpenSSL maintainer (Sebastian Andrzej Siewior) packaged the alpha release just 3 days after it was published. Do not forget that ECH support is experimental and currently relies on the alpha release of OpenSSL. wcurl Gets It Too</h1> Considering wcurl</a> is just a wrapper on curl, it gets the feature for free: wcurl --curl-options="--ech hard --doh-url https://1.1.1.1/dns-query" $URL</code></pre> If you're using wcurl, you don't want to have to set parameters, this is just to show that the feature is there and if you have a .curlrc</code> file, it can enable the feature seamlessly. Other Debian Releases</h1> Given the ECH feature requires OpenSSL >= 4, it will not make it to Debian 13, having a small chance of going to Debian 13 Backports (emphasis on small). It should get to Debian Unstable and Debian Testing within the next couple of months as the OpenSSL GA release happens and gets packaged, but you should be able to install the package from Experimental in your Unstable and Testing systems without issues. It will also be in Debian 14 once it becomes the new Stable. Shoulders of Giants</h1> Stephen Farrell's presentation from OpenSSL Conference 2025 has a lot of background on the work involved: Encrypted Client Hello – Lessons learned from trying to do something that was probably too complicated</a> They have been working on implementing ECH in open-source projects for years, something as big as this doesn't happen without lots of people dedicating both their paid and free times over it. I ended up being the person who enabled it on Debian, which was pretty much the least amount of work between everyone involved, but hey it's fun flipping the switch and telling you about it. Background</h1> Since 2025, the curl developers started organizing an yearly meeting with all maintainers of curl in Operating Systems. The 2026 edition happened in March 26th: https://github.com/curl/curl/wiki/curl-distro-discussion-2026</a>. Attendance was really good, and as you can imagine one of the topics of discussion was ECH, in which it was pointed out that having OpenSSL 4 was the main requirement but besides it nothing unusual was needed. In Debian Experimental, we have been enabling HTTPS-RR since March 2025, and OpenSSL 4.0.0 alpha was packaged just recently (2026-03-13) by Sebastian Andrzej Siewior, it's time for the next step. The curl distro meeting was just the motivation I needed to go ahead and enable it in Debian Experimental, so as part of our Debian Brasil Weekly Meetings I've prepared and uploaded the changes, while Carlos Henrique Lima Melara worked on addressing a recent test regression for Debian Unstable. Unfortunately sergiodj couldn't join and I'm sure he's jealous of the hacking session now. Appendix</h1> While writing this, I've noticed one of the authors of the CloudFlare blogpost is the previous curl maintainer on Debian; Alessandro Ghedini let me take over the maintenance back in 2021 and today curl is maintained by a team of 4 people, it's nice to see Alessandro's involvement. Debian 13: My list of exciting new features 2025-08-28T17:30:00+00:00 Beyond Debian: Useful for other distros too</h1> Every two years Debian releases a new major version of its Stable series, meaning the differences between consecutive Debian Stable releases represent two years of new developments both in Debian as an organization and its native packages, but also in all other packages which are also shipped by other distributions (which are getting into this new Stable release). If you're not paying close attention to everything that's going on all the time in the Linux world, you miss a lot of the nice new features and tools. It's common for people to only realize there's a cool new trick available only years after it was first introduced. Given these considerations, the tips that I'm describing will eventually be available in whatever other distribution you use, be it because it's a Debian derivative or because it just got the same feature from the upstream project. I'm not going to list "passive" features (as good as they can be), the focus here is on new features that might change how you configure and use your machine, with a mix between productivity and performance. Debian 13 - Trixie</h1> I have been a Debian Testing user for longer than 10 years now (and I recommend it for non-server users), so I'm not usually keeping track of all the cool features arriving in the new Stable releases because I'm continuously receiving them through the Debian Testing rolling release. Nonetheless, as a Debian Developer I'm in a good position to point out the ones I can remember. I would also like other Debian Developers to do the same as I'm sure I would learn something new. The Debian 13 release notes contain a "What's new" section </a>, which lists the first two items here and a few other things, in other words, take my list as an addition to the release notes. Debian 13 was released on 2025-08-09, and these are nice things you shouldn't miss in the new release, with a bonus one not tied to the Debian 13 release. 1) wcurl</h2> Have you ever had to download a file from your terminal using curl and didn't remember the parameters needed? I did. Nowadays you can use wcurl</code>; "a command line tool which lets you download URLs without having to remember any parameters." Simply call wcurl</code> with one or more URLs as parameters and it will download all of them in parallel, performing retries, choosing the correct output file name, following redirects, and more. Try it out: wcurl example.com</code></pre> wcurl</code> comes installed as part of the curl package on Debian 13 and in any other distribution you can imagine, starting with curl 8.14.0. I've written more about wcurl in its release announcement</a> and I've done a lightning talk presentation in DebConf24, which is linked in the release announcement. 2) HTTP/3 support in curl</h2> Debian has become the first stable Linux distribution to ship curl with support for HTTP/3. I've written about this in July 2024</a>, when we first enabled it. Note that we first switched the curl CLI to GnuTLS, but then ended up releasing the curl CLI linked with OpenSSL (as support arrived later). Debian was the first stable Linux distro to enable it, and within rolling-release-based distros; Gentoo enabled it first in their non-default flavor of the package and Arch Linux did it three months before we pushed it to Debian Unstable/Testing/Stable-backports, kudos to them! HTTP/3 is not used by default by the curl CLI, you have to enable it with --http3</code> or --http3-only</code>. Try it out: curl --http3 https://www.example.org curl --http3-only https://www.example.org</code></pre>3) systemd soft-reboot</h2> Starting with systemd v254, there's a new soft-reboot</code> option, it's an userspace-only reboot, much faster than a full reboot if you don't need to reboot the kernel. You can read the announcement from the systemd v254 GitHub release</a> Try it out: # This will reboot your machine! systemctl soft-reboot</code></pre>4) apt --update</h2> Are you tired of being required to run sudo apt update</code> just before sudo apt upgrade</code> or sudo apt install $PACKAGE</code>? So am I! The new --update</code> option lets you do both things in a single command: sudo apt --update upgrade sudo apt --update install $PACKAGE</code></pre> I love this, but it's still not yet where it should be, fingers crossed for a simple apt upgrade</code> to behave like other package managers by updating its cache as part of the task, maybe in Debian 14? Try it out: sudo apt upgrade --update # The order doesn't matter sudo apt --update upgrade</code></pre> This is especially handy for container usage, where you have to update the apt cache before installing anything, for example: podman run debian:stable bin/bash -c 'apt install --update -y curl'</code></pre>5) powerline-go</h2> powerline-go</code> is a powerline-style prompt written in Golang, so it's much more performant than its Python alternative powerline</code>. powerline-style prompts are quite useful to show things like the current status of the git repo in your working directory, exit code of the previous command, presence of jobs in the background, whether or not you're in an ssh session, and more. Try it out: sudo apt install powerline-go</code></pre> Then add this to your .bashrc</code>: function _update_ps1() { PS1="$(/usr/bin/powerline-go -error $? -jobs $(jobs -p | wc -l))" # Uncomment the following line to automatically clear errors after showing # them once. This not only clears the error for powerline-go, but also for # everything else you run in that shell. Don't enable this if you're not # sure this is what you want. #set "?" } if [ "$TERM" != "linux" ] && [ -f "/usr/bin/powerline-go" ]; then PROMPT_COMMAND="_update_ps1; $PROMPT_COMMAND" fi</code></pre> Or this to .zshrc</code>: function powerline_precmd() { PS1="$(/usr/bin/powerline-go -error $? -jobs ${${(%):%j}:-0})" # Uncomment the following line to automatically clear errors after showing # them once. This not only clears the error for powerline-go, but also for # everything else you run in that shell. Don't enable this if you're not # sure this is what you want. #set "?" }</code></pre> If you'd like to have your prompt start in a newline, like I have in the screenshot above, you just need to set -newline</code> in the powerline-go invocation in your .bashrc</code>/.zshrc</code>. 6) Gnome System Monitor Extension</h2> Tips number 6 and 7 are for Gnome users. Gnome is now shipping a system monitor extension which lets you get a glance of the current load of your machine from the top bar. I've found this quite useful for machines where I'm required to install third-party monitoring software that tends to randomly consume more resources than it should. If I feel like my machine is struggling, I can quickly glance at its load to verify if it's getting overloaded by some process. The extension is not as complete as system-monitor-next</a>, not showing temperatures or histograms, but at least it's officially part of Gnome, easy to install and supported by them. Try it out: sudo apt install gnome-system-monitor gnome-shell-extension-manager</code></pre> And then enable the extension from the "Extension Manager" application. 7) Gnome setting for battery charging profile</h2> After having to learn more about batteries in order to get into FPV drones, I've come to have a bigger appreciation for solutions that minimize the inevitable loss of capacity that accrues over time. There's now a "Battery Charging" setting (under the "Power") section which lets you choose between two different profiles: "Maximize Charge" and "Preserve Battery Health". On supported laptops, this setting is an easy way to set thresholds for when charging should start and stop, just like you could do it with the tlp</code> package, but now from the Gnome settings. To increase the longevity of my laptop battery, I always keep it at "Preserve Battery Health" unless I'm traveling. What I would like to see next is support for choosing different "Power Modes" based on whether the laptop is plugged-in, and based on the battery charge percentage. There's a GNOME issue</a> tracking this feature, but there's some pushback on whether this is the right thing to expose to users. In the meantime, there are some workarounds mentioned in that issue which people who really want this feature can follow. If you would like to learn more about batteries; Battery University</a> is a great starting point, besides getting into FPV drones and being forced to handle batteries without a Battery Management System (BMS). And if by any chance this sparks your interest in FPV drones, Joshua Bardwell's YouTube channel is a great resource: @JoshuaBardwell</a>. 8) Lazygit</h2> Emacs users are already familiar with the legendary magit</code>; a terminal-based UI for git. Lazygit is an alternative for non-emacs users, you can integrate it with neovim or just use it directly. I'm still playing with lazygit</code> and haven't integrated it into my workflows, but so far it has been a pleasant experience. You should check out the demos from the lazygit GitHub page</a>. Try it out: sudo apt install lazygit</code></pre> And then call lazygit</code> from within a git repository. 9) neovim</h2> neovim has been shipped in Debian since 2016, but upstream has been doing a lot of work to improve the experience out-of-the-box in the last couple of years. If you're a neovim poweruser, you're likely not installing it from the official repositories, but for those that are, Debian 13 comes with version 0.10.4, which brings the following improvements compared to the version in Debian 12: Treesitter support for C, Lua, Markdown, with the possibility of adding any other languages as needed; </li> Better spellchecking due to treesitter integration (spellsitter); </li> Mouse support enabled by default; </li> Commenting support out-of-the-box; Check :h commenting</code> for details, but the tl;dr is that you can use gcc</code> to comment the current line and gc</code> to comment the current selection. </li> OSC52 support. Especially handy for those using neovim over an ssh connection, this protocol lets you copy something from within the neovim process into the clipboard of the machine you're using to connect through ssh. In other words, you can copy from neovim running in a host over ssh and paste it in the "outside" machine. </li> </ul> 10) [Bonus] Running old Debian releases</h2> The bonus tip is not specific to the Debian 13 release, but something I've recently learned in the #debian-devel</code> IRC channel. Did you know there are usable container images for all past Debian releases? I'm not talking "past" as in "some of the older releases", I'm talking past as in "literally every Debian release, including the very first one". Tianon Gravi "tianon" is the Debian Developer responsible for making this happen, kudos to him! There's a small gotcha that the releases Buzz (1.1) and Rex (1.2) require a 32-bit host, otherwise you will get the error Out of virtual memory!</code>, but starting with Bo (1.3) all should work in amd64/arm64. Try it out: sudo apt install podman podman run -it docker.io/debian/eol:bo</code></pre> Don't be surprised when noticing that apt/apt-get</code> is not available inside the container, that's because apt</code> first appeared in Debian Slink (2.1). Changes since publication</h1> 2025-08-30</h2> Mention that Arch also enabled HTTP/3.</li> </ul> DebConf24 was fun! Security, curl, wcurl, Debian's quality 2024-09-04T00:00:00+00:00 tl;dr</h4> DebConf24</a> was fun! A playlist of all of my talks, with subtitles (en, pt-br) and chapters is available on YouTube</a>. Overview</h1> DebConf24 was held in Busan, South Korea, between Sunday July 28th to Sunday August 4th 2024. As usual for DebConfs, I had a great time meeting my friends, but also met new people and got to learn a bit about the interesting things they're working on. I ended up getting too excited during the talk submission stage of the conference and as a result I presented 5 different activities (3 talks, 1 BoF and 1 lightning talk). Since I was too busy with the presentations, I did not have a lot of time to actually hang out with folks, or even to go out in the city, I guess I've learned my lesson for next time. The main purpose of this post is to write about all of the things I presented at the conference. I did want to list some of the interesting talks I've watched, but that I would not be able to be fair as I'm sure I would miss some. You can get the schedule and the recordings of any talks from the conference's website: https://debconf24.debconf.org/schedule/</a> wcurl Lightning Talk</h1> The most fun of my presentations, during the second-to-last day of the conference, I've asked for help from Sergio Durigan Junior <sergiodj> to setup an URL containing a whitespace and redirecting that to wcurl</a>'s manpage. I then did a little demo to showcase why me (and a lot others) struggle with downloading things with curl, and how wcurl</a> solves that. https://www.youtube.com/watch?v=eM8M5qa4pPM</a> </iframe> </div> Fixing CVEs on Debian: Everything you probably know already</h1> I've always felt like DebConf was missing security-related talks, so I decided to do something about it and presented a few of the things I've learned when fixing CVEs for Debian. This is an area where we don't get a lot of new contributors, I'm trying to change that, and this talk can be used to introduce newcomers to it. https://www.youtube.com/watch?v=XzNVVILVyUM</a> </iframe> </div> The secret sauce of Debian</h1> Debian is not very vocal about all of the nice things it has regarding quality-assurance, testing, or CI, even though it's at the state-of-the-art for a lot of things. This talk is an initial step towards making people aware of the cool things happening behind the scenes. Ideally we should have it well-documented somewhere. https://www.youtube.com/watch?v=x_X2IBnpjic</a> </iframe> </div> "I use Debian BTW": fzf, tmux, zoxide and friends</h1> One of my earliest good memories of Debian was when it started coming with a colored PS1 by default, I still remember the feeling of relief whenever I jumped into a Debian server and didn't have to deal with a black and white PS1. There's still a lot of room for Debian to ship better defaults, and I think some of them can actually happen. This talk is a bit of a silly one where I'm just making people aware of the existence of a few Golang/Rust CLI tools, and also some dotfiles configurations that should probably be the default. https://www.youtube.com/watch?v=tfto3Seokn4</a> </iframe> </div> curl</h1> The curl project does such a great job with their security advisories that it will likely never receive the amount of praise it deserves, but I did my best at mentioning it throughout my CVEs talk</a>. Maybe I will write more extensively about this someday, but in case I don't: There's no other project which always consistently mentions the exact range of commits that are affected by a given CVE. Forget about whether the versions are EOL, curl doesn't have LTS releases, yet they do such a great job at clearly documenting their CVEs that I would take that over having LTS releases anytime (that's for curl at least, I acknowledge some types of projects have a different need for LTS releases). Not only that, but they are also always careful about explaining alternative mitigations such as configuration changes, build flags that defuse the exploitation, or parameters that you should not use. Just like we tend to do every time we meet, me and the other Debian curl maintainers spent the first 2 or 3 days of the conference talking about how we wanted to eventually meet up to discuss the package. It was going to be informal, maybe during the Cheese and Wine party</a>, but then I've realized we should make it part of the official schedule, which would also give us the recordings for later. And so the "curl maintainers BoF" happened, where we spoke about HTTP3, GnutTLS, wcurl</a> and other things. https://www.youtube.com/watch?v=fL7hSypUTdM</a> </iframe> </div> wcurl</h1> Right after that BoF, Daniel Stenberg asked</a> if we were interested in having wcurl</a> adopted into curl, which we definitely were, so wcurl is now part of the curl project</a>. Daniel was also kind enough to design a logo for the project, which makes me especially happy because I can stop with my own approach at a logo (which I had to redo every few days): And here is the new logo: Much better, I would say :) curl Swag</h1> DebConf24 was my chance at forwarding some curl swag items to the other curl maintainers, so both Sergio Durigan Junior <sergiodj> and Carlos Henrique Lima Melara <charles> got the curl-up t-shirt</a> and the very cool curl PCB coaster</a>, both gifted by Daniel Stenberg. Unfortunately I didn't have any of that for DebConf attendees, but I did drop loads of curl stickers at the stickers table, they were gone very quickly. For the future</h1> I used to think the most humbling experience you could have as someone who presented a talk was to have to watch it yourself, you notice a lot of mistakes and you instantly think about things that should be done differently. It turns out the most humbling thing to do is actually to write subtitles for your talks, I noticed every single mistake, often multiple times. So after spending more than 30 hours writing the subtitles for both English and Brazilian Portuguese for my talks, I feel like it's going to be much easier to avoid committing the same mistakes again. After some time you stop feeling shame about those mistakes and you're just left with feelings of annoyance, and at that point it becomes easier to consciously avoid them. I am collecting a list of things I wish I had done differently on all of those talks, so if I end up presenting any one of them again, it will be an improved version. Photography: Aigars Mahinovs <[email protected]> License: CC-BYv3+ or GPLv2+ Debian's curl now supports HTTP/3 2024-07-04T00:00:00+00:00 tl;dr</h4> Starting with curl 8.0.0-2, you can now use HTTP/3. curl --http3-only https://example.com</code></pre> Or, if you would like to try it out in a container: podman run debian:testing /bin/bash -c 'apt install --update -y curl && curl --http3-only https://example.com'</code></pre> (in case you haven't noticed, apt now has the --update</code> option for the upgrade</code> and install</code> commands) Availability</h5> Debian unstable - Since 2024-07-02</li> Debian testing - Since 2024-07-18</li> Debian 13 - Since its initial release.</li> Debian 12/bookworm-backports - Since 2024-08-25</li> Debian 12/bookworm - Due to the mechanisms we have in place to make sure Debian stable is in fact stable, we will never be able to ship this in the regular repository. Users can make use of the backports</a> repositories instead.</li> Debian derivatives - Rolling releases will get it by the time it's on Debian testing (e.g.: Kali Linux). Stable derivatives only in their next major release.</li> </ul> The challenge</h1> HTTP/3 is fresh new, well... not really, but at least fresh enough that I'm not aware of any other Linux distribution supporting it on curl, the reason is likely two-fold: OpenSSL is not there yet</h3> OpenSSL still doesn't have proper HTTP/3 support, and given that OpenSSL is so widely used, almost every curl distributor/packager will build curl with it and thus changing the TLS backend to something else is risky. Unfortunately, proper support for the OpenSSL libcurl is unlikely to come anytime before the end of this year, the OpenSSL performance is not good enough yet as of version 3.3</a>. Daniel Stenberg has written about the state of this multiple times, most recently at HTTP/3 in curl mid 2024</a>, if you're interested, I suggest reading through his other posts as well. Some might have noticed that nginx does support HTTP/3 through OpenSSL</a>, although when you look closely, it's not exactly perfect: An SSL library that provides QUIC support is recommended to build nginx, such as BoringSSL, LibreSSL, or QuicTLS. Otherwise, the OpenSSL compatibility layer will be used that does not support early data. </blockquote> As you can see, they don't recommend using OpenSSL, and when doing so, you don't get complete support. Update (October 2025): OpenSSL's HTTP/3 support has since matured enough that curl 8.16.0-2 switched the Debian curl CLI back to the OpenSSL backend, before the Debian 13/trixie freeze. </li> HTTP/3 support for GnuTLS/nghttp3/ngtcp2 is recent</h3> The non-experimental support arrived back in October 2023</a>, and so that's when I started seriously planning for this. curl has been working on HTTP/3 support for years, and so it did support other TLS backends before that, but out of them, the one most feasible for a distribution to ship would be GnuTLS, which gets HTTP/3 support through ngctp2 and nghttp3</a>. </li> </ol> How it was done</h1> The Debian curl package has historically shipped at least two variants of libcurl, an OpenSSL and a GnuTLS one. The OpenSSL libcurl couldn't support HTTP/3 at the time for the reasons explained above, but the GnuTLS libcurl can (with ngtcp2 and nghttp3). Debian packages can choose which version of libcurl to link against (without having to modify any upstream source code). Debian's "git" package being a famous example of a package that links against the GnuTLS libcurl. Enabling HTTP/3 on curl was done in three steps: Make sure all required dependencies fulfill the minimum requirements.</li> Enable HTTP/3 for GnuTLS libcurl.</li> Change the libcurl used by the curl CLI, from OpenSSL to GnuTLS.</li> </ol> curl's HTTP/3 support requires a somewhat recent version of nghttp3 and updating that required a transition</a> (due to the SONAME bump), while we've also had months of freeze for transitions due to the time_t transition</a>. After the dependencies were in place, enabling HTTP/3 for the GnuTLS libcurl was straightforward</a>. Then, for the last part, we had to switch the TLS backend used by the curl CLI. Doing the swap is also quite easy</a> on the packaging level, but we have to consider the chances of this change breaking our users' environments. Update (October 2025): Switching back to OpenSSL</h4> Once OpenSSL's HTTP/3 support was stable and performant enough, the temporary arrangement with the GnuTLS backend had served its purpose. In October 2025, before the freeze for Debian 13/trixie, curl 8.16.0-2 switched the curl CLI back to the OpenSSL backend, now built with HTTP/3 support enabled directly. The GnuTLS libcurl continues to be shipped and supports HTTP/3 as before; this change only affects which backend the curl CLI binary itself links against. Ensuring there are no breakages</h1> The first thing to consider regarding breakages is that this change is not going to be pushed directly to the current Debian stable releases, it will be present in the next stable release (13/trixie) but the current one will stick to the version that's already shipped. Secondly, we have to consider the risk of losing the ability to use certain parameters from the curl CLI which could be limited to the OpenSSL backend. During curl-up 2024</a>, the curl developers pointed out the existence of a page that lists the TLS related options and the backends they work with</a>. Analysing that page, ignoring all of the options that are suffixed with "BLOB" (only pertinent to the library, not the CLI), the only one left which is attention worthy is CURLOPT_ECH</a>. This experimental feature requires a special build of OpenSSL, as ECH is not yet supported in OpenSSL releases. In contrast ECH is supported by the latest BoringSSL and wolfSSL releases. </blockquote> As it turns out, Encrypted Client Hello</code> is experimental and it's not supported by the vanilla OpenSSL. This was enough of an investigation for me to go ahead with the change. Noting that even in the worst case scenario (we find a horrible regression), we can rollback without having affected a single stable release. Now that the package is on Debian unstable, the CI tests (autopkgtest) of every package that depends on curl is currently running, the results are compared against the migration-reference (in this case, the curl CLI with OpenSSL, before the change). If everything goes right, curl with HTTP/3 support will migrate to Debian testing in around 5 days. If we spot any issues, we'll have to solve them first and it's going to be hard to predict how long it takes, although it's fair to expect less than a month. Update (October 2025): Debian 13/trixie ultimately shipped with the OpenSSL backend instead, following the switch in curl 8.16.0-2 before the freeze. Feedback</h1> Feel free to join the Matrix room for the Debian curl maintainers: https://matrix.to/#/#debian-curl-maintainers:matrix.org</a> Acknowledgements</h1> It took us a bit longer than expected to be able to enable HTTP/3, nonetheless it's still early enough to be excited about. A lot of people were crucial to make this happen. I should recognize in the first place, obviously, the curl developers and the developers of the supporting libraries: GnuTLS, nghttp3, ngtcp2. Participating in the curl-up 2024</a> conference helped me get motivated to push this through, besides becoming aware of the right documentation to research for impact. On the Debian side, Sakirnth Nagarasa <sakirnth> was responsible for updating and taking care of the transition for nghttp3 and ngtcp2. Also on the Debian side, I've got loads of help and support from the co-maintainers of the curl package: Sergio Durigan Junior <sergiodj> and Carlos Henrique Lima Melara <charles>. Changes since publication</h1> 2026-04-02</h2> Correct spelling of HTTP/3.</li> Add note to explain that curl is back to using OpenSSL: OpenSSL's HTTP/3 support matured sufficiently by October 2025, and curl 8.16.0-2 switched the Debian curl CLI back to the OpenSSL backend before the Trixie freeze. Updated the OpenSSL challenge section, the "How it was done" section, and the breakages section to reflect this.</li> </ul> 2025-03-08</h2> Fix podman command, the previous one was not running all commands inside the container.</li> Change the podman command to use Debian testing instead of unstable.</li> </ul> 2024-08-28</h2> Mention availability in bookworm-backports.</li> </ul> 2024-07-18</h2> Update date of availability for Debian testing and expected date for bookworm-backports.</li> Remove mention of language spoken in the Matrix room, we are using English now.</li> </ul> Announcing wcurl: a curl wrapper to download files 2024-07-03T00:00:00+00:00 </iframe> </div> tl;dr</h4> Whenever you need to download files through the terminal and don't feel like using wget: wcurl example.com/filename.txt</code></pre> Manpage: https://curl.se/wcurl/manual.html</a> Availability (comes installed with the curl package):</h5> Debian unstable - Since 2024-07-02</li> Debian testing - Since 2024-07-18</li> Debian 12/bookworm-backports - Since 2024-08-25</li> Debian 12/bookworm - Due to the way changes are planned for Debian Stable, wcurl will not be present in bookworm. Users are recommended to either manually download wcurl or use the bookworm-backports repository. wcurl will be present in Debian 13/trixie.</li> Debian derivatives - Rolling releases will get it by the time it's on Debian testing (e.g.: Kali Linux). Stable derivatives only in their next major release.</li> </ul> If you don't want to wait for the package update to arrive, you can always copy the script and place it in your /usr/bin</code>: curl -fLO https://github.com/curl/wcurl/releases/latest/download/wcurl chmod +x wcurl sudo mv wcurl /usr/bin/wcurl</code></pre> After this announcement, wcurl has joined the curl organization: https://daniel.haxx.se/blog/2024/08/08/curl-welcomes-wcurl-to-the-team/</a> Project homepage: https://curl.se/wcurl/</a> Smoother CLI experience</h1> Starting with curl version 8.8.0-2, the Debian's curl package now ships a wcurl executable. wcurl is the solution for those who just need to download files without having to remember curl's parameters for things like automatically naming the files. Some people, myself included, would fall back to using wget whenever there was a need to download a file. Sometimes even installing wget just for that usecase. After all, it's easier to remember "apt install wget" rather than "curl -L -O -C - ...". wcurl consists of a simple shell script that provides sane defaults for the curl invocation, for when the use case is to just download files. By default, wcurl will: Percent-encode whitespaces in URLs;</li> Download multiple URLs in parallel if the installed curl's version is >= 7.66.0;</li> Follow redirects;</li> Automatically choose a filename as output;</li> Avoid overwriting files if the installed curl's version is >= 7.83.0 (--no-clobber);</li> Perform retries;</li> Set the downloaded file timestamp to the value provided by the server, if available;</li> Disable curl's URL globbing parser so {} and [] characters in URLs are not treated specially;</li> Percent-decode the resulting filename;</li> Use "index.html" as default filename if there's none in the URL.</li> </ul> </blockquote> Example to download a single file: wcurl example.com/filename.txt</code></pre> If you ever need to set a custom flag, you can make use of the --curl-options</code> wcurl option, anything set there will be passed to the curl invocation. Just beware that if you need to set any custom flags, it's likely you will be better served by calling curl directly. The --curl-options</code> option is there to allow for some flexibility in unforeseen circumstances. The need for wcurl</h1> I've always felt a bit ashamed of not remembering curl's parameters for downloading a file and automatically naming it, having resorted to wget most of the times this was needed (even installing wget when it wasn't there, just for this). I've spoken to a few other experienced people I know and confirmed what could be obvious to others: a lot of people struggle with this. Recently, the curl project released the results of 2024's curl survey</a>, which also showed this is as a much needed feature, just look at some of the answers: Q: Which curl command line option do you think needs improvement and how?</h4> -O, I really want wget like functionality where I don't have to specify the name </blockquote> Downloading a file (like wget) could be improved - with automatic naming of the file </blockquote> downloading files - wget is much cleaner </blockquote> I wish the default behaviour when GETting a binary was to drop it on disk. That's the only reason 'wget foo.tgz" is still ingrained in my muscle memory . </blockquote> Maybe have a way to download without specifying something in -o (the only reason i used wget still) </blockquote> --remote-time should be default </blockquote> --remote-name-all could really use a short flag </blockquote> Q: If you miss support for something, tell us what!</h4> "Write the data to the file named in the URL (or in redirects if I'm feeling daring), and timestamp the file to the last-modified-date". This is the main reason I'm still using wget. </blockquote> I can finally feel less bad about falling back to wget due to not remembering the parameters I want. Idealization vs. reality</h1> I don't believe curl will ever change its default behavior in such a way that would accommodate this need, as that would have a side-effect of breaking things which expect the current behavior (the blast radius is literally the solar system</a>). This means a new executable needs to be shipped side-by-side with curl, an opportunity to start fresh and work with a more focused use case (to download files). Ideally, this new executable would be maintained by the curl project, make use of libcurl under-the-hood, and be available everywhere. Nobody wants to worry if their systems have the tool or not, it should always be there. Given I'm just a Debian Developer, with not as much free time as I wish, I've decided to write a simple shell script wrapper calling the curl CLI under-the-hood. wcurl will come installed with the curl package from now on, and I will check with the release team about shipping it on the current Debian stable as well. Shipping wcurl in other distros will be up to them (Debian-derivatives should pick it up automatically, though). We've tried to make it easy for anyone to ship this by using the curl license, keeping the script POSIX-compliant, and shipping a manpage</a>. Maybe if there's enough interest across distributions, someone might sign up for implementing this in upstream curl and increase its reach. I would be happy with the curl project reusing the wcurl name when that happens. It's unlikely that wcurl would be shipped by curl upstream as it is, assuming they would prefer a solution that uses libcurl direclty (more similar to curl the CLI, to maintain). In the worst case, wcurl becomes a Debian-specific tool that only a few people are aware of, in the best case, it becomes the new go-to CLI tool for simply downloading files. I would be happy if at least someone other than me finds it useful. Naming is hard</h1> When I started working on it, I was calling the new executable "curld" (stands for "curl download"), but then when discussing this in one of our weekly calls in the Debian Brasília community, it was mentioned that this could be confused for a daemon. We then settled for the name "wcurl", suggested by Carlos Henrique Lima Melara <charles>. It doesn't really stand for anything, but it's very easy to remember. You know... "it's that wget alternative for when you want to use curl instead" :) Feedback</h1> The code is hosted in GitHub, feel free to open an issue to provide feedback. https://github.com/curl/wcurl</a> We also have a Matrix room for the Debian curl maintainers: https://matrix.to/#/#debian-curl-maintainers:matrix.org</a> Acknowledgments</h1> The idea for wcurl came a few days before the curl-up conference 2024</a>. I've been thinking a lot about developer productivity in the terminal lately, different tools and better defaults. Before curl-up, I was also thinking about packaging improvements for the curl package. I don't remember what exactly happened, but I likely had to download something and felt a bit ashamed of maintaining curl and not remembering the parameters to download files the way I wanted. I first discussed this idea in the conference, where I asked the participants about it and there were no concerns raised, and some people said I should give it a go. Participating in curl-up was a really great experience and I'm thankful for the interactions I've had there. On the Debian side, I've got reviews of the code and manpage by Sergio Durigan Junior <sergiodj>, Guilherme Puida Moreira <puida> and Carlos Henrique Lima Melara <charles>. Sergio ended up rewriting the tool to be POSIX-compliant (my version was written in bash), so he takes all the credit for the portability. Changes since publication</h1> 2025-01-19</h2> Mention that wcurl will not be added to Debian 12/bookworm, it will be present in Debian 13/trixie.</li> </ul> 2024-12-14</h2> Update list of wcurl features.</li> Point out to wcurl homepage and mention that it's now part of curl.</li> Reorder this changelog to have latest changes on top.</li> </ul> 2024-08-28</h2> Mention availability in bookworm-backports.</li> Link to wcurl lightning talk from DebConf24.</li> </ul> 2024-07-18</h2> Update date of availability for Debian testing and expected date for bookworm backports.</li> Mention charles as the person who suggested "wcurl" as a name.</li> Update wcurl's -o/--opts options, it's now just --curl-options.</li> Remove mention of language spoken in the Matrix room, we are using English now.</li> Update list of features of wcurl.</li> </ul> Hello World 2024-04-18T00:00:00+00:00 This is my very first post, just to make sure everything is working as expected. Made with Zola</a> and the Abridge theme</a>.

Appendix</h1>
While writing this, I've noticed one of the authors of the CloudFlare blogpost is the previous curl maintainer on Debian; Alessandro Ghedini let me take over the maintenance back in 2021 and today curl is maintained by a team of 4 people, it's nice to see Alessandro's involvement.</p>

`Changes since publication</h1> 2025-08-30</h2> Mention that Arch also enabled HTTP/3.</li> </ul>`

2025-08-30</h2>

Mention that Arch also enabled HTTP/3.</li> </ul>

tl;dr</h4>
DebConf24</a> was fun!</p>
A playlist of all of my talks, with subtitles (en, pt-br) and chapters is available on YouTube</a>.</p>

2024-08-28</h2>

Mention availability in bookworm-backports.</li> </ul>
2024-07-18</h2>

Update date of availability for Debian testing and expected date for bookworm-backports.</li>
Remove mention of language spoken in the Matrix room, we are using English now.</li> </ul>

2024-07-18</h2>

Update date of availability for Debian testing and expected date for bookworm-backports.</li>
Remove mention of language spoken in the Matrix room, we are using English now.</li> </ul>

Feedback</h1>
The code is hosted in GitHub, feel free to open an issue to provide feedback.
https://github.com/curl/wcurl</a></p>
We also have a Matrix room for the Debian curl maintainers:
https://matrix.to/#/#debian-curl-maintainers:matrix.org</a></p>

Samuel Henrique (samueloph)

Bringing HTTP/3 to curl on Amazon Linux

Release Notes</h1>
Amazon Linux 2023 release notes for 2023.10.20260330</a></p>

Latest NVIDIA Drivers for Debian (Packaged with AI)

I use curl with ECH btw (in Debian)

Debian 13: My list of exciting new features

DebConf24 was fun! Security, curl, wcurl, Debian's quality

Debian's curl now supports HTTP/3

Announcing wcurl: a curl wrapper to download files

Hello World

Samuel Henrique (samueloph)

Bringing HTTP/3 to curl on Amazon Linux

Latest NVIDIA Drivers for Debian (Packaged with AI)

Sources</h1> The sources of the packages are available under a namespace in Salsa (Debian's GitLab instance):</p>

I use curl with ECH btw (in Debian)

Debian 13: My list of exciting new features

3) systemd soft-reboot</h2> Starting with systemd v254, there's a new soft-reboot</code> option, it's an userspace-only reboot, much faster than a full reboot if you don't need to reboot the kernel.</p>

4) apt --update</h2> Are you tired of being required to run sudo apt update</code> just before sudo apt upgrade</code> or sudo apt install $PACKAGE</code>? So am I!</p> The new --update</code> option lets you do both things in a single command:</p>

Changes since publication</h1> 2025-08-30</h2> Mention that Arch also enabled HTTP/3.</li> </ul>

2025-08-30</h2> Mention that Arch also enabled HTTP/3.</li> </ul>

DebConf24 was fun! Security, curl, wcurl, Debian's quality

Debian's curl now supports HTTP/3

tl;dr</h4> Starting with curl 8.0.0-2</strong>, you can now use HTTP/3.</p>

Availability</h5> Debian unstable - Since 2024-07-02</li> Debian testing - Since 2024-07-18</li> Debian 13 - Since its initial release.</li> Debian 12/bookworm-backports - Since 2024-08-25</li>

The challenge</h1> HTTP/3 is fresh new, well... not really, but at least fresh enough that I'm not aware of any other Linux distribution supporting it on curl, the reason is likely two-fold:</p>

OpenSSL is not there yet</h3> OpenSSL still doesn't have proper HTTP/3 support, and given that OpenSSL is so widely used, almost every curl distributor/packager will build curl with it and thus changing the TLS backend to something else is risky.</p>

2024-08-28</h2> Mention availability in bookworm-backports.</li> </ul> 2024-07-18</h2> Update date of availability for Debian testing and expected date for bookworm-backports.</li> Remove mention of language spoken in the Matrix room, we are using English now.</li> </ul>

2024-07-18</h2> Update date of availability for Debian testing and expected date for bookworm-backports.</li> Remove mention of language spoken in the Matrix room, we are using English now.</li> </ul>

Announcing wcurl: a curl wrapper to download files

tl;dr</h4> Whenever you need to download files through the terminal and don't feel like using wget:</p>

Q: Which curl command line option do you think needs improvement and how?</h4> -O, I really want wget like functionality where I don't have to specify the name</p> </blockquote>

Hello World

`Changes since publication</h1> 2025-08-30</h2> Mention that Arch also enabled HTTP/3.</li> </ul>`

2025-08-30</h2>

Mention that Arch also enabled HTTP/3.</li> </ul>

2024-08-28</h2>

Mention availability in bookworm-backports.</li> </ul>
2024-07-18</h2>

Update date of availability for Debian testing and expected date for bookworm-backports.</li>
Remove mention of language spoken in the Matrix room, we are using English now.</li> </ul>

2024-07-18</h2>

Update date of availability for Debian testing and expected date for bookworm-backports.</li>
Remove mention of language spoken in the Matrix room, we are using English now.</li> </ul>