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

Randy MacLeod randy.macleod at windriver.com
Mon Jan 30 22:08:24 UTC 2017


On 2017-01-27 07:31 AM, Alexander Kanavin wrote:
> On 01/26/2017 10:10 PM, Randy MacLeod wrote:
>> 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.
>>
>> The change to always call setup_engine() may be a problem
>> but I'm not familiar with the openssl code base so I'm
>> not sure how big a deal it is. Alex, are you familiar with
>> this part of openssl?
>
> Randy, you are starting with a wrong assumption: that people listed in
> maintainers.inc are real maintainers - real in the sense that they
> follow upstream development, take care of regular runtime testing
> (including writing the testsuite if upstream doesn't provide a good
> one), and understand the source code well to make informed decisions.
> That is simply not true. I have no idea about what goes on inside
> openssl, and I think no one else in Yocto does. My duty is updating
> openssl to the latest version in master and reacting to bug reports;
> there's simply no time for more.

Well, I expected such a reply but hoped to be surprised. It's a
tough call as a distro maintainer. I wonder if maintainers for other
major distros would generally have the same concerns about lack of time
to develop the required expertise or is Yocto different due to lack of
community participation.

> We need to spread out recipe maintainership a lot more than is the case
> currently, then we can have a sane policy in place for stable releases.
>
> Alex

That makes sense to me as well.


-- 
# Randy MacLeod. SMTS, Linux, Wind River
Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, 
Canada, K2K 2W5



More information about the Openembedded-architecture mailing list