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
