Security tracker suggestions
Hi,
below are some items I have for security tracker development.
No commitment from me to work on any of these, but if this
is considered useful I can turn them into salsa issues.
1. gen-DSA interprets the package name as regex
The 'k+' in 'gtk+3.0' is interpreted as "one or more 'k'".
2. The tracker should know the security support status of a package
It would be useful for both developers and users if the tracker knew
about the support status of a package in a distribution, and would also
display this information (e.g. background colour of a package).
(old)stable, LTS and ELTS have different support rules, but it shouldn't
be too hard for each case to write a script that outputs files like
<distribution>-supported.txt
<distribution>-partial-support.txt
<distribution>-unsupported.txt
that could then be committed to the tracker.
There are:
- over 35k <end-of-life> tags in the ELTS tracker,
- over 700 "Non-free not supported" comments from <ignored> tags
- plenty of other manual tags for packages like wpewebkit in stable
Such manual tagging would then also no longer be needed.
3. How to avoid triaging mistakes based on host/target confusion?
https://security-tracker.debian.org/tracker/CVE-2020-1751
[buster] - glibc <ignored> (powerpc is not supported by LTS)
libc6-powerpc and libc6-ppc64 are supported.
https://security-tracker.debian.org/tracker/CVE-2019-15847
[buster] - gcc-8 <ignored> (minor issue, affects only POWER9 binaries)
src:gcc-8-cross-ports is a supported package in ELTS.
4. Security notes, with user notification of new notes
[jessie] - openssh <ignored> (Too intrusive to backport; workaround available)
How are our users supposed to know that they have to implement a
workaround for this vulnerability?
This needs user documentation, including some way of notification
(e.g. RSS, email) when new items are added.
After point 2 above and the proposal [1] (mark <not-affected> when no
binary packages are affected), I'd also suggest to make it mandatory
to always link to where we describing this to our users when adding
an <ignored> tag.
5. binNMUs for static linking
It would be useful to have tooling that generates wb commands one
can pipe to wuiet when a DSA/DLA needs rebuilds for static linking,
based on a tool like drt-tools or binNMUs.
This could then also run as check when reserving a DSA/DLA,
refusing/warning when a binNMU is missing.
This requires on the ftp side having the sources available in the
partial security suites.
Regenerating of LTS buildd chroots with security included would be
desirable, otherwise later builds would again use the pre-LTS versions
of packages in the chroot (including glibc) in all future builds.
A longer-term project would be finding and fixing packages like
git-annex or pandoc that link 100 MB of shared libraries with no
metadata what is linked (in this case Haskell tooling would have to
learn adding something like Static-Built-Using or X-Haskell-Built-Using).
Unless this has changed, src:gcc-*-cross* have issues with binNMUs and
might need source uploads.
6. Version tracking, and using BTS version information
- upload to experimental -> manually tracked in the tracker
- upload to unstable -> manually tracked in the tracker
- upload to stable-pu -> manually tracked in next-point-update.txt
- upload to oldstable-pu -> manually tracked in next-oldstable-point-update.txt
The BTS knows that all fixes in 1:128.11.0esr-1 are also in
1:128.11.0esr-1~deb12u1, but the tracker does not.
When a bug is linked from the tracker, the BTS already has a list of
fixed versions. Tracking the same information in multiple places is
something I would consider a bug.
cu
Adrian
[1] https://salsa.debian.org/security-tracker-team/security-tracker/-/issues/32
Reply to: