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