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

[Martin Jansa]

On Fri, Jan 27, 2017 at 09:43:42AM -0800, Khem Raj wrote:
> 
> 
> 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/

And when the upstream didn't break the ABI, we did with seemingly safe
change of version-script.patch:

http://git.openembedded.org/openembedded-core/commit/?h=jethro&id=528541845df34843c14be5de62e9f53004d292ac
http://git.openembedded.org/openembedded-core/commit/?h=krogoth&id=08f85da10b3a7fc6165f163fd0f23784a2c9c8e4

So I agree that we should be very careful and make as few exceptions as
possible at least until there is strong testing for API/ABI
compatibility for release branches.

> 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
> > 
> _______________________________________________
> Openembedded-architecture mailing list
> Openembedded-architecture at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-architecture/attachments/20170127/c94b9a6f/attachment-0002.sig>