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
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.
Community Development Manager
Red Hat, Inc. :: 1-919-754-4255
"To whomsoever much hath been given...
...from him much shall be asked"
fedora-advisory-board mailing list