On Fri, Nov 3, 2017 at 2:03 AM, Alexander Kanavin <[email protected]> wrote: > On 11/02/2017 10:29 PM, Andre McCurdy wrote: >>>> >>>> Update the master to 1.19.2 instead please. >> >> Patching 1.19.1 does have the advantage of creating a commit which can >> easily be cherry-picked into rocko (and pyro, which also uses wget >> 1.19.1). > > Yes, but this is coincidental. If the versions wouldn't exactly match, > cherry-picking would not be possible.
Of course. But in cases where the same fix can be shared between master and stable branches I think it makes sense to try to do so (or at least not actively block doing so). >> Master should certainly update to 1.19.2 but doing so in two steps >> might be appreciated by the stable branch maintainers. > > When fixing CVEs, the yocto branches should be considered separately, and > patched all at the same time by the same person. Difficult in practice since we don't have a security team etc who can bypass the normal flow of patches into the stable branches. It also places an extra burden on anyone proposing updates for master that happen to fix CVEs if they need to simultaneously create fixes for stable branches too. > For master, updating to > latest upstream release without the vulnerability is the best, as it lessens > the load on people who have to keep master up to date. Agreed. Question is just whether (in special cases such as this one) to make the update in master as a single commit or in two. > For stable branches, > it depends. If the upstream maintains a stable branch themselves where cves > and other bugs are fixed, I think we should trust that rather than backport > patches. This is a more general topic. Although version updates in stable branches is not something we do now, personally I think it's something we should at least consider. Sometimes it makes more sense to trust upstream than to cook up our own solutions. For anyone using OE to actually ship a product, it's far easier to do security audits etc by checking package versions than reviewing a long list of patches. The counter argument though is that we just don't have resources to make case by case decisions and a blanket policy of never updating versions in stable branches keeps thing simple for the stable branch maintainers. -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
