Collaborative Working Sessions - Distributed verification

Distributed verification Notes

Session 1:

First Activity: Write down problem statements

Julien: disributed RB monitoring #scale #infratructure

Julien: trustless binary distribution #scale #infratructure - get rid of trust / the opposite of martin said about changing who you trust over time - Michael: having to pick someone to trust is a hard thing to do it is hard to do so in a way that is not absolute or muddy > wanting confidence without having to pick a point of failure - Julien: I don’t want to have users pick who to turst because it sounds complicated

Michael: tooling and infra to support multi party reproducibility verification at scale #scale - Michael: we want to fund this

Holger: distributed verification as the second step after making 90+ % things of reproducible #fromPossibleToUsefulOrActionable - explore difference between useful and actionable - make everyone benefit by default (not just a process you seek out) - get away from manual verification

Marc: RB creates resilience across a diverse set of build tools/diversity of build environments #security #notRelyOnASingleTool - problem of monocultures?

Herve: as a user of a lib, I want ot make sure I can do a simple fix #constraintOnSolution - make it sure it stays possible to

Martin: I want to be able to change who I trust over time - Michael’s reframe: want to be able to reason about my roots of trusti (and how they change over time) -> make tampering exponentially expensive for attackers - reducing the number of roots of trust?

Julien: make roots of trust transparent / easy to users

Mark: I want to be able to trust a published artifact because someone I trust reproduced it - Michael’s reframe: I want to be able to choose who I trust

Michael: Reproducible build cost by sharing the load in a pool #cost #practicality - everyone reproducing everything is not the solution - contribute the pool of reproducibility / benefit from the pool of reproducibility - pick whom I trust

Holger: if the russians, the cinese and the US agree, the build output is probably fine - kabal of enemies: PKI infrastructure - Apple reproducing Microsoft’s binaries / debian rebuilding fedora & fedora rebuilding debian

Holger: distros reproducing is silver, users reproducing is gold - enable anyone to verify that source and binary match up - Michael’s devils advocate question: people at the RB summit are not users - broad pool of people participating / it should be easy to be part of the pool / as easy as torrenting a file

Marc: improve security by linking source and artifacts - source by itself does not help if there is no link between artifact and source - self-generating provenance

Nicolas: - want to make sure that multiple trusted builders agree about output

Holger: we need tools for comparing rebuilder results

Justin: we need a way to to revocations of signatures without revoking keys - Martin: I think only using intuitionistic / constructive logic is sufficient - What about saying “oops I produced a lot of wrong results by mistake”

Justin: we need non-repudiation

Justin: how do we figure out how much consensus is enough and surface that to the end-user?

Michael: debugging failures to reproduce? #tooling

kpcyrd: trust not collude - justin: explicit collusion that is surfaced is OK <- delegation - Martin: freerider problem

kpcyrd: consensus is subjective / it depends on who you choose to listen to

First summary

Areas

Interesting points of tension

Taxonomy: