How could we accelerate *deployment* of verified reproducible builds?

[Justin Cappos]

Great question.  I hope if you don't mind that I reply on list.

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.

I'm happy to say more if it can help to clarify further.

Thanks,
Justin

On Mon, Feb 1, 2021 at 5:58 PM Arnout Engelen <arnout at bzzt.net> wrote:

> Hi,
>
> As a 'consumer' of artifacts, you definitely need to verify signatures
> from several distinct trusted parties.
>
> 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?
>
>
> Kind regards,
>
> Arnout
>
> On Sat, Jan 30, 2021, at 12:50, Justin Cappos wrote:
>
> 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?
>
> Thanks,
> Justin
>
> On Sat, Jan 30, 2021 at 7:15 PM David A. Wheeler <
> dwheeler at linuxfoundation.org> wrote:
>
> My post "Preventing Supply Chain Attacks like SolarWinds” <
> https://www.linuxfoundation.org/en/blog/preventing-supply-chain-attacks-like-solarwinds/>
> prominently discusses verified reproducible builds.
>
> 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?
>
> Thanks!
>
> --- David A. Wheeler
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20210201/e7325bee/attachment.htm>