On Mon, Mar 18, 2019 at 1:49 PM Richard Purdie <[email protected]> wrote: > > Since we established the stable branch maintenance guidelines for OE- > Core the world has changed a little. I'd like to propose we update the > guidelines to reflect this changing world and the current best > practises. > > Partly this change has been influenced by a discussion I was part of > where GregKH talked about the kernel stable branch policies. > > In short, its very very hard to tell the difference between a security > issue and a bugfix. You can't easily know whether a NULL pointer > dereference is exploitable or not. > > Add to this that OE is not an expert on much of the code we consume, we > need the expertise of the upstreams we take code from to know what is > important to fix. > > Then add in that there are often security fixes which don't have CVE > numbers. > > My proposal is therefore that where an upstream has a stable release > mechanism, we should work with that in OE-Core, taking direct stable > version upgrades. We've been doing this already for the kernel and > recipes like openssl. I'd propose we should be doing this more widely. > > I appreciate its hard for the stable maintainer to know which upstreams > focus on this. I therefore believe we should make a list of recipes > where this is acceptable, either in the policy/wiki or through recipe > markup or some other mechanism. I don't worry too much about the > mechanism, we can figure that out, I do believe we need to change our > "no upgrade" rule to be more adaptable. > > To be clear, the "no upgrade" rule does make sense in many cases. If > upstream is breaking APIs (without a security cause) that would be a > strong indication their definition of stable isn't compatible with > ours. > > Recently this issue came to light around some lttng* version upgrades. > I do think that particular upstream is in keeping with what we'd > need/want from a stable branch. > > Does anyone strongly object to this? > No objection but: * Is this whitelist something updated per version? An update version x -> y might contain CVE/no API change while y -> z might behave differently. * Do we still keep the policy that a patch has to go through master? If so: An API change is detected in master often by breaking dependencies - so there is some information available for us. Just a vague idea: Some (automatic) instance that keeps the information when a package update broke others => blacklist for stable update. Just a suggestion - don't ask me how to implement... * While we are at blacklist: From experience my personal top candidates are: gcc/glibc/boost/icu...
Andreas _______________________________________________ Openembedded-architecture mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
