Openssl fixes bug (but occasionally changes the API) in letter releases so YP should follow that as well rather than cherry-picking back CVE patches.
The YP practice has been to maintain the letter release and to cherry-pick back specific CVE and other bug fixes. The proposed change it to track the letter releases: so for morty: openssl_1.0.2j would be followed by: openssl_1.0.2k Other linux distros do this. The benefit is easier integration of bug fixes. The risk is that upstream could (and has in the past) introduced 'minor' API changes. Should we decide that the benefits outweigh the risks, we would need to rigorously check for API changes and if any are found, we could patch those out.
(In reply to comment #1) > The YP practice has been to maintain the letter release and to cherry-pick > back specific CVE and other bug fixes. This should be driven more by the upstream package maintainer version/revision plan if they have one. If the minor version bump is a bug fix only, then updating a package a seems reasonable coarse of action. But if a critical fix has been posted and no new version released, then what? (backport the fix, my recommendation ). We are terrible inconsistent. We update the minor versions of the kernel but not the toolchain. They both are bug fixes only. Sorry, got of topic ; ) The proposed change it to track > the letter releases: so for morty: > openssl_1.0.2j > would be followed by: > openssl_1.0.2k I think we need to refine the overall package update/fix guidelines and leave any deviations to the package maintainers listed in the layers. I don't want to single out "openssl". I suspect there are other cases like this that exist. > > Other linux distros do this. The benefit is easier integration of bug fixes. agree. > The risk is that upstream could (and has in the past) introduced 'minor' API > changes. Should we decide that the benefits outweigh the risks, we would > need to > rigorously check for API changes and if any are found, we could patch those > out. We some CVE fixes where to degrade or eliminate an API because it is inherently flawed. Kinda had to make the changes.
The consensus on the openembedded-architecture@lists.openembedded.org list is that there are risks in tracking minor releases that the project does not have the tools or people to deal with. I'll close the enhancement unless someone has a different proposal before Feb 6, 2017.
As explained previously, the YP has to minimize risk and test effort so this enhancement and change in policy will not be implemented unless there is an increase in participation in the community.