Development

7 steps for publishing a DLA

Debian Long Term Support Security Advisory (DLA)

How-to prepare security updates for LTS

Contributing to Debian Long Term Support

The Debian LTS team is always looking for more volunteers to do a better job. With more resources, we could for example:

  • support packages that are currently unsupported

  • take care of all Debian packages and not only the most popular ones

  • fix lower priority issues

If you want to get involved in the LTS team and help keep Debian packages secure for 5 years, have a look at this page. We assume that you are already familiar with the repository layout described in LTS/Using and that you are subscribed to the LTS mailing list: http://lists.debian.org/debian-lts/

You can help in many ways:

Test updated packages and report regressions

As a simple user, you can test packages that have been updated (or that are in the process of being updated). If you find a regression (i.e. something that used to work and that no longer works), then please report it to debian-lts@lists.debian.org and put the person who prepared the update in copy (in case they are not subscribed to the list).

Many LTS contributors are looking for testers for their updated packages. They send call for tests on the mailing list, so please subscribe to it and test the packages they provide when you can, and report back whether they work for you.

Debian Security Tracker

The Debian LTS team makes extensive use of the Debian Security Tracker. This is a database of all known security issues in Debian.

LTS developers must keep the security tracker up-to-date. In particular:

  • data/CVE/list: large, single-file text-base database of all current and past CVEs, for non-LTS and LTS Debian dists. Includes links to related bug reports, upstream commits, fixing versions, exploits, and any information useful to the Security and LTS teams.

  • data/dla-needed.txt: LTS work queue.

  • data/DLA/list: semi-automated reference list of DLAs with affected packages and CVEs.

To work on the security tracker, clone the repository.

git clone git@salsa.debian.org:security-tracker-team/security-tracker.git
cd security-tracker/
sudo apt install jq python3-apt
bin/setup-repo

Note

The git repository is heavy and a first normal clone will easily take an hour. For occasional work, a shallow clone (with --depth 1) will only take a few minutes.

Attention

Please run bin/setup-repo, which installs a pre-commit hook to validate syntax (and avoid breaking web interface updates).

Prepare security updates for LTS

Claim the issue in the security tracker (in dla-needed.txt)

In order to prevent duplication of effort, make sure the issue is listed in the data/dla-needed.txt file from the security tracker and add your name to it. Normally, packages are triaged by Front Desk in dla-needed.txt first.

dla-needed.txt reflects LTS-specific information, such as who is working on a package, requests for help, or problems encountered.

Do not add packages to dla-needed.txt (bypass front desk by self-triaging) when you are not at front desk. The exception is when front desk is unresponsive (for more than 1-2 working days) or when the issue is really critical and timely release is important (e.g. embargoed issues). In that case, notify front desk about it, and document the bypass reason in the git commit message (for clarity to FD and other contributors).

As mentioned in the previous section, make sure to also review and update the relevant information in data/CVE/list when working on a package for LTS work.

You shall only claim it for the time you do active work. You are expected to actively handle the problem within 2-3 days and then you are expected to announce your intention to upload so others can test it for a few (3-4) more days. If you can not solve the problem within the 2-3 days, then please mention why it takes more time, how far you have gone, the preliminary results and/or free it for someone else to work on it. We do not want people to work on a package for a few hours, wait a few days, work again on it, wait more and so on.

Edit the data/dla-needed.txt file:

$ editor data/dla-needed.txt
$ git commit -m "Claim foo in dla-needed.txt" data/dla-needed.txt
$ git push

If the package you worked on got unclaimed by the coordinator after 2 weeks of apparent inactivity, and you want to re-claim it, do not only restore your name/claim, but also add information about your progress and/or difficulties. Please add a new NOTE line with the current date, and detail the progress status (not just “WIP”, for instance “waiting for feedback from maintainer” or “fixing multiple testsuite failures”). That way the coordinator and other contributors can see whether you’re e.g. just facing lengthy work, lacking time (and could hand over your work to another contributor), or could use additional help.

Special case: can’t be fixed

If a CVE is too hard to fix, first unclaim the package in dla-needed.txt and leave a note describing the approach and difficulties.

Then, depending on the difficulties and issue severity, either:

  1. Leave the package for someone else to attempt.

  2. If severity is low, or a work-around exists, tag the issue <ignored> (cf. CVE status list for LTS) then drop the package from dla-needed.txt:

    [buster] - SRCPKG <ignored> (Minor issue; Easily worked around by ... hard to backport due to ...)

  3. If the issue is high-severity, a newer version of the package may need to be backported. Discuss this at debian-lts@lists.debian.org and open a backport proposal at lts-updates-tasks.

Build the update

Attention

In general, your work should be done in the maintainer’s repo (on an appropriate DEP-14 branch, and assuming that the maintainer is willing to have LTS work done in the main repo), or in a fork on Salsa. Please look at Git workflow for the (E)LTS packages for details. Only if neither the maintainer repo nor the fork on Salsa are possible, should the work be done in a new project under the lts-team/packages group in Salsa.

Backport the fix to the version in LTS (in case there’s already been an earlier update). Make sure that the fix was approved by the upstream project (e.g. committed to their development repository), sometimes early patches proposals are erroneous or incomplete. If there is no fix, it is fine to work on a new one: be a good citizen and contribute the patch back upstream and make sure the maintainer and regular security teams will be aware of them, by adding it to a bug report against the package and linking that bug report in the security tracker. (If the issue being addressed requires AddressSanitizer in order to reproduce the vulnerability and confirm the fix, then Development Asan may be helpful).

If the fix comes with new binary files (e.g. test cases), they won’t be accepted by quilt, but you can reference them in debian/source/include-binaries and they’ll be included in the .debian.tar.xz file directly (discussion).

In debian/changelog, you need to set the target distribution to “buster-security”. The versioning follows the conventions already used at security.debian.org. Historically codenames have been used as version numbers, but this was changed some time ago as version numbers are more deterministic.

  • If you use dch (pre-buster) to make the changelog entry, note that it may include the text “Non-maintainer upload by the Security Team.” It is important to change that line to avoid giving the appearance of support by the Debian Security Team. Cf. DebianBug:762715 (now uses: “Non-maintainer upload by the LTS Security Team.”).

  • If a package already e.g. had a +deb10u1 update, use +deb10u2 for the next update.

  • If a package hasn’t seen an update, use +deb10u1 for the next update.

  • For the rare cases where new upstream versions are introduced:

    • make sure to use a lower version than in bullseye. See this discussion. Just don’t use +busterX as this will cause problems!

    • Always use deb10u1 , regardless how many uploads have been done previously.

  • For the rare case where backports of the entire package from newer distributions is required (as opposed to just the fix), it is expected that the changelog will not be in incrementing version order.

BTS numbers can be referenced but are currently not processed.

Note that for non-native packages, first uploads to security-master need to include the source tarball (even if it’s already present in the distribution you’re uploading to) by using dpkg-buildpackage -sa; check at http://security.debian.org/pool/ or try rmadison -u qa PACKAGE.

Make sure you use a clean chroot for building the binary packages. Using sbuild/pbuilder is recommended. For instance:

# Init
sudo pbuilder --create --basetgz /var/cache/pbuilder/base-buster.tgz --distribution buster --othermirror 'deb http://security.debian.org/ buster/updates main contrib'
sudo pbuilder --update --basetgz /var/cache/pbuilder/base-buster.tgz
# Rebuild source and binary packages from buster (in extracted source)
export DEB_BUILD_OPTIONS="parallel=$(nproc)"
pdebuild --use-pdebuild-internal --buildresult .. --debbuildopts '-S' -- --basetgz /var/cache/pbuilder/base-buster.tgz
# Rebuild binary packages from buster, reproducing buildd's separate build-indep/build-arch
# - first security upload:
sudo --preserve-env=DEB_BUILD_OPTIONS pbuilder --build --basetgz /var/cache/pbuilder/base-buster.tgz --source-only-changes --logfile build-indep.log --buildresult . --binary-indep --debbuildopts '-sa' package+deb10u1.dsc
sudo --preserve-env=DEB_BUILD_OPTIONS pbuilder --build --basetgz /var/cache/pbuilder/base-buster.tgz --source-only-changes --logfile build-arch.log  --buildresult . --binary-arch  --debbuildopts '-sa' package+deb10u1.dsc
# - later uploads:
sudo --preserve-env=DEB_BUILD_OPTIONS pbuilder --build --basetgz /var/cache/pbuilder/base-buster.tgz --source-only-changes --logfile build-indep.log --buildresult . --binary-indep package+deb10u2.dsc
sudo --preserve-env=DEB_BUILD_OPTIONS pbuilder --build --basetgz /var/cache/pbuilder/base-buster.tgz --source-only-changes --logfile build-arch.log  --buildresult . --binary-arch  package+deb10u2.dsc

