[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: security upload imposing load on other parts of Debian



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.

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 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.

Regards,

-Roberto

-- 
Roberto C. Sánchez


Reply to: