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:

Initial package triage for LTS

This is normally done by Front Desk (see Claim the issue in the security tracker). The objective is to determine, in reasonable time, if the current state of the package justifies triggering a DLA.

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.

Incidentally, consider subscribing to openwall oss-security (echo "subscribe" | mail oss-security-subscribe@lists.openwall.com). May be useful to get reproducer and additional info.

Package/CVE evaluation

Triaging packages requires gathering information on the CVE, weighing each piece, analyzing carefully, and making an educated decision on whether an update is warranted. 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).

If in doubt, check with the other LTS contributors, the package maintainers, or the Security Team. Don’t rush though; if the troublesome CVEs were just released, don’t add the package, let the Debian and security community at large gather more information, and send a note to the next Front Desk person so they’ll re-check next week.

If initial investigation cannot be done in a reasonable time, add the package to dla-needed.txt with a NOTE: about what remains to be checked, and let another team member double-check the vulnerabilities.

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.yml 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: 20240903: Follow fixes from bookworm 12.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.

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.