To actually build the binary package, you may want to use a porter box, especially if you need to fix a regression that concerns a specific architecture you may not have access to, see PorterBoxHowToUse for instructions on how to use porterboxes.

See also:

Test the update

See TestSuites for package-specific test instructions.

If there’s a built-in test suite, make sure it runs fine at build-time in the LTS environment. It is acceptable to enable or even backport test suites from later releases if they are available.

There can also be DEP-8 tests in debian/tests/, to run with autopkgtest.

See for instance TestSuites/rails for a direct run or TestSuites/sane-backends for a full LXC environment.

If there are no test suites available, you will need to run and test the package directly. Prefer a full environment (virtualized or sometimes even physical).

Do check the reverse-dependencies (find-rdeps, apt-rdepends -r, dose-ceve from dose-extra) and install some of them, to check if your package still runs correctly with them.

It is worth testing with both a 32- and 64-bit architecture, see e.g. CVE-2019-14866.

Check your package update with generic tools as well:

# check for common packaging issues in last build
# from extracted source after build, buster host (only check new errors)
lintian -i
# inspect source changes
debdiff package+deb10u3.dsc package+deb10u4.dsc | diffstat
debdiff package+deb10u3.dsc package+deb10u4.dsc | less
# inspect binary changes
debdiff --from deb10u3/*.deb --to deb10u4/*.deb
# test package upgrade
sudo piuparts -d buster \
  --extra-repo='deb http://security.debian.org/ buster/updates main contrib' \
  -l piuparts-package.log \
  -I :etc/buggy-dep \
  --single-changes-list package+deb10u4_{all,amd64}.changes \
  | grep -P '(INFO|ERROR):'
# also consider --install-remove-install

Depending on the urgency of the security fix, and your confidence on your own work, you might want to seek reviews from interested parties (such as upstream authors, Debian maintainers, security team, LTS team, etc.). If you ask for reviews, you should supply the following information:

  1. A generated debdiff against the previous version in LTS.

  2. A link to a test package that can be downloaded and tested.

It is common for LTS workers to upload their packages to a personal repository in people.debian.org, but any public repository or even simple webserver will do. A few guidelines for those temporary uploads:

  • sign the packages (using debsign, for example) so that users can verify package integrity

  • make sure to have the target distribution set to UNRELEASED so that nobody else can upload them before they are ready.

Upload the update

Uploads to Debian LTS do not wait for a DLA or any other manual intervention before being installed into the Debian Archive. In this regard, they are different from stable security uploads.

If you’re satisfied with your tests, upload to security-master, using dput or dput-ng :

dput security-master hello_1.0-1+deb10u1_source.changes

Once the upload is accepted, an email will be sent to you and to the debian-lts-changes mailing list, confirming the update has been released into the Debian archive. The BTS bot will also announce it in the #debian-devel-changes channel. (wait for ~30mn)

The package will then be auto-built for all the available architectures. Check the build logs at:

Troubleshooting:

Built-Using refers to non-existing source package: if your package is rejected with this reason, open a bug against package ftp.debian.org requesting to add the missing package, see e.g. #974877 or #974954. For the same reason, the package may also be accepted but then unexplicably stalls in the “Uploaded” (not “Installed”) stage in the buildd status (#1033604).

Non-free packages: currently (2022-01-19) buildds won’t build source-only uploads to security-master (a bug, according to Aurélien Jarno), impacting packages such as amd64-microcode and firmware-linux-nonfree. Instead, upload the full “source-code” + the amd64 binary packages (build with -sa and upload the _amd64.changes file); then upload only the i386 binary packages (dpkg-buildpackage -b; or use changestool from reprepro to exclude unwanted files from the changes file).

Claim a DLA ID in DLA/list

Once your upload has been built successfully, you can go ahead with the DLA.

Please make an effort to send out announcement for anything released via security.debian.org with not too much delay; there’s all kinds of processes by people out there who react on those emails and there’s also people who get suspicious if an update is available without a corresponding announcement.

Run bin/gen-DLA in the top directory of the Git repository. It automatically generates an entry in data/DLA/list and asks you to commit the changes to ensure that no IDs are used twice. The following command would add an entry for src:hello fixing CVE-2014-0666 and creates an advisory template in the top directory of your security-tracker checkout.

$ DEBFULLNAME=xxx bin/gen-DLA --save hello CVE-2014-0666
# OR
$ DEBFULLNAME=xxx bin/gen-DLA --save .../hello_1.2-3+deb10u4_source.changes

That list of CVE will make sure that the security tracker is aware of the fix and mark the issues as resolved for that specific package.

gen-DLA will automatically remove prior suite triage for the fixed vulnerabilities (e.g. [buster] - package <postponed>). However, the DLA-XXXX-1 annotation will be added by the bi-daily cron, and the fixed version will be inferred automatically (don’t add it).

Announce the update

Only send the DLA to the mailing list when you have confirmed that the package was processed and built on all supported architectures.

Send mail to the debian-lts-announce mailing list. The mail needs to be signed by a GPG key in the debian or debian-maintainers keyring. Inline signatures always work (PGP/MIME check works with mutt but fails with Thunderbird).

The advisory template has been created by bin/gen-DLA (see before) and generally looks like this:

Subject: [SECURITY] [DLA $DLA-1] $SOURCEPACKAGENAME security update

Package        : $SOURCEPACKAGENAME
Version        : $LTS_VERSION
CVE ID         : CVE-2014-0001 CVE-2014-0002
Debian Bug     : 12345

DLA text goes here
[...]

In addition to describing the vulnerabilities, remember to add a short package description, so the audience can better understand the context and whether they are affected.

Please also don’t append your personal signatures to DLAs.

If you use mutt, a simple way to send it is to use

mutt -e "unset signature" -H DLA-123

Simple mail command works:

cat DLA-body.txt \
  | gpg --clearsign \
  | mail -s "[SECURITY] [DLA XXXX-X] $SOURCEPACKAGENAME security update" \
         -a "From: You <you@debian.org>" \
         debian-lts-announce@lists.debian.org
Official documentation:

When all this is done, you should remove the package from other locations it was uploaded to in the test section, if any.

Publish the Git repository and tags

Cf. Git workflow for the (E)LTS packages.

You may verify using the coordinator’s check:

$ bin/package-operations --advisory dla --days=1 --check-dla-git-tag

Prepare regression updates for LTS

If an upload introduces a regression, it needs to be fixed as soon as possible.

Steps for a regression update

  1. Fix the package.

  2. Do a test build and test installation. Verify the regression issue and also the original issue are really resolved now.

  3. Make sure you use a clean chroot for building. Using sbuild/pbuilder is recommended.

  4. Upload the fixed package to buster-security.

  5. Use gen-DLA script to add a DLA entry to data/DLA/list and to provide you with an announcement email template. Two possible options:

  1. The regression fixes the previous upload of the package:

$ bin/gen-DLA  --save $SOURCEPACKAGENAME regression

  1. The regression fixes an earlier than the previous upload of the package:

$ bin/gen-DLA  --save $PREVIOUS_DLA_ID $SOURCEPACKAGENAME regression
# /!\ $PREVIOUS_DLA_ID needs to be incremented (-1 -> -2)...

  1. If this is a security regression (e.g. incomplete or missing fix), reference the CVE ID in the data/DLA/list entry, otherwise (functional regression) do not reference it.

  2. Wait for the uploaded package to arrive in the buster-security repository.

  3. In the base folder of the security-tracker Git repository, you can find an auto-generated LTS announcement template file with name DLA-$DLA-{2,3,4...}. Use this file as the template for your regression fix announcement. Don’t commit this file to Git(!). Copy+paste the announcement template to your email application, complete/edit it manually and finally send the regression fix DLA email to debian-lts-announce@lists.debian.org.

  4. Note: if a DLA requires a fix in another package, use the same DLA major number (see this mail)

Triage security issues

The Security and LTS teams cooperate to process the flow of new security issues. Each is assigned a CVE number, so we often call this “CVE triage”.

Caution

You must first get familiar with the Security Tracker before committing.

CVE status list for LTS

Important

The reference documentation for data/CVE/list classification remains the security tracker documentation. Do read it first.

There are some differences between LTS and Debian Security triaging:

  • LTS currently does not have any point releases.

  • The LTS Team prepares the vast majority of updates (few maintainers want to help with the LTS fixes).

In the context of LTS (currently [buster]), here’s a break-down of each possible CVE status:

  • <postponed> when it’s a minor issue that is not critical to address immediately, but may be fixed later.

  • <ignored> when there is a valid/strong reason not to fix it (e.g. it is only in sources neither compiled nor shipped in binary packages; it’s non-critical and too hard to backport; it’s non-critical and requires an API change affecting reverse dependencies).

  • <not-affected> when LTS version is not affected (e.g. because the vulnerable code was introduced later). Good practice: find and reference the related commit (in “NOTE: Introduced by …”), because vulnerable code often gets moved around between upstream releases. If all versions are unaffected, tag at the package-level (e.g. - python3.7 <not-affected>, without [buster]).

  • <end-of-life> when the package is not supported in the LTS release (buster unsupported packages are listed at debian-security-support:security-support-ended.deb10). If needed, update that file and add debian-security-support to dla-needed.txt – cf. debian-security-support:README.source.)

  • specific version: any later version is considered fixed. Normally not used, in favor of the automated {DLA-XXXX-X} tags.

  • <undetermined>: rare, set at the package level by secteam, we don’t use this tag, but you can help find more information.

Attention

<no-dsa> is often used by the Security Team to indicate a first level of triage: no immediate DSA (aka package update), but maybe a delayed fix in the next point release, or just deferring to the maintainer [doc].

We decided to stop using <no-dsa> starting 2024-03, due to its vagueness and ambiguity in the context of LTS, in favor of its sub-states <postponed> and <ignored>. Old no-dsa LTS entries can be considered <postponed>.

Note

LTS triage normally tags dist-level (buster) entries, while higher, package-level tagging is reserved to secteam. We only tag at the package level for LTS-specific packages. Contact secteam if you have a recommendation for other package-level entries.

Severity levels are normally set by the Security Team, coordinate with them if needed. A couple notes:

  • “minor”: the Security Team tends to mark non-Internet-facing vulnerabilities as <some tag> (Minor) with default severity, because those are not directly exploitable. However they allow greater penetration when the attacker put one foot in the victim’s infrastructure and are better fixed in the long run.

  • unimportant: caution, makes the CVE disappear from all our tooling.

  • other states: rarely used in practice.

Hint at your thought process through a comment or a NOTE:

[buster] - package <postponed> (Minor issue, local OOM DoS)

NOTE: PoC doesn't trigger in buster.

You may expand your rationale in the Git commit message, this helps secteam review your changes, but makes it harder for others to notice or search it later.

Initial package triage for LTS

This is normally done by Front Desk (see Claim the issue in the security tracker).

Guiding principles:

  • Reactivity.

  • Risks assessment (e.g. security vs. regression).

  • Reduce end users’ (e.g. sysadmins) load with too many updates (daemon restarts, large network upgrades…).

  • Use the sponsors’ funding efficiently.

  • Avoid confusing users with discrepancies between LTS and non-LTS dists.

Run bin/lts-cve-triage.py to gather a list of security issues in the LTS release and group them by status.

The script includes sources which you may check manually:
but doesn’t handle:
and explicitly excludes:

  • Packages already added to dla-needed.txt (beware if they stay there for too long; check debian-lts:./find-work and the coordinators’ weekly e-mail about older than 21 days packages).

  • Issues already triaged, in particular <postponed>.

  • Issues with severity unimportant.

Package/CVE evaluation

Triaging packages requires gathering information on the CVE, weighing each piece, analyzing carefully, and making an educated decision. This is not a yes/no process and is hardly automatable.

This includes the following criteria and considerations:

  • Package security Debian support status: supported, limited, ended/unsupported; see debian-security-support + non-free + we don’t support games. Attention: unsupported packages may still be sponsored, contact the LTS Coordinator if that looks like an oversight.

  • LTS version vulnerable/not-affected: verify this during triage (if can be done in a reasonable amount of time).

  • Severity of the CVEs: critical issues are often embargoed and treated privately; 0-day exploits need to be fixed ASAP; most issues are non-critical.

  • Package criticality: security sensitivity (e.g. CLI tool vs. exposed Internet service); LTS sponsorship (means we should fix it, cf. debian-lts:./find-work); size of user base (caution: popcon may not be a good indicator especially for private server components); number of reverse dependencies.

  • CVE processed in Debian: the CVE can be: reported to sid, fixed in sid, triaged by secteam, or affect a LTS-specific package; if non-critical and nothing happened yet, wait for a couple days rather than triage prematurely.

  • Package maintainers willing to do the update: see Contact the maintainers.

  • Fixability: patch availability (for dead or uncooperative upstreams, consider updating debian-security-support); backport complexity (regression risk, ability to backport a new upstream version without rdeps breakage, time requirement).

  • Number of pending CVEs: since LTS doesn’t have point releases, we handle them when too many postponed issues piled up, or there is a more serious issue.

  • Date of the last package DLA: neither too frequent, to avoid impacting users (see guiding principles above); neither too infrequent, to avoid dragging too many changes (i.e. regression risks) at once.

  • Past triage: if we have consistently ignored certain type of CVEs for a certain package in the past, there’s usually a good reason.

  • Alignment with other Debian dists: Security Team is taking similar decisions daily and we usually follow them. We should follow promptly if explicit fixes were published (DSA, stable/oldstable point release), or if a DSA is planned in dSa-needed.txt. Conversely we can offer to fix no-dsa/postponed issues in stable if we can fix them in LTS.

  • Vulnerability exposure in the press: this usually exaggerates severity to interested/worried users and prompts for more reactivity.

There are only 2 possible outcomes:

  • The CVE does not trigger an immediate package update and is triaged.

  • The package is added to dla-needed.txt so that someone else prepares a package update and close the CVE(s).

In doubt, check with the other LTS contributors, the package maintainers or the Security Team. If pressed for time, add the package to dla-needed.txt, with a NOTE: about the doubt, and let another team member double-check the vulnerability.

Adding a package

To add a package into dla-needed.txt or ela-needed.txt, please use the package-operations script from the debian-lts repo:

bin/package-operations --lts  --add --package $packagename
bin/package-operations --elts --add --package $packagename

This script creates a package record in packages.xml with central info (like attention notes, maintainer being part of LTS team, reference Git repository, etc.) Don’t pre-create the repository, leave the details (raw import, fork, coordinate with DD repo…) to whomever will prepare the update.

You can add an optional NOTE: to explain your thought process, e.g.:

  • NOTE: 20201124: I believe the issue is severe but patches don’t exist yet. (yourname/front-desk)

  • NOTE: 20201124: I believe the issue is minor but there are several other ignored and postponed issues already. Let’s fix all of them now? (yourname/front-desk)

  • NOTE: 20230303: Follow fixes from bullseye 11.2 (3 CVEs) (yourname/front-desk)

  • NOTE: 20240312: CVE-2023-48733 fixed via DSA-5624-1 (yourname/front-desk)

Contacting the maintainers

When (not) to contact

  • If the package maintainers are listed in data/packages/lts-do-call-me, you coordinate with them who will work on the update.

  • The majority of maintainers are glad if security updates are handled by the LTS team, you may still contact them if necessary.

  • If the package maintainers are listed in data/packages/lts-do-not-call, do not contact them.

How to contact

Add the package to dla-needed.txt and add a note when you have contacted the maintainer. Then wait for a response and update the notes, or remove the package if they feel no security update is required.

If a vulnerability bug is unfixed in unstable and not reported in the BTS yet, you can use bin/report-vuln to open it. Discussions about severity and urgency are best done in the bug report since all involved parties (LTS team, security team and package maintainers) can get involved. Maintainers often know best how severe an issue is and if an immediate update is actually needed.

Otherwise, the bin/contact-maintainers has a few templates and recipients suggestions to help you (use --help for details):

# Ask the maintainers if they want to update the package, otherwise we will
$ bin/contact-maintainers --lts sudo CVE-2014-9680 CVE-2014-0106
$ bin/contact-maintainers --lts --minor sudo CVE-2014-9680 CVE-2014-0106

# Let the maintainers know we won't update (normally not needed)
$ bin/contact-maintainers --lts --no-dsa sudo CVE-2014-9680 CVE-2014-0106

In order to avoid undue pressure on the maintainer, you must customize the mail sent:

  • Always drop the list of uploaders and review/adjust the recipients list.

  • If the package was recently added to dSa-needed.txt, re-formulate the email to clarify this is Long Term Security and not the usual Security Team e-mail.

  • Check who was involved in making the Security Team aware of the issue. If it was the maintainer you need to re-formulate as well.

Front Desk duties

Front Desk is a shared role, in rotation. The allocations are managed in org/lts-frontdesk.20XX.txt, e.g. lts-frontdesk.2023.txt, which itself is populated by the LTS Coordinator, depending on your frontdesk flag in LTS’ and ELTS’ contributors.yml files.

Front Desk work involves CVE triage and making sure queries on the debian-lts@lists.debian.org or on IRC get an answer. In particular, make sure to follow-up on package upload sponsorship requests and questions from new contributors to make sure things flow smoothly. Following up on stale and stalled issues is also a good idea. Contributors should feel free to contact Front Desk for any questions regarding LTS.

Front Desk is expected to perform their duties on a daily basis on work days (Monday to Friday) at least, and preferably during week-ends.

References:

Switching to the next LTS release

  • Send a reminder to debian-lts-announce@lists.debian.org two months before the official support for the last LTS ends.

  • Contact the Teams/Publicity and draft an announcement that the old LTS release cycle has come to an end and a new one has started. Example, Example 2

  • Ensure that the infrastructure is ready for the new LTS release.

  • Contact the FTP team and ask them to wait four weeks with archiving the old LTS release to give users a “grace period” to update their systems.

  • Contact the Stable Release Managers for coordinating the last point release (and so that they can clean up the proposed updates queues).

  • Update all relevant pages especially LTS/Using, LTS/Installing and this LTS/Development itself.

  • Check/update/merge security-support-ended.debX in debian-security-support

    • Follow debian-security-support’s README.source

    • We shouldn’t just forward-port the EOL list, i.e. if the only reason to not support something is “we didn’t support it in previous releases”, then we should support it.

    • Also check for missing/pending EOLs announced in recent DSAs, e.g. grep 'discontinued' -r webwml/english/security/202*

    • Request team members / sponsors opinion, e.g. EOL candidates for security-support-ended.deb10

  • Update/verify the contents of data/packages/lts-do-call-me and data/packages/lts-do-not-call in the security tracker.

  • Reference pending proposed-updates in data/dla-needed.txt to prevent conflicts

Switching to the next Stable release

  • Update debian-archive-keyring for LTS (skipping one release during dist-upgrades is quite common); also needed as a work-around for #992966 (simple-cdd) at the moment.

Housekeeping Tasks

There are several tasks where we base our work on the work of the security team and where we can support them - especially when there are no open issues in dla-needed.txt. This will lead to more packages to fix:

  • Easy: Add bug references for issues unfixed in unstable. Check unreported issues in unstable, recheck them and file a bug if not already there. This makes sure we don’t regress in unstable with bugs fixed in stable, oldstable. You can use the bin/report-vuln script to generate a template report to be further edited with reportbug or a MUA. In case you don’t use reportbug to further submit the bugreport, please X-Debbugs-CC team@security.debian.org and secure-testing-team@lists.alioth.debian.org. This is done automatically if using reportbug.

  • Hard: Check TODO items from the tracker. Be sure to only mark items as NOT-FOR-US when you’re sure the software is not contained in Debian in any form.

Tips & tools