Re: [gentoo-security] No GLSA since January?!?

[Rich Freeman]

On Sat, Aug 27, 2011 at 8:34 AM, Tobias Heinlein <keytoaster@g.o> wrote:
> I have read that idea multiple times now, each of them by people not on
> the security team or something similar. It just doesn't work that way.
> It's like suggesting to ditch Bugzilla and instead enter bugs manually
> with SQL commands into a database. Well, not quite, but you get the idea.

So, if we weren't able to log or update any bugs for six months, we
would probably at least give devs a spreadsheet on google docs or
something.  I wouldn't suggest that we put the distro on hold until
somebody could re-engineer bugzilla.

If we had an automatic ebuild creator and nobody created ebuilds for
six months I'd suggest that we create them by hand.

We're talking about emails and xml files - neither of which are
terribly complex.  Exact format on the former is not critical, and the
syntax of the latter can be checked with standard tools.  If on rare
occasion we get one wrong we fix it - just like we do with ebuilds
(the libpng glsa still shows stable amd64 as vulnerable, so simply
having a tool doesn't prevent mistakes).

>
> Also, as previously stated, we know that the tool sucks, which is why
> Alex has been working for months on new tools. We really wouldn't spend
> that much time on that if it wasn't worth it.

I have no doubt that automation is better than no automation.
However, that isn't really what we're discussing here.  What we're
talking about is GLSAs vs no GLSAs.  Working automated GLSAs
apparently don't exist right now.  It is wonderful that a bunch of
people are looking to change that, however it doesn't really change
the fact that we're not sending out GLSAs, and that makes it hard for
people to take Gentoo seriously as a distro.  If the new tool were
just a few weeks away then a few posts to -dev/-security updating
status would probably alleviate concerns.  However, I think that
people have been talking about fixing the GLSA tool for ages now.

I think the fundamental problem is failing to distinguish between
operations and improvements.  You can't put the former on hold to work
on the latter.  It seems like we're trying to debate how to build the
Hagia Sophia while we're sleeping on dirt and rocks.  In my thinking
the most critical requirement is that we send out a notice when we
have a vulnerability, and describe what the vulnerability is (in a
sentence with links), and what versions are and are not vulnerable.
When resource constraints hit a volunteer project, the solution is
usually to create a more distributed solution.

Rich