The Debian/Ubuntu SSL bug

[Greg DeKoenigsberg]

On Tue, 13 May 2008, Dave Jones wrote:

> On Tue, May 13, 2008 at 02:45:29PM -0400, Greg DeKoenigsberg wrote:
> >
> > So I've been having a conversation with Mark Cox about the 
> > Debian/Ubuntu SSL bug.  This is basically a horror story of what can 
> > go wrong when packagers don't maintain close relationships with 
> > upstream.  I asked Mark, "what security policies do we have in place 
> > to keep this from happening in Fedora-land?"  And his response was, "I 
> > don't know, what security policies do we have in place to keep this 
> > from happening in Fedora-land?"
> >
> > We know that RHEL is secure and stable, and we *do* have safeguards in 
> > place to prevent this from happening in RHEL-land.  But a mistake like 
> > this in Fedora-land would be every bit as bad for the Red Hat and 
> > Fedora brands.
> >
> > Are there any steps we can take to protect ourselves from this kind of 
> > mistake -- in which a packager does something dumb to the package and 
> > no one notices it?
>
> The thing I find amazing about this bug is that it took 2 years for 
> someone to notice it.  I think in part this is due to the size of debian 
> making it pretty much impossible for someone to review every change that 
> goes in. The casual observer just has no chance to keep up with the rate 
> of change. (and there are parallels to kernel development here, git has 
> increased the merge rate to the point where one person really can't 
> sanely review everything that goes in).
>
> I think the only real answer is to make sure that for critical packages, 
> there exists >1 person actually reading the changes that go in. Though 
> the possibility of groupthink taints even this approach. Clearly a 
> number of debian developers thought that change was a great idea, 
> without realising the consequences.

Seems like a good idea -- not that we should go do it tomorrow or 
anything, but it seems sensible to me.  How do we identify which packages 
are critical?  Certainly anything that creates encrypted keys goes in this 
bucket.  :)

> Other than review though, and making sure that any patches we carry are 
> either a) short-lived [ie, on their way upstream], or b) carried forever 
> for really good reasons.
>
> Something the SuSE guys have done which I'm thinking we should adopt for 
> our patches (in the kernel at least), is a header at the top of each 
> patch detailing its upstream status, (and if not upstream, why not).

This sounds like a *really* good idea to me.  It sounds sensible, highly 
auditable, not too much of a headache, and something that packagers coudl 
keep up with.

> Additionally, something else I think we should be doing more of is
> automated testing.  We do a bunch of this for RHEL already. There was
> a whole brouhaha at rh summit a few years ago about how we were going to
> opensource our QA test harnesses. None of that happened afaict.
> Perhaps it'd be faster to reinvent something new anyway.
> (Seemed to work out for the better that way with koji).

This is a whole other kettle of worms, I'm afraid.  And yes, maybe we 
should reinvent from scratch, but I don't even know where we'd begin.

--g

-- 
Greg DeKoenigsberg
Community Development Manager
Red Hat, Inc. :: 1-919-754-4255
"To whomsoever much hath been given...
...from him much shall be asked"