Re: Yocto post-release CVE and package uprev policy - openssl, ffmpeg, etc.

Paul Eggleton <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
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.

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.



Paul Eggleton
Intel Open Source Technology Centre

Join { to automatically receive all group messages.