On 6/22/2011 12:09 PM, Ljubomir Ljubojevic wrote:
>
>> It's speculation at this point, but I think security fixes in the kernel
>> and major libs are to be expected instead of being some extreme case,
>> and those are precisely the most likely things that would cause
>> something to break if done incorrectly. The point of planning the early
>> release concept in the first place should be to get these fixes out to
>> the people who otherwise become targets of well-known exploits and
>> rootkits. Assume, for example, that another flaw is found in php or a
>> web app that allows remote command execution, and another glibc flaw
>> like the one recently fixed that allowed root escalation if you could
>> make a symlink to a suid file. Now assume that the fixes for these
>> vulnerabilities comes in or immediately after the point release. That
>> scenario seems normal, expected, and what the early release planning
>> should be all about instead of holding these back until a working
>> ananconda and iso layout is ready and tested.
>
> So in another words, you approve creation of CR repository in it's
> current designed form.
It is sort of irrelevant to my concerns if things that have CVE's
associated don't go there. But I'm not sure it can be that simple.
> And you also support devs when they release important security related
> packages through "updates" repo as fast as humanly possible, just I
> failed to understand what you are saying.
Yes, this is the important part, but I don't think the updates of a
point release are neatly divided into security/bug/feature sets and
worse, there are usually a flurry of new updates immediately after the
point release. It would be reasonable to expect and plan for something
like a php, mod_perl or mod_python security update to come soon after a
point release that would have dependencies on a whole bunch of other
stuff in their point-release versions even if those hadn't been pushed
as updates on their own yet. If the CR plan covers this, then I'm
happy. I just see the security issue as a fairly sure thing and the
risk being one of running version combinations that aren't well tested
together. If you push anything due to security needs, I'm not sure that
risk is reduced by holding parts back that upstream would have tested
together.
--
Les Mikesell
lesmikesell at gmail.com