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

Re: The Debian/Ubuntu SSL bug

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.

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

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

Good questions though. This bug could easily have been us on the recieving end.



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