Re: security upload imposing load on other parts of Debian
Hi
[I'm subscribed and following, but if anything needs a immediate reply
please do CC me, if something needs a reply from a security team
member please cc the security team always]
On Sun, Mar 01, 2020 at 08:14:41AM -0500, Roberto C. Sánchez wrote:
> On Sun, Mar 01, 2020 at 01:57:21PM +0100, Thorsten Alteholz wrote:
> >
> >
> > On Sun, 1 Mar 2020, Roberto C. Sánchez wrote:
> > > The rationale behind the no-dsa decision for stretch/buster
> > > is unkown to me.
> >
> > Even upstream said in the announcement [1] (linked from the security
> > tracker) that it is only a minor vulnerability.
> >
> Understood. In the context of privilege escalation vulnerabilities it
> is minor. As opposed to some arbitrary privelege escalation allowing an
> unpriveleged user to gain root privilege, the vulberability allows a
> user to regain a formerly elevated privilege. In any event, the only
> reason that this discussion is taking place is because of the REJECT
> that occured following the upload.
For context, we usually do triage issues in various steps. A decision
of a no-dsa/dsa might come later. In the particular stance we got
approached by the maintainer getting feedback on the severity,
pointing the above and deciding the issue does not warrant a DSA on
its own. The decision from LTS to issue a DLA was done here before the
security team decided on the no DSA status.
>
> With that in mind, the principal concern now is what to do.
>
> I have made things worse by reserving the DLA, including
> committing/pushing the reservation as soon as I made the upload but
> before I received the REJECT. As it happens I also submitted the MR for
> the DLA on the website, which Holger merged only minutes later.
>
> I have not sent the announcement and the DLA on the website is easy
> enough to remove, but it is not totally clear what the best path forward
> is here. Perhaps update the DLA on the website to say something
> "delibertely left blank", then unmark the CVE as fixed and leave the
> whole mess be? Or is it better to wait for FTP master to perform the
> copy of libcap2 and reprocess the zsh upload?
As a general suggestion, I would always wait until you get an ACCEPTED
before going ahead with releasing an advisory. And to reserve an
advisory number when you are sure that the advisory is actually to go
out "soonish" (this is a flexible interpretation). Apart from the
mentioned problem with Built-Using, there can be always some technical
problems which block an release.
With the concrete case in mind, I pinged ftp-master yesterday, because
there is another upload waiting in NEW which needs processing (Ben
Hutchings src:linux-4.9 upload). So in this case you might continue to
wait until it's processed it.
But it would as well not be a problem to just rollback your commit,
remove the already pubished advisory from the website (if the mail was
not sent out yet), and then reuse the DLA number by explicitly
choosing it in a next DLA pending, or skip it). If you want to reuse
the number then you will need to explicitly say so, otherwise gen-DLA
will actually otherwise pick up the next number.
> > > As far as the other CVEs, it is my practice to review postponed
> > > vulnerabilities, but not ignored or no-dsa vulnerabilities. If we are
> > > meant to revisit all unfixed vulnerabilities when working on a package,
> > > then that is news to me.
> >
> > According to [2] no-dsa means that there should be no immediate DSA/DLA.
> > Only <ignored> ones never get an update.
> >
> That is news to me. I always thought of no-dsa, postponed, and ignored
> as three distinct states rather than as a general state (no-dsa) with
> two more specific sub-states (postponed and ignored). So, given that,
> yes, a more thorough review of the unfixed vulnerabilities would have
> been warranted. I do not know how came to the incorrect understanding I
> had up until this point.
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.
Hope this helps,
Regards,
Salvatore
Reply to: