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