how to get started with helping the project [...]

[Daniel Roesen]

On Thu, Mar 03, 2005 at 01:14:26PM -0800, Jesse Keating wrote:
> On Thu, 2005-03-03 at 22:06 +0100, Daniel Roesen wrote:
> > The problem is that people who take security serious can't wait weeks
> > and months for security fixes to arrive from FL. And as that's
> > (security
> > fixes) all FL provides...
> 
> This is very true.  It continues to be my main goal to get packages out
> quicker.

Excellent.

> One can say the same about distros like Red Hat and Debian, in
> that the time between a vuln being known and packages coming out may be
> too long for the really sensitive systems.

The old Red Hat was OK for me in almost all cases. Can't judge Debian.

> Although, these distros communicate about vulns using VendorSec in a
> non-public way, and are able to coordinate the announcement of and
> therefor the release of packages. Fedora Legacy is part of VendorSec
> now, however to really act on any information I get from there, I
> would need to close community access to the bug and communicate
> privately with a very very select few about the issue. I'm torn on
> this.  It would allow for potentially faster and more coordinated
> packages, but the community would have a lot less chance to do the QA
> and testing.  It is a very hard thing to do.

I fully understand this problem and am happy that we are "in sync" about
it.

> What may happen is that we'll have testing packages ready at coordinated
> announce time, for the community to QA so that we can release shortly
> thereafter.  Is anybody opposed to this strategy?  It will still mean
> private bugs in bugzilla until ready for announcement.

I think that is the only sane strategy for Fedora Legacy in order to
support security-concicious (and not only "enterprise customers" are,
but I'm so for all my private systems, all connected to the Internet)
folks.

There are two general types of disclosure: coordinated (vendor-sec etc.)
disclosure (CD) and uncoordinated disclosure (UD).

There should be a small team (the "very very select few" you mentioned)
which then prepares packages, to be released for testing at coordinated
disclosure time (CDT). When CDT has come, FL releases advisory to the
usual channels (Bugtraq, FL-announce) and releases the prepared packages
for testing. When at CDT+3days no showstoppers have appeared, the
packages are declared fully released. So people can judge for themselves
(only THEY know THEIR risk level and exposure) wether they go quickly
with the test packages, or wait for the CDT+3days "they are OK"
declaration.

Same procedure for UD, but a different team can handle those, package
test packages ASAP, and release into testing. After 3 days and no
showstoppers, packages are declared "fully released".

If any problems with packages appear, new packages are prepared and made
available.

The "3 days" is more or less an arbitrary number and may be larger.

Baseline idea: get packages out as quickly as possible, even if that may
cause problems. Installing stuff by hand has much bigger chance of hosing
something, and is more difficult to revert again. So FL would already
provide an added value also to folks who want/need to upgrade ASAP.

And from what I'm seeing, the chance that updates really break something
REALLY badly is quite low.

I'm not sure how many vulns are preannounced on vendor-sec nowadays,
but I guess splitting work a little between two teams of people on
vendor-sec and people working on non-coord disclosure issues can also
distribute some load.

> > For me, FL is only of value if I can save time by just installing FL
> > RPMs instead of rolling my own security updates. But at least remotely
> > exploitable vulnerabilities require *immediate* fix so people can't
> > wait weeks and months for FL to get into gear. So one has to backport
> > or install newer, fixed versions manually. So no time saved at all.
> 
> Right.  THere are those that don't rely on the vendor at all for
> security fixes, they do it themselves using source on the critical
> systems.  There is no way to compete with the speed this can have.

Not to the extreme, but quite close, especially in the coordinated
disclosure scenario. And with "immediate" does (in this context, for me)
mean more like "within next 24-48 hours", not "within next 30 minutes".
:-)


Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0