Security updates are too slow or none existant

[Jef Spaleta]

William Hooper wrote:
Red Hat is part of a number of non-public groups that discus and fix  
security issues.  Releasing an update into testing before the issue was
made public would be irresponsible.
---

Any discussion of the handling security issues is always going to be
hampered by embargos on sensitive security information.  Right now, the
frustration the community is feeling with gaim could very well be the
result of an ongoing sensitive security issue, associated with the
patch.  This of course is just speculation on my part. No one who
actually knows would be able to comment. And as a a general rule...
a 'no comment' comment is still a comment.  Vendor-sec and other
security related groups membership is going to be a thorn in the side
of Fedora long term, if community developers start maintaining pieces of
core. It's not clear those developers will ever be allowed to see the
vendor-sec notices....
http://www.fedora.us/wiki/VendorSec

But that being said.... there is certainly room for improvement with
regard to how the security update process is being handled with Fedora.
Instead of focusing on gaim in this discussion (which could have
complicated vendor-sec issues associated with the patch). I'd prefer
to try to look at older security issues, that should be less complicated
to discuss. the httpd update, that took 3 weeks, i think might be a
better example to look at objectively to understand where any process
problems might exist...and ways the community can supplement Red Hat's
efforts to solve the problems.

The key question of course with regard to the httpd update is what was
the real reason the httpd update for fc1 was 3 weeks late?

was it a manpower constraint inside Red Hat? 
was it a technical issue?
was it a prioritization issue, in that rolling the update for fedora was
considered a low priority compared to non-security related tasks by
management or the packager? 

Looking at the changelog for the httpd update for fc1, and looking
at the build date for the package in rpm -qi httpd. The information
available seems to suggest this package was actually built in Novemeber.
Why it didn't get published till January seems to indicate a process
problem and not necessarily a low prioritization to build security
updates for fedora core. The httpd package was built..it just didn't
make it out as a released update in a timely manner. In fact...it was
announced as a test update in Novemeber.
http://www.redhat.com/archives/fedora-test-list/2003-November/msg00814.
html
So technically...a package was available for fedora before it was
available at all for rhl9. If anything...there was a break down in
moving packages from testing to released.  No one is going to argue
there aren't problems with how 'testing' is being used. Policy around
how things move into and out of testing is not codified, and at this
point i think every fedora core developer is making a best effort
attempt to use it appropriately...but there's isn't a clear mandate or
guideline on how 'testing' is suppose to be used. The concept of the
testing branch is new, and its ill-defined. Having httpd sit in testing
for that long indicates there needs to be more guidance and policy with
regard to how testing is supposed to be used.

Moving away from the specific example of httpd, i want to say that in
general I see the problems with how 'testing' updates are being released
as a symptom of larger scale lack of policy and guidelines for the
Fedora development/maintenance process. I personally think its only
going to get worse before it gets better. Right now gafton is making
getting the CVS repository and the associated contributors paperwork in
place so community can start contributing code in some way.  Once this
tool is in place. the issues of guidelines and communication on how to
do things is going to become more more pressing and much harder to make
headway on.  

Right now, Fedora Core developers are Red Hat employees, working in a
culture of close-knit internal communication where processes and
instructions aren't written down and are instead a sort of word-of-
mouth, seat-of-your-pants oral history.  This sort of communication
culture, might work just fine in small/medium sized companies...where
people stick around for the paycheck and learn the day-to-day process
over a period of time by watching and emulation others, and being
overseen by 'managers.'  So instead of a clean written process, with
clear written guidelines, there is a long indoctrination period where
new employees learn by watching what other people are currently doing.
This communication culture breaks down when brand new processes
developed and quickly implemented, like the 'testing' repo idea. Since
there is no oral history or tradition to follow, everyone is sort of
floundering around not really knowing how to use the new process
appropriately. This oral history communication process also breaks down,
when you have a large influx of new people, and you can't make enough
time to mentor them by having them try to follow along watching how the
current employees do things. And that breakdown is only going to get
worse...when the new people..aren't employees...but are instead
volunteers...because volunteers will not be as tied into the internal
communication channels as employees are.  Volunteers are by and large
going to need more mentoring than new employees....and are by and large
not going to be willing to wait as long dealing with political overhead
to make an impact.  It's one thing to twiddle your thumbs while earning
a pay check...its quite another to twiddle your thumbs waiting to be
told as a volunteer how to contribute to the process.  

-jef


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20040208/256d485d/attachment-0001.sig>