[yocto] Security updates question
Jon Szymaniak
jon.szymaniak.foss at gmail.com
Sat Sep 8 16:57:41 PDT 2018
Hi Brian,
On Sat, Sep 8, 2018 at 6:20 PM Brian Smucker <bds at bsmucker.eu.org> wrote:
> Jon,
>
> I do appreciate your insights and I am aware of some of the update
> mechanisms that are out there. At the moment we don't have a need for
> that. The need at this time is a totally new image, identical to the
> working image we have been using, except with an updated web server
> package. For the present we will use our manual update mechanism to
> update select devices on an as-needed basis.
>
> So I am not implying by my question that I think that Yocto should have
> a way to do that kind of updating. I agree that it is out of the scope
> of the Yocto build system. And the update mechanism itself was in no
> case what prompted the question in the first place.
>
> The question was: How do people/companies deal with the problem of
> needing a new version of an existing package in a working image based on
> an old version of Yocto?
>
> Thanks again for your reply.
>
> Brian
>
>
My sincere apologies for completely misunderstanding your question. I've
CC'd the mailing list in this response, just in an attempt to help steer
further discussion back on course, after I wandered off. :)
Here's my attempt at more useful questions and comments, at least.
1) How have the maintainers of the upstream software in question resolved
the vulnerability?
1a) Is there a single patch, or a manageable number of patches, that you
could apply to address the vulnerability? If so, perhaps you could use a
.bbappend file [1] in your layer to append patches to SRC_URI.
1b) Take a look at how patches are backported in release branches (e.g.
[2]) for some inspiration.
2) In the case where the version you're on does not have an easily applied
patch available, is it possible to simply pull in a recipe from a newer
version of Yocto into your own layer(s)?
2a) Depending on the software, this might lead you down a dependency
rabbit hole, and might not be viable.
2b) If this is possible, I wonder if it would be sane to maintain your
own layer of updated recipes you're transitioning to, as not to clutter
whatever layer(s) you use for your organization. Ideally, once you reach a
point where you could fully switch to a newer Yocto release, you could just
drop this temporary layer from your bblayers.conf and track a maintained
release.
[1]
https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#using-bbappend-files
[2]
https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=rocko&id=b33d89d5ea8604657a59b83a30c3374079c34fd2
Best regards,
Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20180908/0c038304/attachment.html>
More information about the yocto
mailing list