<div dir="ltr"><div dir="ltr">Great question.  I hope if you don't mind that I reply on list.</div><div dir="ltr"><br></div><div dir="ltr">in-toto provides a way to know what / how many keys should be trusted for the build servers (and rotate them / replace them securely if needed, for example if a compromise occurs).  It also performs checks to make sure that what goes into the reproducible build process was actually a signed / tagged git release.  Following the reproducible builds process, it makes sure that any localization or further work on the reproducible builds output (if present) also actually used the result of the reproducible build.</div><div dir="ltr"><br></div><div>I'm happy to say more if it can help to clarify further.</div><div><br></div><div>Thanks,</div><div>Justin</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 1, 2021 at 5:58 PM Arnout Engelen <<a href="mailto:arnout@bzzt.net">arnout@bzzt.net</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>Hi,<br></div><div><br></div><div>As a 'consumer' of artifacts, you definitely need to verify signatures from several distinct trusted parties.<br></div><div><br></div><div>I have looked into in-toto on a couple of occasions but I'm afraid I don't understand what you mean by "in-toto style verification" in this scenario specifically - what does it contribute here?<br></div><div><br></div><div><br></div><div>Kind regards,<br></div><div><br></div><div>Arnout<br></div><div><br></div><div>On Sat, Jan 30, 2021, at 12:50, Justin Cappos wrote:<br></div><blockquote type="cite" id="gmail-m_1770408727607646881qt"><div dir="ltr"><div>I think it would be wise to add some sort of in-toto style verification that cryptographically checks proof that the reproducible builds were carried out and found equal.  Without this piece, why would an attacker with insider access even bother to go through the reproducible builds process?<br></div><div><br></div><div>Thanks,<br></div><div>Justin<br></div></div><div><br></div><div><div dir="ltr">On Sat, Jan 30, 2021 at 7:15 PM David A. Wheeler <<a href="mailto:dwheeler@linuxfoundation.org" target="_blank">dwheeler@linuxfoundation.org</a>> wrote:<br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>My post "Preventing Supply Chain Attacks like SolarWinds” <<a href="https://www.linuxfoundation.org/en/blog/preventing-supply-chain-attacks-like-solarwinds/" rel="noreferrer" target="_blank">https://www.linuxfoundation.org/en/blog/preventing-supply-chain-attacks-like-solarwinds/</a>> prominently discusses verified reproducible builds.<br></div><div><br></div><div>What would be especially helpful for accelerating deployment of verified reproducible builds in a few key places? E.g., what tools, infrastructure, people paid to do XYZ?<br></div><div><br></div><div>Thanks!<br></div><div><br></div><div>--- David A. Wheeler<br></div><div><br></div></blockquote></div></blockquote><div><br></div></div></blockquote></div></div>