=================
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
<https://salsa.debian.org/security-tracker-team/security-tracker/raw/master/org/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 <#triage-security-issues>`_
and making sure queries on the `debian-lts@lists.debian.org <mailing
list>`_ 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:

* `Front desk 2015 announcement <https://lists.debian.org/debian-lts/2015/06/msg00032.html>`_

""""""""""""""""""""""""""""""
Initial package triage for LTS
""""""""""""""""""""""""""""""

This is normally done by `Front Desk <#front-desk-duties>`_ (see
`Claim the issue in the security tracker
<#claim-the-issue-in-the-security-tracker-in-dla-needed-txt>`_).  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:
 * Open issues from the tracker: `oldstable
   <https://security-tracker.debian.org/tracker/status/release/oldstable>`_/`oldoldstable
   <https://security-tracker.debian.org/tracker/status/release/oldoldstable>`_
   (tick the top-level checkboxes accordingly; "issues to be checked"
   means "undetermined").
 * Heuristic to detect explicit CVE fixes from new DSAs and stable
   point releases (may typically include batches of unmonitored
   ``<postponed>`` vulnerabilities), check
   `debian-security-announce@l.d.o
   <https://lists.debian.org/debian-security-announce/>`_ and
   `Proposed Updates
   <https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=release.debian.org@packages.debian.org;tag=pu>`_
   / `debian-announce@l.d.o
   <https://lists.debian.org/debian-announce/>`_.
 * Package support status, see `debian-security-support
   <https://salsa.debian.org/debian/debian-security-support/>`__.

but doesn't handle:
 * non-CVE updates such as SUAs (tzdata, clamav...), do check
   `debian-stable-announce@l.d.o
   <https://lists.debian.org/debian-stable-announce/>`_.

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
<https://www.openwall.com/lists/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
   <https://salsa.debian.org/debian/debian-security-support/>`__ +
   `non-free
   <https://www.debian.org/doc/debian-policy/ch-archive.html#the-non-free-archive-area>`_
   + 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 <#contacting-the-maintainers>`__.
 * Fixability: patch availability (for dead or uncooperative
   upstreams, consider updating `debian-security-support
   <https://salsa.debian.org/debian/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 <#cve-status-list-for-lts>`_.
 * 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 <#contacting-the-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
<https://freexian.gitlab.io/services/deblts-team/documentation/lts/information-for-lts-contributors.html>`_:
::

  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
  <https://salsa.debian.org/security-tracker-team/security-tracker/-/blob/master/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
  <https://salsa.debian.org/security-tracker-team/security-tracker/-/blob/master/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
<https://salsa.debian.org/security-tracker-team/security-tracker/raw/master/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.