With 26.10 in Feature Freeze, wore my Release team hat to:
Review and approve a bunch of Feature Freeze Exceptions, including the Go 1.27 transition, Qt 6.11.2, rust-coreutils 0.12.0, devscripts 2.6.12, kdump-tools moving to dracut, and a few GCE packages.
Point linux-entra-sso to the SRU team, as it didn t need an FFe at all, and milestone a couple of bugs for 26.10.
Continued to push for infrastructure improvements:
Made ubuntu-cdimage more resilient to Launchpad hiccups (MP).
Taught generate-freeze-block in ubuntu-archive-tools a couple of new options (--skip-update and --series) and better error handling (MP).
Bumped the arm64 generic non-cloud image to 4.5G in livecd-rootfs and uploaded it as 26.10.16; also sponsored the follow-up 26.10.17 for Chlo .
Reviewed quite a lot of MPs - britney hints, meta-release, ubuntu-release-tools, ubuntu-archive-tools, ubuntu-cdimage, livecd-rootfs, ubuntu-seeds, and so on.
Did Archive Admin, DMB, and Release team duties as usual.
Debian (E)LTS
This month I have worked 33.5 hours
on Debian Long Term Support (LTS)
and on its sister Extended LTS
project and did the following things:
(A quick note that I did quite a lot of the work during my work as Frontdesk that went on till 4th Oct, so 33.50 hours include the work I did till 4th October 2026.)
Released Security Updates
node-lodash: Prototype pollution in _.unset and _.omit (plus a bypass of the initial fix for it), and code injection via the imports option of _.template.
This is the bookworm follow-up to DLA 4663-1 that I carried over from July. The update had been sitting prepared and tested on debusine, so once the upstream discussion wrapped up, it went straight out. It also carries an extra patch to the lodash-cli dependency map - without it, the regenerated lodash.template module throws assignWith is not defined at runtime, which node-gulp-util s autopkgtest caught.
libpng1.6: Use-after-free of zlib input in png_read_end() after incomplete zTXt, iTXt, or iCCP decompression, which could result in denial of service.
I picked this one up whilst on front desk; the upstream fix that went into trixie via DSA 6537-1 applied to 1.6.39 as-is.
Work in Progress
libpng1.6: The same CVE-2026-46675.
[ELTS]: Claimed in ela-needed; the same upstream fix applies to all three ELTS suites, so this should go out shortly.
Other Activities
[E/LTS] Did my front-desk week from 28-09 to 04-10.
Over the week I did roughly:
Triage of 524 unique CVEs across 192 source packages and all four suites. And 1 automated ELTS end-of-life sweep.
Additional data is now part of the front-desk job too, so 75 commits record it for 179 CVEs across 71 packages.
Newly queued 22 source packages - 13 in dla-needed (apache2, chromium, firefox-esr, libnet-idn-encode-perl, libpng1.6, node-shell-quote, nvidia-graphics-drivers, openssl, pcre2, php-mongodb, php8.2, social-auth-core, and wpa) and 16 in ela-needed (apache2, firefox-esr, gegl, lemonldap-ng, libnet-idn-encode-perl, libpng1.6, libwebsockets, nsd, nvidia-graphics-drivers, pcre2, php7.0, php7.3, php7.4, rar, unrar-nonfree, and wpa), 7 of them in both. Also widened 3 ELTS entries to bullseye - antiword, ocaml, and openvswitch.
Most of the interesting work was again in the <not-affected> verdicts: 217 of 263 (83%, across 57 packages) rest on showing that the vulnerable code or feature isn t in the source we ship. Another 17 cover incomplete upstream fixes that we either never shipped or shipped with the follow-up already in (expat, libxml2, node-tar, and pyjwt). 15 come from bundled components we don t ship - node-ajv again, which uses uri-js and not fast-uri, and nvidia-open, which doesn t ship the NGX updater. And 13 are vendor- or platform-specific - openssh s CVE-2026-55654 lives only in a Red Hat GSSAPI patch, and the netdata and PHP ones only affect Windows.
Did 4 rounds of newly supported bullseye packages (33 packages overall), plus libmail-mboxparser-perl for buster - 34 in all. The existing CVE data mostly held up; the real finds were discovery gaps. One interesting gotcha: sid renamed stunnel4 to stunnel, and two new CVEs were associated only with the new name, so they never showed up for trixie, bookworm, or any ELTS suite. I also sorted the 180 Triage needed entries (57 packages) from elts-eol by where each was already handled, and triaged for ELTS the 100 that trixie or bookworm had already decided; the rest come next. And I imported 79 package-level lines for the older source names ELTS still ships (tomcat8, php7.0/7.3/7.4, netty-3.9, openssl1.0, python2.7/3.5/3.7, and pypy).
Caught some inconsistencies in released advisories: DLA 4801-1 (swift) was missing a CVE, ELA 1831-1 (redis) listed the wrong one, and DLA 4808-1 (network-manager-l2tp) listed CVE-2026-75883 - an ID that was renamed and then reassigned to an unrelated ppp issue. I fixed all three in the tracker s advisory lists.
Made the Security team and the uploaders aware of regressions from our own updates:
libde265: the CVE-2026-49337 fix in DLA 4789-1/ELA 1828-1 (and DSA 6413-1) misses upstream s follow-up commit.
libxml2 CVE-2026-76781 and policykit-1 CVE-2026-85498 were introduced by our own back-ports; the policykit-1 one is harmless.
expat: the CVE-2025-59375 backport in DLA 4807-1 is compiled out, because XML_GE is never defined.
xen: DLA 4818-1 s XSA-491 fix makes XSA-510 reachable.
gegl: the CVE-2026-2049/2050 back-port in ELA 1650-1 rejects valid RLE .hdr files.
log4cxx: DLA 4322-1 broke UTF-8 in JSONLayout output. That one is functional, not security.
Helped correct a set of triages and let the Debian Security team know:
ruby-json CVE-2026-71847: the vulnerable code was never in a released Debian version.
openssh CVE-2026-55654: only affects a Red Hat-specific GSSAPI patch.
three libxml2 issues that don t affect trixie either.
the stunnel4 rename above.
trixie <no-dsa> lines on jsch, node-qs, and ruby-loofah, where trixie s version doesn t have the vulnerable feature at all.
Independently found a security issue in rclone and reported it privately upstream through a GitHub security advisory. Upstream already had a report for the same issue, so they folded mine into the existing advisory and credited me as a co-reporter.
Also found some bugs in the additional-data tooling, e.g. cve-ad --package P --severity tbd wipes the CVE-level severity, and the schema doesn t validate package-level entries at all.
[E/LTS] Monitored discussions on mailing lists, IRC, and all the documentation updates.
Following up on my previous post, I have released the
debvulns CLI. This utility uses
the same parsing logic as the debsecan-mcp server but exposes the
functionality directly via the command line.
Why a new CLI?
While Debian's native debsecan utility exists, it lacks modern output formats
like JSON and CSV, and fails to expose a significant amount of metadata
available in the Debian Security Team's daily snapshot.
Additionally, running a persistent Model Context Protocol (MCP) server
introduces context window overhead. The manifests and tool descriptions required
by the protocol consume tokens even when idle. For debsecan-mcp, the MCP
Inspector utility shows an
overhead of roughly 150 tokens.
By contrast, an LLM can parse a standard CLI help menu on-demand without
permanently draining the context window. Integrating the CLI into a persistent
agent workflow can be achieved via a skill file, allowing the LLM to leverage the
tool without repeated discovery overhead.
What else is NEW?
During testing, I observed discrepancies between the output of debsecan-mcp/debvulns
and native debsecan. Debugging with an LLM revealed a bug in the version
comparison logic
that caused debvulns to underreport vulnerabilities. This has been resolved.
The current interface supports structured formatting and customizable data backends:
By allowing users to override data sources with local snapshots of the Debian
Security Tracker and EPSS feeds, debvulns can run natively in airgapped
environments.
What Next?
The next step is building a Prometheus exporter for this vulnerability data to
streamline scanning and monitoring across data center infrastructure. Stay tuned.
Since Generative AI is currently the most popular topic, I wanted to get my
hands dirty and learn something new. I was learning about the Model Context
Protocol at the time and wanted to apply it to build something simple.
Idea
On Debian systems, we use debsecan to find vulnerabilities. However, the tool
currently provides a simple list of vulnerabilities and packages with no
indication of the system's security posture meaning no criticality information
is exposed and no executive summary is provided regarding what needs to be
fixed. Of course, one can simply run the following to install existing fixes and
be done with it:
But this is not how things work in corporate environments; you need to provide a
report showing the system's previous state and the actions taken to bring it to
a safe state. It is all about metrics and reports.
My goal was to use debsecan to generate a list of vulnerabilities, find more
detailed information on them, and prioritize them as critical, high, medium, or
low. By providing this information to an AI, I could ask it to generate an
executive summary report detailing what needs to be addressed immediately and
the overall security posture of the system.
Initial Take
My initial thought was to use an existing LLM, either self-hosted or a
cloud-based LLM like Gemini (which provides an API with generous limits via AI
Studio). I designed functions to output the list of vulnerabilities on the
system and provide detailed information on each. The idea was to use these as
"tools" for the LLM.
Learnings
I learned about open-source LLMs using Ollama, which allows you to download
and use models on your laptop.
I used Llama 3.1, Llama 3.2, and Granite 4 on my laptop without a GPU. I
managed to run my experiments, even though they were time-consuming and
occasionally caused my laptop to crash.
I learned about Pydantic and how to use it to parse custom JSON schemas with
minimal effort.
I learned about osv.dev, an open-source initiative by Google that aggregates
vulnerability information from various sources and provides data in a
well-documented JSON schema format.
I learned about the EPSS (Exploit Prediction Scoring System) and how it is
used alongside static CVSS scoring to detect truly critical vulnerabilities.
The EPSS score provides an idea of the probability of a vulnerability being
exploited in the wild based on actual real-world attacks.
These experiments led to a collection of notebooks. One key takeaway
was that when defining tools, I cannot simply output massive amounts of text
because it consumes tokens and increases costs for paid models (though it is
fine for local models using your own hardware and energy). Self-hosted models
require significant prompting to produce proper output, which helped me
understand the real-world application of prompt engineering.
Change of Plans
Despite extensive experimentation, I felt I was nowhere close to a full
implementation. While using a Gemini learning tool to study MCP, it suddenly
occurred to me: why not write the entire thing as an MCP server? This would save
me from implementing the agent side and allow me to hook it into any
IDE-based LLM.
Design
This MCP server is primarily a mix of a "tool" (which executes on the server
machine to identify installed packages and their vulnerabilities) and a
"resource" (which exposes read-only information for a specific CVE ID).
The MCP exposes two tools:
List Vulnerabilities: This tool identifies vulnerabilities in the packages
installed on the system, categorizes them using CVE and EPSS scores, and
provides a dictionary of critical, high, medium, and low vulnerabilities.
Research Vulnerabilities: Based on the user prompt, the LLM can identify
relevant vulnerabilities and pass them to this function to retrieve details
such as whether a fix is available, the fixed version, and criticality.
Vibe Coding
"Vibe coding" is the latest trend, with many claiming that software engineering
jobs are a thing of the past. Without going into too much detail, I decided to
give it a try. While this is not my first "vibe coded" project (I have done this
previously at work using corporate tools), it is my first attempt to vibe code a
hobby/learning project.
I chose Antigravity because it seemed to be the only editor providing a
sufficient amount of free tokens. For every vibe coding project, I spend time
thinking about the barebones skeleton: the modules, function return values, and
data structures. This allows me to maintain control over the LLM-generated code
so it doesn't become overly complicated or incomprehensible.
As a first step, I wrote down my initial design in a requirements document. In
that document, I explicitly called for using debsecan as
the model for various components. Additionally, I asked the AI to reference my
specific code for the EPSS logic.
The reasons were:
debsecan already solves the core problem; I am simply rebuilding it.
debsecan uses a single file generated by the Debian Security team
containing all necessary information, which prevents us from needing multiple
external sources.
This provides the flexibility to categorize vulnerabilities within the
listing tool itself since all required information is readily available,
unlike my original notebook-based design.
I initially used Gemini 3 Flash as the model because I was concerned about
exceeding my free limits.
Hiccups
Although it initially seemed successful, I soon noticed discrepancies between
the local debsecan outputs and the outputs generated by the tools. I asked the
AI to fix this, but after two attempts, it still could not match the outputs. I
realized it was writing its own version-comparison logic and failing
significantly.
Finally, I instructed it to depend entirely on the python-apt module for
version comparison; since it is not on PyPI, I asked it to pull directly from
the Git source. This solved some issues, but the problem persisted. By then, my
weekly quota was exhausted, and I stopped debugging.
A week later, I resumed debugging with the Claude 3.5 Sonnet model. Within 20-25
minutes, it found the fix, which involved four lines of changes
in the parsing logic. However, I ran out of limits again before I could proceed
further.
In the requirements, I specified that the list vulnerabilities tool should
only provide a dictionary of CVE IDs divided by severity. However, the AI
instead provided full text for all vulnerability details, resulting in excessive
data including negligible vulnerabilities being sent to the LLM. Consequently,
it never called the research vulnerabilities tool. Since I had run out of
limits, I manually fixed this in a follow-up commit.
How to Use
I have published the current work in the debsecan-mcp repository. I have used the same
license as the original debsecan. I am not entirely sure how to interpret
licenses for vibe-coded projects, but here we are.
To use this, you need to install the tool in a virtual environment and configure
your IDE to use the MCP. Here is how I set it up for Visual Studio Code:
I am running it directly from my local codebase using a virtualenv created
with uv. You may need to tweak the path based on your installation.
To use the MCP server in the Copilot chat window, reference it using
#debsecan-mcp. The LLM will then use the server for the query.
Use a prompt like: "Give an executive summary of the system security status
and immediate actions to be taken."
You can observe the LLM using list_vulnerabilities followed by
research_cves. Because the first tool only provides CVE IDs based on
severity, the LLM is smart enough to research only high and critical
vulnerabilities, thereby saving tokens.
What's Next?
This MCP is not yet perfect and has the following issues:
The list_vulnerabilities dictionary contains duplicate CVE IDs because the
code used a list instead of a set. While the LLM is smart enough to
deduplicate these, it still costs extra tokens.
Because I initially modeled this on debsecan, it uses a raw method for
parsing /var/lib/dpkg/status instead of python-apt. I am considering
switching to python-apt to reduce maintenance overhead.
Interestingly, the AI did not add a single unit test, which is disappointing.
I will add these once my limits are restored.
I need to create a cleaner README with usage instructions.
I need to determine if the MCP can be used via HTTP as well as stdio.
Conclusion
Vibe coding is interesting, but things can get out of hand if not managed
properly. Even with a good process, code must be reviewed and tested; you cannot
blindly trust an AI to handle everything. Even if it adds tests, you must
validate them, or you are doomed!
The Debian LTS Team, funded by [Freexian s Debian LTS offering]
(https://www.freexian.com/lts/debian/), is pleased to report its activities for
December.
Activity summary
During the month of December, 18 contributors have been
paid to work on Debian LTS (links to individual
contributor reports are located below).
The team released 41 DLAs fixing 252 CVEs.
The team currently focuses on preparing security updates for Debian 11
bullseye , but also looks for contributing with updates for Debian 12
bookworm , Debian 13 trixie and even Debian unstable.
Notable security updates:
libsoup2.4 (DLA-4398-1),
prepared by Andreas Henrikson, fixing several vulnerabilities.
glib2.0 (DLA-4412-1),
published by Emilio Pozuelo Monfort, addressing multiple issues.
lasso (DLA-4397-1),
prepared by Sylvain Beucler, addressing multiple issues, including a critical
remote code execution (RCE) vulnerability
(CVE-2025-47151)
roundcube (DLA 4415-1),
prepared by Guilhem Moulin, fixing a cross-site-scripting (XSS)
(CVE-2025-68461)
and an information disclosure
(CVE-2025-68460)
vulnerabilities
mediawiki (DLA 4428-1),
published by Guilhem, fixing multiple vulnerabilities could lead to
information disclosure, denial of service or privilege escalation.
python-apt (DLA 4408-1), prepared by
Utkarsh Gupta, in coordination with the Debian Security Team and Julian
Andres Klode, the apt s maintainer.
libpng1.6 (DLA-4396-1),
published by Tobias Frost, completing the work started the previous month.
Notable non-security updates:
tzdata (DLA-4403-1),
prepared by Emilio, including the latest changes to the leap second list and
its expiry date, which was set for the end of December.
Contributions from outside the LTS Team:
Christoph Berg, co-maintainer of PostgreSQL in Debian, prepared a
postgresql-13 update, released as DLA-4420-1
The LTS Team has also contributed with updates to the latest Debian releases:
Andreas proposed trixie
and bookworm point updates for pgbouncer
Abhijith PA prepared a bookworm
point update for php-dompdf
Thorsten Alteholz prepared an unstable update and a
trixie point update for libcoap3
Thorsten prepared or completed different updates for unstable, trixie and
bookworm for packages related to cups: an
unstable update
of cups to fix several issues related to the latest security update, a
trixie point update for
libcupsfilters, and trixie and
bookworm point updates for cups-filter.
Here s my monthly but brief update about the activities I ve done in the F/L/OSS world.
Debian
Debian 13 was released! Woot!
Whilst I didn t get a chance to do much, here s still a few things that I worked on:
Helped Anshul with Golang 1.25 packaging and upload.
Assited Anshul in fixing Golang bugs in the stable release via a -pu.
Mentoring for newcomers.
Moderation of -project mailing list.
Ubuntu
I joined Canonical to work on Ubuntu full-time back in February 2021.
Whilst I can t give a full, detailed list of things I did, here s a quick TL;DR of what I did:
Utkarsh Gupta
did 15.0h (out of 1.0h assigned and 14.0h from previous period).
Evolution of the situation
In July, we released 24 DLAs.
Notable security updates:
angular.js, prepared by Bastien Roucari s, fixes multiple vulnerabilities including input sanitization and potential regular expression denial of service (ReDoS)
tomcat9, prepared by Markus Koschany, fixes an assortment of vulnerabilities
mediawiki, prepared by Guilhem Moulin, fixes several information disclosure and privilege escalation vulnerabilities
php7.4, prepared by Guilhem Moulin, fixes several server side request forgery and denial of service vulnerabilities
This month s contributions from outside the regular team include an update to thunderbird, prepared by Christoph Goehre (the package maintainer).
LTS Team members also contributed updates of the following packages:
commons-beanutils (to stable and unstable), prepared by Adrian Bunk
djvulibre (to oldstable, stable, and unstable), prepared by Adrian Bunk
git (to stable), prepared by Adrian Bunk
redis (to oldstable), prepared by Chris Lamb
libxml2 (to oldstable), prepared by Guilhem Moulin
commons-vfs (to oldstable), prepared by Daniel Leidert
Additionally, LTS Team member Santiago Ruano Rinc n proposed and implemented an improvement to the debian-security-support package. This package is available so that interested users can quickly determine if any installed packages are subject to limited security support or are excluded entirely from security support. However, there was not previously a way to identify explicitly supported packages, which has become necessary to note exceptions to broad exclusion policies (e.g., those which apply to substantial package groups, like modules belonging to the Go and Rust language ecosystems). Santiago s work has enabled the notation of exceptions to these exclusions, thus ensuring that users of debian-security-support have accurate status information concerning installed packages.
DebCamp 25 Security Tracker Sprint
The previously announced security tracker sprint took place at DebCamp from 7-13 July. Participants included 8 members of the standing LTS Team, 2 active Debian Developers with an interest in LTS, 3 community members, and 1 member of the Debian Security Team (who provided guidance and reviews on proposed changes to the security tracker); participation was a mix of in person at the venue in Brest, France and remote. During the days of the sprint, the team tackled a wide range of bugs and improvements, mostly targeting the security tracker.
The sprint participants worked on the following items:
Continued work (which was in progress prior to the sprint) on improved tooling to support security releases of packages from language ecosystems that rely heavily on static linking
As can be seen from the above list, only a small number of changes were brought to completion during the sprint week itself. Given the very compressed timeframe involved, the broad scope of tasks which were under consideration, and the highly sensitive data managed by the security tracker, this is not entirely unexpected and in no way diminishes the great work done by the sprint participants. The LTS Team would especially like to thank Salvatore Bonaccorso of the Debian Security Team for making himself available throughout the sprint to answer questions, for providing guidance on the work, and for helping the work by reviewing and merging the MRs which were able to merged during the sprint itself.
In the weeks that follow the sprint, the team will continue working towards completing the in progress items.
Thanks to our sponsors
Sponsors that joined recently are in bold.
Here s my 70th monthly but brief update about the activities I ve done in the F/L/OSS world.
Debian
This was my 79th month of actively contributing to Debian.
I became a DM in late March 2019 and a DD on Christmas 19! \o/
Debian was in freeze throughout so whilst I didn t do many uploads, there s a bunch of other things I did:
Attended DebConf25 in Brest, France.
Lead the bursary BOF and discussions.
Participated in other sessions, especially around the FTP masters.
I ve started to look at things with my trainee hat on.
Participated in the Debian Security Tracker sprints during DebCamp. More on that below.
Mentoring for newcomers.
Moderation of -project mailing list.
Ubuntu
This was my 54th month of actively contributing to Ubuntu.
I joined Canonical to work on Ubuntu full-time back in February 2021.
Whilst I can t give a full, detailed list of things I did (there s so much and some of it might not be public yet!), here s a quick TL;DR of what I did:
Got a recognition award for leading 24.04.2 LTS release and leading the Release Management team.
Preparing for the 24.04.3 LTS release early next month.
Debian (E)LTS
Debian Long Term Support (LTS) is a project to extend the lifetime of all Debian stable releases to (at least) 5 years. Debian LTS is not handled by the Debian security team, but by a separate group of volunteers and companies interested in making it a success.
And Debian Extended LTS (ELTS) is its sister project, extending support to the stretch and jessie release (+2 years after LTS support).
This was my 70th month as a Debian LTS and 57th month as a Debian ELTS paid contributor.
I only worked for 15.00 hours for LTS and 5.00 hours for ELTS and did the following things:
Coordinated with upstream due to lack of clarity on 1.11.4 being affected & not having a clear reproducer.
As 1.11.4 was still partially vulnerable and the backport was non-trivial, it was probably conveinent to bump the upstream version to 1.11.12 instead, fixing:
Helped Bastien with ca-certificates bit & coordinating with fellow Debian contributors.
Also triaged some newly supported packages for ELTS.
[LTS] Attended the monthly LTS meeting on IRC. Summary here.
Debian Security Tracker sprint 2025
Thanks to the LTS team for also organizing a security tracker sprint during DebCamp25. I attended the sprint and spent 10 hours working on the following tasks:
This includes some coordination with the web team and some back and forth with them to ensure both the Web team and the Security team would be happy with the fix. It also fixes more issues as mentioned in the description of the MR.
Show packages from next-point-release.txt in source package overview
Tobias Frost
did 2.5h (out of 12.0h assigned), thus carrying over 9.5h to the next month.
Evolution of the situation
In June, we released 35 DLAs.
Notable security updates:
mariadb-10.5, prepared by Otto Kek l inen, fixes vulnerabilities which could result in denial of service, information disclosure, or unauthorized data modification
python-django, prepared by Chris Lamb, fixes vulnerabilities which would result in log injection or denial of service
webkit2gtk, prepared by Emilio Pozuelo Monfort, fixes many vulnerabilities which could results in a wide range of issues
xorg-server, prepared by Emilio Pozuelo Monfort, fixes multiple vulnerabilities which may result in privilege escalation
sudo, prepared by Thorsten Alteholz, fixes a vulnerability which could result in privilege escalation
Notable non-security updates:
debian-security-support, prepared by Santiago Ruano Rinc n, updates status of packages which receive limited security support or which have reached the end of security support
dns-root-data, prepared by Sylvain Beucler, updates the DNSSEC trust anchors
This month s contributions from outside the regular team include the mariadb-10.5 update mentioned above, prepared by Otto Kek l inen (the package maintainer); an update to libfile-find-rule-perl, prepared by Salvatore Bonaccorso (a member of the Debian Security Team); an update to activemq, prepared by Emmanuel Arias (a maintainer of the package).
Additionally, LTS Team members contributed stable updates of the following packages:
curl, prepared by Carlos Henrique Lima Melara
python-tornado, prepared by Daniel Leidert
python-flask-cors, prepared by Daniel Leidert
common-vfs, prepared by Daniel Leidert
cjson, prepared by Adrian Bunk
icu, prepared by Adrian Bunk
node-tar-fs, prepared by Adrian Bunk
rar, prepared by Adrian Bunk
Something of particular noteworthiness is that LTS contributor Carlos Henrique Lima Melara discovered a regression in the upstream fix for CVE-2023-2753 in curl. The corrective action which he took included providing a patch to upstream, uploading a stable update of curl, and further updating the version of curl in LTS.
DebConf, the annual Debian Conference, is coming up in July and, as is customary each year, the week preceding the conference will feature an event called DebCamp. The DebCamp week provides an opportunity for teams and other interested groups/individuals to meet together in person in the same venue as the conference itself, with the purpose of doing focused work, often called sprints . LTS coordinator Roberto C. S nchez has announced that the LTS Team is planning to hold a sprint primarily focused on the Debian security tracker and the associated tooling used by the LTS Team and the Debian Security Team.
Thanks to our sponsors
Sponsors that joined recently are in bold.
Utkarsh Gupta
did 1.0h (out of 15.0h assigned), thus carrying over 14.0h to the next month.
Evolution of the situation
In May, we released 54 DLAs.
The LTS Team was particularly active in May, publishing a higher than normal number of advisories, as well as helping with a wide range of updates to packages in stable and unstable, plus some other interesting work. We are also pleased to welcome several updates from contributors outside the regular team.
Notable security updates:
containerd, prepared by Andreas Henriksson, fixes a vulnerability that could cause containers launched as non-root users to be run as root
libapache2-mod-auth-openidc, prepared by Moritz Schlarb, fixes a vulnerability which could allow an attacker to crash an Apache web server with libapache2-mod-auth-openidc installed
request-tracker4, prepared by Andrew Ruthven, fixes multiple vulnerabilities which could result in information disclosure, cross-site scripting and use of weak encryption for S/MIME emails
postgresql-13, prepared by Bastien Roucari s, fixes an application crash vulnerability that could affect the server or applications using libpq
dropbear, prepared by Guilhem Moulin, fixes a vulnerability which could potentially result in execution of arbitrary shell commands
openjdk-17, openjdk-11, prepared by Thorsten Glaser, fixes several vulnerabilities, which include denial of service, information disclosure or bypass of sandbox restrictions
glibc, prepared by Sean Whitton, fixes a privilege escalation vulnerability
Notable non-security updates:
wireless-regdb, prepared by Ben Hutchings, updates information reflecting changes to radio regulations in many countries
This month s contributions from outside the regular team include the libapache2-mod-auth-openidc update mentioned above, prepared by Moritz Schlarb (the maintainer of the package); the update of request-tracker4, prepared by Andrew Ruthven (the maintainer of the package); and the updates of openjdk-17 and openjdk-11, also noted above, prepared by Thorsten Glaser.
Additionally, LTS Team members contributed stable updates of the following packages:
rubygems and yelp/yelp-xsl, prepared by Lucas Kanashiro
simplesamlphp, prepared by Tobias Frost
libbson-xs-perl, prepared by Roberto C. S nchez
fossil, prepared by Sylvain Beucler
setuptools and mydumper, prepared by Lee Garrett
redis and webpy, prepared by Adrian Bunk
xrdp, prepared by Abhijith PA
tcpdf, prepared by Santiago Ruano Rinc n
kmail-account-wizard, prepared by Thorsten Alteholz
Other contributions were also made by LTS Team members to packages in unstable:
proftpd-dfsg DEP-8 tests (autopkgtests) were provided to the maintainer, prepared by Lucas Kanashiro
a regular upload of libsoup2.4, prepared by Sean Whitton
a regular upload of setuptools, prepared by Lee Garrett
Freexian, the entity behind the management of the Debian LTS project, has been working for some time now on the development of an advanced CI platform for Debian-based distributions, called Debusine. Recently, Debusine has reached a level of feature implementation that makes it very usable. Some members of the LTS Team have been using Debusine informally, and during May LTS coordinator Santiago Ruano Rinc n has made a call for the team to help with testing of Debusine, and to help evaluate its suitability for the LTS Team to eventually begin using as the primary mechanism for uploading packages into Debian. Team members who have started using Debusine are providing valuable feedback to the Debusine development team, thus helping to improve the platform for all users. Actually, a number of updates, for both bullseye and bookworm, made during the month of May were handled using Debusine, e.g. rubygems s DLA-4163-1.
By the way, if you are a Debian Developer, you can easily test Debusine following the instructions found at https://wiki.debian.org/DebusineDebianNet.
DebConf, the annual Debian Conference, is coming up in July and, as is customary each year, the week preceding the conference will feature an event called DebCamp. The DebCamp week provides an opportunity for teams and other interested groups/individuals to meet together in person in the same venue as the conference itself, with the purpose of doing focused work, often called sprints . LTS coordinator Roberto C. S nchez has announced that the LTS Team is planning to hold a sprint primarily focused on the Debian security tracker and the associated tooling used by the LTS Team and the Debian Security Team.
Thanks to our sponsors
Sponsors that joined recently are in bold.
Here s my 68th monthly but brief update about the activities I ve done in the F/L/OSS world.
Debian
This was my 77th month of actively contributing to Debian.
I became a DM in late March 2019 and a DD on Christmas 19! \o/
This month I ve just been sort of MIA, mostly because of a combination of the Canonical engineering sprints in Frankfurt, a bit of vacation in Italy, and then being sick. So didn t really get much done in Debian this month.
Ubuntu
This was my 53rd month of actively contributing to Ubuntu.
I joined Canonical to work on Ubuntu full-time back in February 2021.
Whilst I can t give a full, detailed list of things I did (there s so much and some of it might not be public yet!), here s a quick TL;DR of what I did:
Prepared for the engineering sprints in Frankfurt.
Delivered the Ubuntu knowledge sharing session during the sprints.
Released the first monthly snapshot of Ubuntu 25.10.
Got a recognition award for driving the Plucky Puffin release, nominated by Florent. \o/
Debian (E)LTS
Debian Long Term Support (LTS) is a project to extend the lifetime of all Debian stable releases to (at least) 5 years. Debian LTS is not handled by the Debian security team, but by a separate group of volunteers and companies interested in making it a success.
And Debian Extended LTS (ELTS) is its sister project, extending support to the buster, stretch, and jessie release (+2 years after LTS support).
This was my 68th month as a Debian LTS and 55th month as a Debian ELTS paid contributor.
Due to a combination of the Canonical engineering sprints in Frankfurt, a bit of vacation in Italy, and then being sick, I was barely able to do (E)LTS work. So this month, I worked for only 1.00 hours for LTS and 0 hours for ELTS.
I did the following things:
[LTS] Attended the hourly LTS meeting on IRC. Summary here.
Here s my 67th monthly but brief update about the activities I ve done in the F/L/OSS world.
Debian
This was my 76th month of actively contributing to Debian.
I became a DM in late March 2019 and a DD on Christmas 19! \o/
There s a bunch of things I do, both, technical and non-technical. Here s what I did:
Updating Matomo to v5.3.1.
Lots of bursary stuff for DC25. We rolled out the results for the first batch.
Helping Andreas Tille with and around FTP team bits.
Mentoring for newcomers.
Moderation of -project mailing list.
Ubuntu
This was my 51st month of actively contributing to Ubuntu.
I joined Canonical to work on Ubuntu full-time back in February 2021.
Whilst I can t give a full, detailed list of things I did (there s so much and some of it might not be public yet!), here s a quick TL;DR of what I did:
Jon, VP of Engineering, asked me to lead the Canonical Release team - that was definitely not something I saw coming. :)
We re now doing Ubuntu monthly releases for the devel releases - I ll be the tech lead for the project.
Preparing for the May sprints - too many new things and new responsibilities. :)
Debian (E)LTS
Debian Long Term Support (LTS) is a project to extend the lifetime of all Debian stable releases to (at least) 5 years. Debian LTS is not handled by the Debian security team, but by a separate group of volunteers and companies interested in making it a success.
And Debian Extended LTS (ELTS) is its sister project, extending support to the stretch and jessie release (+2 years after LTS support).
This was my 67th month as a Debian LTS and 54th month as a Debian ELTS paid contributor.
Due to DC25 bursary work, Ubuntu 25.04 release, and other travel bits, I only worked for 2.00 hours for LTS and 4.50 hours for ELTS.
I did the following things:
[ELTS] Had already backported patches for adminer for the following CVEs:
As the same CVEs are affected LTS, we decided to release for LTS first and then for ELTS but since I had no hours for LTS, I decided to do a bit more of testing for ELTS to make sure things don t regress in buster.
Will prepare LTS (and also s-p-u, sigh) updates this month and get back to ELTS thereafter.
[LTS] Started to prepare the LTS update for adminer for the same CVEs as for ELTS:
Haven t fully backported the patch yet but this is what I intend to do for this month (now that I have hours :D).
[LTS] Partially attended the LTS meeting on Jitsi. Summary here.
Partially because I was fighting SSO auth issues with Jitsi. Looks like there were some upstream issues/activity and it was resulting in gateway crashes but all good now.
I was following the running notes and keeping up with things as much as I could. :)
Last year, I decided to start participating in the Debian LTS and ELTS projects. It was a great opportunity to engage in
something new within the Debian community. I had been following these projects for many years, observing their evolution
and how they gained traction both within the ecosystem and across the industry.
I was curious to explore how contributors were working internally especially how they managed security patching and
remediation for older software. I ve always felt this was a particularly challenging area, and I was fortunate to
experience it firsthand.
As of April 2025, the Debian LTS project was primarily focused on providing security
maintenance for Debian 11 Bullseye. Meanwhile, the Debian ELTS project was
targeting Debian 8 Jessie, Debian 9 Stretch, and Debian 10 Buster.
During my time with the projects, I worked on a variety of packages and CVEs. Some of the most notable ones include:
There are several technical highlights I d like to share things I learned or had to apply while participating:
CI/CD pipelines: We used CI/CD pipelines on salsa.debian.org all the times to automate
tasks such as building, linting, and testing packages. For any package I worked on that lacked CI/CD integration,
setting it up became my first step.
autopkgtest: There s a strong emphasis on autopkgtest as the mechanism for running functional tests and ensuring
that security patches don t introduce regressions. I contributed by both extending existing test suites and writing
new ones from scratch.
Toolchain complexity for older releases: Working with older Debian versions like Jessie brought some unique
challenges. Getting a development environment up and running often meant troubleshooting issues with sbuild chroots,
qemu images, and other tools that don t just work like they tend to on Debian stable.
Community collaboration: The people involved in LTS and ELTS are extremely helpful and collaborative. Requests for
help, code reviews, and general feedback were usually answered quickly.
Shared ownership: This collaborative culture also meant that contributors would regularly pick up work left by
others or hand off their own tasks when needed. That mutual support made a big difference.
Backporting security fixes: This is probably the most intense and most rewarding activity. It involves manually
adapting patches to work on older codebases when upstream patches don t apply cleanly. This requires deep code
understanding and thorough testing.
Upstream collaboration: Reaching out to upstream developers was a key part of my workflow. I often asked if they
could provide patches for older versions or at least review my backports. Sometimes they were available, but most of
the time, the responsibility remained on us.
Diverse tech stack: The work exposed me to a wide range of programming languages and frameworks Python, Java, C,
Perl, and more. Unsurprisingly, some modern languages (like Go) are less prevalent in older releases like Jessie.
Security team interaction: I had frequent contact with the core Debian Security Team the folks responsible for
security in Debian stable. This gave me a broader perspective on how Debian handles security holistically.
In March 2025, I decided to scale back my involvement in the projects due to some changes in my personal
life. Still, this experience has been one of the highlights of my career, and I would definitely recommend it to others.
I m very grateful for the warm welcome I received from the LTS/ELTS community, and I don t rule out the possibility of
rejoining the LTS/ELTS efforts in the future.
The Debian LTS/ELTS projects are currently coordinated by folks at Freexian.
Many thanks to Freexian and sponsors for providing this opportunity!
Here s my 66th monthly but brief update about the activities I ve done in the F/L/OSS world.
Debian
This was my 75th month of actively contributing to Debian.
I became a DM in late March 2019 and a DD on Christmas 19! \o/
There s a bunch of things I do, both, technical and non-technical. Here s what I did:
Updating Rails to v7.2.2.1 for Trixie.
Updating Redmine to v6.0.4 for Trixie.
Kickstarting the bursary team for DC25.
Mentoring for newcomers.
Moderation of -project mailing list.
Ubuntu
This was my 50th month of actively contributing to Ubuntu.
Now that I joined Canonical to work on Ubuntu full-time, there s a bunch of things I do! \o/
I mostly worked on different things, I guess.
I was too lazy to maintain a list of things I worked on so there s
no concrete list atm. Maybe I ll get back to this section later or
will start to list stuff from the fall, as I was doing before. :D
Debian (E)LTS
Debian Long Term Support (LTS) is a project to extend the lifetime of all Debian stable releases to (at least) 5 years. Debian LTS is not handled by the Debian security team, but by a separate group of volunteers and companies interested in making it a success.
And Debian Extended LTS (ELTS) is its sister project, extending support to the stretch and jessie release (+2 years after LTS support).
This was my 66th month as a Debian LTS and 53rd month as a Debian ELTS paid contributor.
I worked for 15.00 hours for LTS and 7.50 hours for ELTS.
I did the following things:
Most of my Debian contributions this month were
sponsored by Freexian.
You can also support my work directly via
Liberapay.
OpenSSH
OpenSSH upstream released
9.9p2 with fixes for
CVE-2025-26465 and CVE-2025-26466. I got a heads-up on this in advance from
the Debian security team, and prepared updates for all of testing/unstable,
bookworm (Debian 12), bullseye (Debian 11), buster (Debian 10, LTS), and
stretch (Debian 9, ELTS). jessie (Debian 8) is also still in ELTS for a few
more months, but wasn t affected by either vulnerability.
Although I m not particularly active in the Perl team, I fixed a
libnet-ssleay-perl build failure because
it was blocking openssl from migrating to testing, which in turn was
blocking the above openssh fixes.
I also sent a minor sshd -T
fix upstream, simplified
a number of autopkgtests using the newish Restrictions:
needs-sudo facility, and prepared for
removing the obsolete slogin symlink.
PuTTY
I upgraded to the new upstream version
0.83.
GCC 15 build failures
I fixed build failures with GCC
15 in a few packages:
Python team
A lot of my Python team work is driven by its maintainer
dashboard.
Now that we ve finished the transition to Python 3.13 as the default
version, and inspired by a recent debian-devel thread started by
Santiago, I
thought it might be worth spending a bit of time on the uscan error
section. uscan is typically
scraping upstream web sites to figure out whether new versions are
available, and so it s easy for its configuration to become outdated or
broken. Most of this work is pretty boring, but it can often reveal
situations where we didn t even realize that a Debian package was out of
date. I fixed these packages:
cssutils (this in particular was very out of date due to a new and active
upstream maintainer since 2021)
In bookworm-backports, I updated python-django to 3:4.2.18-1 (issuing
BSA-121)
and added new backports of python-django-dynamic-fixture and
python-django-pgtrigger, all of which are dependencies of
debusine.
I went through all the build failures related to python-click 8.2.0 (which
was confusingly tagged but not fully released
upstream and posted an
analysis.
I fixed or helped to fix various other build/test failures:
Tobias Frost
did 12.0h (out of 10.5h assigned and 1.5h from previous period).
Evolution of the situation
In November, we have released 38 DLAs.
The LTS coordinators, Roberto and Santiago, delivered a talk at the Mini-DebConf event in Toulouse, France. The title of the talk was How LTS goes beyond LTS . The talk covered work done by the LTS Team during the past year. This included contributions related to individual packages in Debian (such as tomcat, jetty, radius, samba, apache2, ruby, and many others); improvements to tooling and documentation useful to the Debian project as a whole; and contributions to upstream work (apache2, freeimage, node-dompurify, samba, and more). Additionally, several contributors external to the LTS Team were highlighted for their contributions to LTS. Readers are encouraged to watch the video of the presentation for a more detailed review of various ways in which the LTS team has contributed more broadly to the Debian project and to the free software community during the past year.
We wish to specifically thank Salvatore (of the Debian Security Team) for swiftly handling during November the updates of needrestart and libmodule-scandeps-perl, both of which involved arbitrary code execution vulnerabilities. We are happy to see increased involvement in LTS work by contributors from outside the formal LTS Team.
The work of the LTS Team in November was otherwise unremarkable, encompassing the customary triage, development, testing, and release of numerous DLAs, along with some associated contributions to related packages in stable and unstable.
Thanks to our sponsors
Sponsors that joined recently are in bold.
Tobias Frost
did 17.0h (out of 7.5h assigned and 9.5h from previous period).
Evolution of the situation
In September, we have released 52 DLAs.
September marked the first full month of Debian 11 bullseye under the responsibility of the LTS Team and the team immediately got to work, publishing more than 4 dozen updates.
Some notable updates include ruby2.7 (denial-of-service, information leak, and remote code execution), git (various arbitrary code execution vulnerabilities), firefox-esr (multiple issues), gnutls28 (information disclosure), thunderbird (multiple issues), cacti (cross site scripting and SQL injection), redis (unauthorized access, denial of service, and remote code execution), mariadb-10.5 (arbitrary code execution), cups (arbitrary code execution).
Several LTS contributors have also contributed package updates which either resulted in a DSA (a Debian Security Announcement, which applies to Debian 12 bookworm) or in an upload that will be published at the next stable point release of Debian 12 bookworm. This list of packages includes cups, cups-filters, booth, nghttp2, puredata, python3.11, sqlite3, and wireshark. This sort of work, contributing fixes to newer Debian releases (and sometimes even to unstable), helps to ensure that upgrades from a release in the LTS phase of its lifecycle to a newer release do not expose users to vulnerabilities which have been closed in the older release.
Looking beyond Debian, LTS contributor Bastien Roucari s has worked with the upstream developers of apache2 to address regressions introduced upstream by some recent vulnerability fixes and he has also reached out to the community regarding a newly discovered security issue in the dompurify package. LTS contributor Santiago Ruano Rinc n has undertaken the work of triaging and reproducing nearly 4 dozen CVEs potentially affecting the freeimage package. The upstream development of freeimage appears to be dormant and some of the issues have languished for more than 5 years. It is unclear how much can be done without the aid of upstream, but we will do our best to provide as much help to the community as we can feasibly manage.
Finally, it is sometimes necessary to limit or discontinue support for certain packages. The transition of a release from being under the responsibility of the Debian Security Team to that of the LTS Team is an occasion where we assess any pending decisions in this area and formalize them. Please see the announcement for a complete list of packages which have been designated as unsupported.
Thanks to our sponsors
Sponsors that joined recently are in bold.
Evolution of the situation
In July, we have released 1 DLA.
August will be the month that Debian 11 makes the transition to LTS. Our
contributors have already been hard at work with preparatorty tasks and also
with making contributions to packages in Debian 11 in close collaboration with
the Debian security team and package maintainers. As a result, users and
sponsors should not observe any especially notable differences as the transition
occurs.
While only one DLA was released in July (as a result of the transitional state
of Debian 11 bullseye ), there were some notable highlights. LTS contributor
Guilhem Moulin prepared an update of libvirt for Debian 11 (in collaboration
with the Old-Stable Release Managers and the Debian Security Team) to fix a
number of outstanding CVEs which did not rise to the level of a DSA by the
Debian Security Team. The update prepared by Guilhem will be included in Debian
11 as part of the final point release at the end of August, one of the final
transition steps by the Release Managers as Debian 11 moves entirely to the LTS
Team s responsibility. Notable work was also undertaken by contributors Lee Garrett
(fixes on the ansible test suite and a bullseye update), Lucas Kanashiro (Rust toolchain, utilized by the clamav,
firefox-esr, and thunderbird packages), and Sylvain Beucler (fixes on the ruby2.5/2.7 test
suites and CI infrastructure), which will help improve the quality of updates produced during
the next LTS cycle.
June was the final month of LTS for Debian 10 (as announced on the
debian-lts-announce
mailing list). No additional Debian 10 security updates will be made available
on security.debian.org.
However, Freexian and its team of paid Debian contributors will continue
to maintain Debian 10 going forward for customers of the
Extended LTS offer. Subscribe right
away if you still have Debian 10 systems which must be kept secure (and which
cannot yet be upgraded).
Thanks to our sponsors
Sponsors that joined recently are in bold.
Tobias Frost
did 16.0h (out of 15.0h assigned and 1.0h from previous period).
Utkarsh Gupta
did 5.5h (out of 5.0h assigned and 26.0h from previous period), thus carrying over 25.5h to the next month.
Evolution of the situation
In May, we have released 34 DLAs.
Several of the DLAs constituted notable security updates to LTS during the month of May. Of particular note were the linux (4.19) and linux-5.10 packages, both of which addressed a considerable number of CVEs. Additionally, the postgresql-11 package was updated by synchronizing it with the 11.20 release from upstream.
Notable non-security updates were made to the distro-info-data database and the timezone database. The distro-info-data package was updated with the final expected release date of Debian 12, made aware of Debian 14 and Ubuntu 23.10, and was updated with the latest EOL dates for Ubuntu releases. The tzdata and libdatetime-timezone-perl packages were updated with the 2023c timezone database. The changes in these packages ensure that in addition to the latest security updates LTS users also have the latest information concerning Debian and Ubuntu support windows, as well as the latest timezone data for accurate worldwide timekeeping.
LTS contributor Anton implemented an improvement to the Debian Security Tracker Unfixed vulnerabilities in unstable without a filed bug view, allowing for more effective management of CVEs which do not yet have a corresponding bug entry in the Debian BTS.
LTS contributor Sylvain concluded an audit of obsolete packages still supported in LTS to ensure that new CVEs are properly associated. In this case, a package being obsolete means that it is no longer associated with a Debian release for which the Debian Security Team has direct responsibility. When this occurs, it is the responsibility of the LTS team to ensure that incoming CVEs are properly associated to packages which exist only in LTS.
Finally, LTS contributors also contributed several updates to packages in unstable/testing/stable to fix CVEs. This helps package maintainers, addresses CVEs in current and future Debian releases, and ensures that the CVEs do not remain open for an extended period of time only for the LTS team to be required to deal with them much later in the future.
Thanks to our sponsors
Sponsors that joined recently are in bold.
Here s my (forty-first) monthly but brief update about the activities I ve done in the F/L/OSS world.
Debian
This was my 50th month of actively contributing to Debian.
I became a DM in late March 2019 and a DD on Christmas 19! \o/
There s a bunch of things I do, both, technical and non-technical. Here are the things I did this month:
libyang2 (2.1.30-2) - Adding DEP8 test for yangre.
redmine (5.0.4-3) - Add patch to stop unnecessary recursive chown ing (Fixes: #1022816, #1022817).
redmine (5.0.4-4) - Set DH_RUBY_IGNORE_TESTS to all (Fixes: #1031308).
python-jira (3.4.1-1) - New upstream version, v3.4.1.
Others
Looked up some Release team documentation.
Sponsored php-font-lib and php-dompdf-svg-lib for William.
Granted DM rights for php-dompdf.
Mentoring for newcomers.
Reviewed micro bits for Nilesh, new uploads and changes.
Ruby sprints.
Bug work (on BTS and #debian-ruby) for rails and redmine.
Moderation of -project mailing list.
A huge thanks to Freexian for sponsoring my Debian work and Entrouvert for sponsoring the Redmine backports. :D
Ubuntu
This was my 25th month of actively contributing to Ubuntu.
Now that I joined Canonical to work on Ubuntu full-time, there s a bunch of things I do! \o/
I mostly worked on different things, I guess.
I was too lazy to maintain a list of things I worked on so there s
no concrete list atm. Maybe I ll get back to this section later or
will start to list stuff from the fall, as I was doing before. :D
Debian (E)LTS
Debian Long Term Support (LTS) is a project to extend the lifetime of all Debian stable releases to (at least) 5 years. Debian LTS is not handled by the Debian security team, but by a separate group of volunteers and companies interested in making it a success.
And Debian Extended LTS (ELTS) is its sister project, extending support to the stretch and jessie release (+2 years after LTS support).
This was my forty-first month as a Debian LTS and thirty-second month as a Debian ELTS paid contributor.
I worked for 24.25 hours for LTS and 28.50 hours for ELTS.
LTS CVE Fixes and Announcements:
Fixed CVE-2022-47016 for tmux and uploaded to buster via 2.8-3+deb10u1.
But decided to not roll the DLA for the package as the CVE got rejected upstream.
Worked on ruby-rails-html-sanitize and added notes to the security-tracker.
TL;DR: we need newer methods in ruby-loofah to make the patches for ruby-rails-html-sanitize backportable.
Started to look at other set of packages meanwhile.
ELTS CVE Fixes and Announcements:
Issued ELA 813-1, fixing CVE-2017-12618 and CVE-2022-25147, for apr-util.
For Debian 8 jessie, these problems have been fixed in version 1.5.4-1+deb8u1.
For Debian 9 stretch, these problems have been fixed in version 1.5.4-3+deb9u1.
Issued ELA 815-1, fixing CVE-2022-44792 and CVE-2022-44793, for net-snmp.
For Debian 8 jessie, these problems have been fixed in version 5.7.2.1+dfsg-1+deb8u6.
For Debian 9 stretch, these problems have been fixed in version 5.7.3+dfsg-1.7+deb9u5.
Helped facilitate RabbitMQ s update queries by one of our customers.
Started to look at other set of packages meanwhile.
Following up on my previous 
The Debian LTS Team, funded by [Freexian s Debian LTS offering]
(
Last year, I decided to start participating in the Debian LTS and ELTS projects. It was a great opportunity to engage in
something new within the Debian community. I had been following these projects for many years, observing their evolution
and how they gained traction both within the ecosystem and across the industry.
I was curious to explore how contributors were working internally especially how they managed security patching and
remediation for older software. I ve always felt this was a particularly challenging area, and I was fortunate to
experience it firsthand.
As of April 2025, the 
Most of my Debian contributions this month were
