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

Re: Security Response Team / EOL



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


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