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

[Khem Raj]

On 1/26/17 8:04 PM, Paul Eggleton wrote:
> 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 think we can contexualize it based upon amount of work, openssl has
violated ABI within same major release in past see 1.0.2f -> 1.0.2g

For complete list

https://abi-laboratory.pro/tracker/timeline/openssl/

We may use that as guiding light to make a decision for backporting CVEs
or do a minor upgrade.

> 
> 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
>