FYI: One thing we're pushing toward is the inclusion of in-toto attestations in SBOMs, which would capture that information. We've been pushing for about a year now and there seems to be some support, but it's still in the works.
Thanks, Justin On Wed, Oct 1, 2025 at 8:37 AM Arnout Engelen via rb-general < [email protected]> wrote: > On Wed, Oct 1, 2025, at 13:45, kpcyrd wrote: > > On 9/29/25 3:28 PM, Arnout Engelen via rb-general wrote: > > Do you agree with the comments above? Are there any changes you'd like > to see, or additional comments you think would be valuable to relay in the > context of reproducible builds? The timeline is relatively strict: if we > can get rough consensus before, say, Wednesday, I think we could respond > "as the Reproducible Builds project". > > It's really close to "until Wednesday" already > > > Yeah, I meant to share all this much earlier, but 'life happened'. Luckily > the 'upstream' deadline is Friday, so we have *some* time :) > > As Holger mentioned it's perhaps a bit too short notice to arrive at a > 'Position of the Reproducible Builds project', but perhaps we can comment > with something like: > > == > This document summarizes the position of from various project > representatives in the R-B project, namely: > > - (...) > - Arnout Engelen for Reproducible Builds in the NixOS project > - (...) > > == > > Let's say if we can get to '3' I'll post the comment? > > in my opinion a missed opportunity in the original SBOM standard was: > > The build tools/compiler are a material of your software executable > > Knowing which exact compiler and compiler version was used is necessary > for triaging certain security issues[1], and it's also critical > information for any reproducible builds efforts. > > At the moment this gap is filled by buildinfo files (each project having > their own): > > https://reproducible-builds.org/docs/recording/ > > > I agree having that information can be (in)valuable. More widely, > realistically I think there's SBOMs for various use cases, and how far you > go in declaring 'build-time context/dependencies' depends on the use case. > Perhaps we could include this as a comment on the introduced 'Generation > Context' field: we could confirm there are different kinds of context, and > emphasize we believe that whether/which build-time dependencies you include > depends on that context. Personally, I think it's to early to 'standardize' > on such a field (I don't think there's any consensus what the exact meaning > would be), so I would recommend to remove this field from the current > version of the doc. We could also recommend adding a line saying the > context can determine whether/which build-time dependencies should be > included. > > Also to any CISA staff following this thread: hi! 😺 > > > 👋😃 > > > -- > Arnout Engelen > Engelen Open Source > https://engelen.eu > >
