Re: What pain points exist in the current security-tracker structure?
Le dimanche 6 avril 2025, 09:25:58 heure d’été d’Europe centrale Roberto C.
Sánchez a écrit :
> Hello everyone,
>
> I am in the early stages of putting together a sprint to take place at
> DebCamp25, with the objective of making improvements to the security
> tracker. With that in mind, I would like to ask a very specific
> question:
>
> As you go about tasks which require interacting with the security
> tracker, what pain points exist for you?
>
> Some background:
>
> Santiago and I have recently been discussing some improvements to the
> security tracker with a specific focus on improvements to support our
> workflow needs (both inward facing and outward facing needs, including
> things that support the workflow of the LTS team and by extension the
> Security team). As a result, we have a reasonably good idea of some
> changes that we'd like to see implemented in order to support those
> specific neds.
>
> As part of this effort I would also like to consider whether other
> improvements are needed and/or desirable. The idea with considering
> existing pain points and other improvements is two-fold. First is that
> if we are going to undertake significant work on the tracker (vis-à-vis
> a sprint) then this is also an opportunity to fix some other issues
> along the way, thus improving the overall day-to-day experience for the
> LTS team and the Security team. Second is that such improvements seem
> likely to yield workflow improvements that I had not previously
> considered.
>
> At the moment I am most interested in identifying the problem areas and
> pain points rather than considering the potential solutions. That said,
> while solutions aren't the focus of the question I am asking in this
> mail, discussions of potential solutions to specific problems are fine.
> I'd rather we not turn this into a discussion about hypothetical issues
> nor a bikeshedding session on potential optimizations.
>
> As one example, some time ago I encountered the issue of the size of
> data/CVE/list, specifically in the context of a git blame operation
> taking a few hours to complete. I became convinced that data/CVE/list
> needs to be split. As I've done some research on the topic, the answer
> to that is far from clear. I'm less convinced now that "split
> data/CVE/list" is the de facto right solution, and I'm definitely
> convinced that a big change here will not be accepted without many good
> reasons and proof that doesn't also include some massive drawbacks.
split per year will help here.
And bonus point will help us LTS/ELTS wise to avoid conflict with more recent
entry.
> So,
> in the context of this discussion I would consider "git blame takes an
> unreasonably long time to be particularly useful" as a valid statement
> of a pain point, and I would hesitate to favor a specific possible
> solution.
pain point:
- PU should be taken in account for fixed version #645201
- Don't display unimportant issues as "vulnerable" #1039606
Otehr pain point: NOTE syntax should be improved or better documented for fixed
version
>
> Regards,
>
> -Roberto
Reply to: