[OE-core] [PATCH] wget: CVE-2017-13089 and CVE-2017-13090

Andre McCurdy armccurdy at gmail.com
Fri Nov 3 19:33:04 UTC 2017


On Fri, Nov 3, 2017 at 2:03 AM, Alexander Kanavin
<alexander.kanavin at linux.intel.com> 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.



More information about the Openembedded-core mailing list