<div dir="ltr">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.<div><br></div><div>Thanks,</div><div>Justin</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Oct 1, 2025 at 8:37 AM Arnout Engelen via rb-general <<a href="mailto:rb-general@lists.reproducible-builds.org">rb-general@lists.reproducible-builds.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u><div><div>On Wed, Oct 1, 2025, at 13:45, kpcyrd wrote:</div><blockquote type="cite" id="m_8356897656524726644qt"><div>On 9/29/25 3:28 PM, Arnout Engelen via rb-general wrote:</div><div>> 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".</div><div><br></div><div>It's really close to "until Wednesday" already</div></blockquote><div><br></div><div><div>Yeah, I meant to share all this much earlier, but 'life happened'. Luckily the 'upstream' deadline is Friday, so we have *some* time :)</div><div><br></div><div>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:</div><div><br></div><div>==</div><div>This document summarizes the position of <span style="color:rgb(27,29,34)">from various project representatives in the R-B project</span>, namely:</div><ul><li>(...)</li><li>Arnout Engelen for Reproducible Builds in the NixOS project</li><li>(...)</li></ul><div>==</div><div><br></div><div>Let's say if we can get to '3' I'll post the comment?</div><div><br></div></div><blockquote type="cite" id="m_8356897656524726644qt"><div>in my opinion a missed opportunity in the original SBOM standard was:<br></div><div>> The build tools/compiler are a material of your software executable</div><div><br></div><div>Knowing which exact compiler and compiler version was used is necessary </div><div>for triaging certain security issues[1], and it's also critical </div><div>information for any reproducible builds efforts.</div><div><br></div><div>At the moment this gap is filled by buildinfo files (each project having </div><div>their own):</div><div><br></div><div><a href="https://reproducible-builds.org/docs/recording/" target="_blank">https://reproducible-builds.org/docs/recording/</a></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote type="cite" id="m_8356897656524726644qt"><div>Also to any CISA staff following this thread: hi! 😺</div></blockquote><div><br></div><div>👋😃</div><div><br></div><div><br></div><div id="m_8356897656524726644sig124436424"><div>-- </div><div>Arnout Engelen</div><div>Engelen Open Source</div><div><a href="https://engelen.eu" target="_blank">https://engelen.eu</a></div></div><div><br></div></div></blockquote></div>