Re: [gentoo-dev] Regarding long delays on GLSA generation

[Chris Reffett]

On Jan 18, 2014 1:35 PM, Pacho Ramos <pacho@g.o> wrote:
>
> El sáb, 18-01-2014 a las 19:19 +0100, Alex Legler escribió:
> [...]
> > So you observed correctly there's still plenty of delays. There are
> > three parts to an advisory that take time:
> > - Drafting: Collecting information, linking references, getting package
> > versions done right (slots are a huge pain still).
> >
> > - Reviewing: Our current process asks for two independent positive
> > reviews from other team members before an advisory can be sent.
> >
> > - Sending: The original author gets a .txt to email and have to check in
> > the .xml to CVS.
> >
> > Going through these three steps requires at least three people, and the
> > (group of) people whose action is required shifts twice. That overall
> > process is spot #1 we are planning to improve. The current plan contains
> > requiring only one review and the reviewer sends the advisory directly.
> > So we go from author -> reviewer 1 -> reviewer 2 -> author to just
> > author -> reviewer.
>
> This looks a nice improvement indeed :)
>
> >
> > Concerning the single steps here are other measures:
> > - Drafting: Implement a new GLSA format to
> >   * reduce the amount of editorial text written by us
> >   * support slots (makes specifying vulnerable ranges in slotted package
> >     much easier)
> >   * (cleanup old stuff no longer needed)
>
> That looks interesting as doing all the draft manually is really a huge
> work (with leads to not so enhancement). I am unsure how will the
> cleanup be done, as soon as the portage tree doesn't break (due some
> other package requiring the old buggy version), why are not all devs
> allowed to drop (or, at least, hardmask if needed for some base-system
> package :/) the vulnerable versions? Looks like currently security team
> waits for maintainers to do that, I try to do it fast but maybe will
> take much more time in other situations. I think this could be improved
> if other people like security team members or the last one stabilizing
> the fixed version could do the cleanup too.
We prefer that the maintainers do the drop in case there's some dependency situation we're not aware of, but we will drop if maintainers are unresponsive.

> Also, currently looks like, when we (maintainers) get asked to bump the
> package fixing it, we tend to wait for security team members to CC
> arches, maybe the maintainers could do that directly to gain a bit of
> time.
By all means, maintainer should be the one to call for the stable. It's your package, I cannot think of any situation where security would not want the maintainer to do that.

> >
> > - Reviewing: Reduced editorial text means less to review.
> >
> > - Sending: We want to improve our tooling to automatically send
> > advisories and push them to a git repository.
> >
> > The new GLSA format was up for review on -security last week. Next up
> > will be getting it specified formally, implemented in our tooling,
> > glsa-check and a new security.g.o frontend. [1]
> > Then, we can adopt the new workflow.
> >
> > >
> > > Then, instead of blaming on how should I have asked for clarification on
> > > this (well, looks like the main topic here is that I have asked about
> > > this in ML instead of the real problem :O), I think you should focus on
> > > explaining how are you fixing this problem.
> >
> > Your original email didn't reflect actual interest in the details. Now
> > that we've established you do care, I hope my explanations helped you
> > out there.
> >
>
> They helped for sure :) and I appreciate them, I simply thought nothing
> was being worked out as I explained in previous mail (I was still saying
> long delays)
>
> > > I have been long time wondering about this because:
> > > 1. I usually get lots of bugs from alias I am a member whose we go fast
> > > bumping, calling for stabilization and dropping vulnerable versions and,
> > > the, the bugs get stalled.
> > > 2. Once of the machines I maintain would benefit from being able to use
> > > glsacheck to only update vulnerable packages as not always have enough
> > > time for updating the full world
> > >
> > >
> > >
> >
> > [1] Lots of code to be written here. .py+.rb, help wanted!
> >
>
>
>