Re: security upload imposing load on other parts of Debian
Hi Hoger,
On Wed, May 20, 2020 at 12:34:13PM +0000, Holger Levsen wrote:
> Hi,
>
> (the long block of text is from Salvatore and should probably
> still go to https://security-team.debian.org/security_tracker.html)
>
> On Tue, Mar 03, 2020 at 08:45:36AM +0100, Ola Lundqvist wrote:
> > > On 02/03/2020 06:53, Salvatore Bonaccorso wrote:
> > > > On Mon, Mar 02, 2020 at 01:57:05AM -0000, Chris Lamb wrote:
> > > >>> Internally they are all no-dsa states for the tracker. But think of it
> > > >>> of three "flavours" of no-dsa.
> > > >>>
> > > >>> For instance for postponed, we think that an update is woth of a DSA,
> > > >>> but it makes no sense to just release a DSA for it and the issue
> > > >>> should be tried to be included in a next update (be it DSA or even a
> > > >>> point release do not mather, but it has a stronger meaning that if a
> > > >>> future update is to be done then yes this needs to be included as well
> > > >>> if possible).
> > > >>>
> > > >>> The regular no-dsa is weker in in this regard. It just means, there is
> > > >>> no need or an update via security for it. It can be fixed for instance
> > > >>> via a point release *but* it is not expcluded that you can piggy-back
> > > >>> such a fix as well once a DSA worthy issue appear and you want to
> > > >>> issue a DSA/DLA.
> > > >>>
> > > >>> ignored is the stronges on the other part. It indicates from the
> > > >>> security-team perspective (or LTS team) we generally will not look
> > > >>> again at the issue (well expecptions can exists). It is a falvour of
> > > >>> no-dsa but meaning it even a future evaluation its likely just skiped.
> > > >> Ooh, this was very helpful; thank you. Indeed, can we get these very
> > > >> rough-and-ready definitions copy-pasted somewhere?
> > We have this fairly well described here:
> > https://security-team.debian.org/security_tracker.html
> > Should that page be updated in some way?
>
> yes, and Salvatore already suggested this:
>
> > > > Yes sure (fixing my obvious english grammar issues and typos). We have
> > > > a very "high level" view on this in [1], but it might make sense to
> > > > add some verbose explanation/outline on this on your repsective LTS
> > > > subpage where issue triage is documented. The most important bit is, I
> > > > think to explain they are basically all no-dsa, but "smell directions"
> > > > or flavours, with strongness on how the respective team will consider
> > > > they.
> > > >
> > > > [1]
> > > > https://security-team.debian.org/security_tracker.html#issues-not-warranting-a-security-advisory
>
> so, yes, if someone could update doc/security-team.d.o/security_tracker in
> security-tracker.git with above info from Salvatore, that would be awesome!
Well actually I was suggesting to add any specifics needed for the LTS
team to your LTS documentation (and maybe referring to the high level
view of the security-tracker defintiion).
Hope this helps,
Regards,
Salvatore
Reply to: