On 3/18/19 7:49 AM, Richard Purdie 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?
Let me start out with, I'm not against this proposal. But, I want to mention the cases in my experience where people get upset with version numbers changing. 1) "Regulated devices". For some reason there are a class of devices where some sort of government regulation says you have to re-certify the device if internal components change version numbers. So for these users they would rather the version number never change, and all contents be backported. (Even if the backport effectively changes the software base other then the version number.) Fortunately a lot of these industries are changing, and focusing our policy on allowing someone to workaround a specific regulation seems like a bad idea. 2) Business reasons. Customers who are so risk adverse that they believe every commit needs to be validated before they can possible accept the upgrade. Focusing on backports gives them the confidence that they are able to review all of the changes that a minor (stable version) upgrade does may not. Perhaps becomes part of the criteria we use for stable version upgrades? Stable versions have bug fixes that are in a small enough quantity that they can be reviewed? Along those lines, perhaps our policy should be to include with a stable upgrade a changelog or other list of the upstream changes in our own commit logs to help reassure these users? 3) Technical reasons. These are EXTREMELY rare, and I suspect any policy we produce would already address it. But it's the case where someone has an extension to something that breaks with even a minor upgrade. (Not necessary a published API, but perhaps an internal API.) I'd contend that the software that breaks is in-fact broken, but it's something to watch out for. Often Linux kernel drivers (out of tree, especially those provided only as patches) fall under this case. I would only suggest here that our policy be clear that we focus on public APIs, not patches that fail to apply after an upgrade. It's the responsibility of the user to re-create/update their patches [if applicable] after an upgrade. (So again, all for this change, just wanted to highlight a few things we should address in any project policy.) --Mark > Cheers, > > Richard > > > > _______________________________________________ > 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
