Re: What pain points exist in the current security-tracker structure?
On Sat, Apr 26, 2025 at 12:38:50PM +0300, Adrian Bunk wrote:
> On Wed, Apr 23, 2025 at 09:38:47PM +0200, Sylvain Beucler wrote:
> >...
> > On 06/04/2025 09:25, Roberto C. Sánchez wrote:
> > > As you go about tasks which require interacting with the security
> > > tracker, what pain points exist for you?
> >
> > One pain point that happened again today is the confusing terminology.
> >
> > In particular:
> >
> > - "no-dsa": every body gets confused by this: users, maintainers, LTS
> > contributors.
> > It's generally understood as "won't fix", while it can be fixed through
> > other means than DSA (typically PU).
>
> "should-be-fixed-in-pu" would be more exact, but also too long.
>
I wonder if "for-pu" or "wait-pu" might be possible labels that still
communicate the idea without being too long.
> > In general, let's not name something using a negative.
> >
> > Let's keep in mind that even among DDs/DMs the different security workflows
> > aren't clear (DSA, PU), they usually only upload to unstable.
> >
> > It gets even more confusing when the CVE eventually moves to LTS.
> >
> > The fact that it has "sub-states" with postponed & ignored is unique in the
> > tracker and brings further confusion.
> >
> > "deferred" (as is: deferred from Debian Security Team to the rest of Debian:
> > maintainers, release team, LTS team, etc.) may be better, though still
> > unclear to a common Debian user.
> >
> > Dropping "no-dsa" and only using "postponed" and "ignored" would be another
> > proposal.
> >...
>
>
> Using "postponed" in stable is more confusing terminology than "no-dsa",
> since "postponed" sounds even more as if it should not be fixed in pu.
>
>
> Calling "ignored" a sub-state of "no-dsa" is confusing terminology.
>
> "no-dsa" and "postponed" both mean that the CVE alone will never
> justify a DSA, but it should be fixed in pu (or as part of a DSA for
> other CVEs).
>
> "ignored" means there is a good reason why the CVE should never
> be fixed.[1]
>
> I think what was intended was that "no-dsa" is the result of triaging
> only for severity, while "postponed"/"ignored" also includes a statement
> about the feasibility of fixing a "no-dsa" CVE.
>
> After tagging "no-dsa" the security team does usually not look further
> at a CVE.
>
> Calling "ignored" a sub-state is wrong in cases where a high-severity
> CVE that would warrant a DSA/DLA is tagged "ignored" because backporting
> a fix is not feasible.
>
>
> The difference between stable and LTS is not only at the CVE level,
> but also at the package level.
>
> When after triaging all CVEs in a package a non-zero number has no tags
> like "no-dsa", then a DSA should be issued.
>
> A main difference is what happens otherwise, DLA has a higher threshold
> for issuing an update than pu.
>
> When a package has 1 low-severity CVE a pu upload would still be
> appropriate, but a DLA might not be.
>
> For 40 low-severity CVEs a DLA will usually be issued (but not a DSA).
>
>
It seems more likely that we could find a way to introduce a new tag (in
terms of security team agreement with the idea) than that we change the
semantic meaning of an existing tag.
I agree that we can find examples of tags being applied in ways that are
confusing, but that's the sort of thing that can be corrected when found
and avoided in the first place (with good documentation and good
practice on the part of those applying the labels).
A systematic review of our (i.e., LTS Team) documentation in this area
would be good.
Regards,
-Roberto
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
Reply to: