[Openembedded-architecture] Yocto post-release CVE and package uprev policy - openssl, ffmpeg, etc.

[Paul Eggleton]

On Thursday, 26 January 2017 3:10:57 PM NZDT Randy MacLeod wrote:
> Yocto seems to have a policy not to update packages once a
> release is generally available. I think that rule should be
> broken for certain packages that have been reviewed and tested
> properly.

We have made exceptions in the past for exactly the reasons you outline. 
Unfortunately I know at least for OpenSSL when we have done so on at least one 
occasion we have been bitten by compatibility issues :(

If we can introduce more rigorous runtime testing (and by that I don't just 
mean tests for the package itself - runtime tests for functionality in other 
applications that rely on that package would be preferred) then we would be in 
a much better place. Being able to measure ABI compatibility is a good start 
but doesn't cover any internal changes in behaviour that might be problematic.

> See:
>     https://bugzilla.yoctoproject.org/show_bug.cgi?id=10707
> for additional background.
> 
> For some packages,  the upstream development team fixes CVE and
> other bugs on their released version and by YP only cherry-picking back
> specific fixes, we expose users to additional risk and incur higher
> costs of maintenance.
>
> At least two packages that I know of have released
> "bug fix only" updates to fix CVEs and other defects for packages
> that are in morty:
> 
>   - openssl 1.0.2j -> 1.0.2k
>   - ffmpeg 3.1.3 -> 3.1.5
> 
> Should we continue to cherry-pick back only the CVEs fixes
> or should we review, test, and release the full minor release?
>
>
> I've done a review of openssl below but
> before I proceed with more evaluation or sending the
> uprev to the list for morty, I'd like to know if the upgrade
> policy will block such a change. From my analysis, there's only
> one change that seems like an upgrade blocker and I need help
> to evaluate that since I'm not an openssl maintainer.

I would say we're not hard-blocked by the policy - we can make exceptions, but 
we really do need to be careful, and I don't think we're prepared to make a 
continuing exception for specific packages yet. The better idea we can get 
that there won't be regressions, hopefully in an automated or semi-automated 
manner, the safer position we'll be in.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre