On 3/18/19 10:34 AM, Andreas Müller wrote: > 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?
I think if a stable version of upgrade, master must have the same (or equivalent, even newer version) made to it as well, or a clear statement why that was not necessary. master first, then older branches or it becomes maintenance nightmare! > 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 Agreed, if master shows breakage (due to API changes), then we need to be more careful on the upgrades in the older versions... but I think this will be fairly clear to us as we go forward. > 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... I think we need to be clear on what a stable (or minor) version is. This will certainly change for each project and version numbering scheme. Maybe it becomes part of the whitelist/blacklist? (I'm worried that we're potentially adding a LOT of overhead as well...) Using your example above: GCC (in recent history) seem to be just that, reasonable bug (and security) updates. (Now OLDER versions pre GCC6, I wouldn't have had much confidence in..) glibc I'm not sure. I'm not sure if say 2.29 to 2.30 makes sense.... Boost is one of those I don't have a lot of confidence in ICU -- not sure.. etc.. But in the end who makes the recommendation to whitelist/blacklist? Probably the maintainers, BUT how many maintainers know the associated projects enough to actually comment about stable policy? A lot of the maintainers, are good at upreving the versions -- but that is their knowledge -- they need the component, and can upgrade it consistently, but don't necessary know that community or their requirements. I do agree with what RP said in another thread though, I think this will sort itself out pretty quickly once we have a policy... I'm just hoping it's not very painful in the meantime. --Mark > Andreas > _______________________________________________ > Openembedded-architecture mailing list > [email protected] > http://lists.openembedded.org/mailman/listinfo/openembedded-architecture > _______________________________________________ Openembedded-architecture mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
