Re: [docs] [PATCH] security-manual: Add information about how security is handled in builds

Richard Purdie <[email protected]>
Newsgroups org.yoctoproject.lists.docs
Message-ID <ea4f44a7400e193bf4cd9b65d59e50b0593cf4b7.camel@linuxfoundation.org>
On Tue, 2026-08-11 at 10:01 +0200, Antonin Godard wrote:
> On Fri Aug 7, 2026 at 6:43 PM CEST, Richard Purdie via lists.yoctoproject.org wrote:
> > We have no information about how security is handled within the builds
> > themselves. Start to document this.
> > 
> > Signed-off-by: Richard Purdie <[email protected]>
> > ---
> >  .../security-manual/build-security.rst        | 41 +++++++++++++++++++
> >  documentation/security-manual/index.rst       |  1 +
> >  2 files changed, 42 insertions(+)
> >  create mode 100644 documentation/security-manual/build-security.rst
> > 
> > diff --git a/documentation/security-manual/build-security.rst b/documentation/security-manual/build-security.rst
> > new file mode 100644
> > index 000000000..5f15d5f64
> > --- /dev/null
> > +++ b/documentation/security-manual/build-security.rst
> > @@ -0,0 +1,41 @@
> > +.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
> > +
> > +**************
> > +Build Security
> 
> I suggest renaming it to "OpenEmbedded Build System Security", as "Build" alone
> could be interpreted in many different ways, including builds for specific
> software components, etc.

Perhaps "Build Process Security"? I think build system isn't quit the
right thing here.

> 
> > +**************
> > +
> > +OpenEmbedded is used to run the builds and careful consideration has gone into
> 
> When you say "OpenEmbedded" I guess you mean the community? Or the build system?
> 
> We have a :term:`OpenEmbedded Build System` that could be used here if relevant.

That seems like the right thing to use.

> > +how it does this with the aim of being both secure and reproducible. Like any
> > +system, it does need to be used carefully and in keeping with the design for
> > +that to be true. Users of the system should consider that:
> > +
> > +-  The builds generally aim for any input into the build process being verified in
> > +   some form. For source code tarballs, these would have a checksum. Git source
> > +   trees would have a specific git revision. Metadata would also usually be
> > +   under source control and also have revisions.
> 
> Add a link to our fetching documentation here?
> 
> """
> See the :doc:`bitbake:bitbake-user-manual/bitbake-user-manual-fetching` section
> of the BitBake User Manual for more information.
> """

Sure, I intended this as a first pass and figured it might need some
markup/tweaking. Sorry for the spelling :/.

> 
> > +
> > +-  Some elements that can influence the build are not verified. It is assumed
> > +   that the operating system running the system is secure and of a known setup and
> > +   version. The system goes to signififant lengths to isolate against host
> > +   contamination of the output but it is certainly possible, especially malicously.
> 
> typo: maliciously
> 
> Link to our supported distros here?
> 
> """
> See the :ref:`system-requirements-supported-distros` section of the Yocto
> Project Reference Manual for more information on supported host distributions.
> """
> 
> > +
> > +-  The builds assume DL_DIR is a safe location. Once things enter that location
> 
> s/DL_DIR/:term:`DL_DIR`/
> 
> > +   there are not repeatedly re-verified. A user could edit the git trees or
> > +   tarballs there in ways the build might not detect.
> 
> I guess this will be better detailed with
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=16102. Maybe the documentation
> coming from this bug should be linked here then.

This text was intended to help close 16102 :/. We've not managed to get
anyone else to provide such information. Certainly if any more is
forthcoming, this would be the place to add it. I did want to document
something before we close that bug though.

Cheers,

Richard
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.