Security Response Team / EOL

Tim Jackson lists at timj.co.uk
Sun Apr 30 10:12:58 UTC 2006


Thorsten Leemhuis wrote:

[EOL stuff]

Having read the many useful and almost exclusively constructive opinions 
in this thread, I personally don't think that there are massive 
fundamental differences between what everyone thinks, though the devil 
is in the detail.

Personally, I 100% agree with the modest proposals that Thorsten has put 
forward to get the ball rolling.

A few random but important points that I have picked up from the thread 
in general:

1. no completely new packages in EOL/legacy/maintenance (except by FESCO 
overrule, as Thorsten proposed). I think that almost everyone is agreed 
on this.

2. End-user expectations need to be set clearly. My own feeling is that 
we should set end-user expectations to the lowest common denominator; 
i.e. something like "legacy releases have no expectation of any updates 
whatsoever. Notwithstanding that, a security respose team will, within 
the contraints of a volunteer group, try to provide security updates to 
packages in reasonable timescales, prioritising as they feel is 
appropriate". Better to set this expectation and exceed it than set 
something much higher and fail.

3. On the topic of backporting security fixes, I think this is a bit of 
a red herring. Some have suggested NO new package versions, only 
backported fixes. This doesn't really make a lot of sense: what if 
upstream releases a new version that contains just the security fixes? 
Or the security fixes plus tiny bugfixes too? This is pretty common and 
artificially forcing someone to diff package version N and N+1, then 
apply the patch to version N but call it version N release++ makes no 
sense. Now, obviously this leaves it down to the maintainer: if we are 
leaving it open that they can upgrade packages as they see fit for 
"security" reasons, there's nothing stopping them upgrading to some big 
new version. But then that's the case with FE in general: a lot of it is 
down to trust in the maintainers not to do things that are completely 
out-of-line with what the Project as a whole is trying to do.

Just a few thoughts anyway.


Tim




More information about the fedora-extras-list mailing list