Binary Transparency II

Can we use the same idea as certificate transparency for the packages?

Why do we need this:

How does it work for website certificates: we have the information about when the certificate was issued and when does it expire. But what do we do with the idea of revocation?

Problems with revocation:

What can we use for the packages:

Revocation problem: there are at least 2 different situations:

  1. I found the bug in my test infrastructure, so please ignore my last result(s)
  2. I reproduced the build yesterday, but failed to reproduce it today.

Do we need to treat them differently?

Keep the logs;

Keep buildinfo files. If we reproduced - good, if not - check the inputs. If the inputs are different, this is not so surprising (although still can be a sign of non-reproducibility)

Look through all the logs:

  1. Select all buildinfo-s for the packages;
  2. Do all the output match?
  3. If output is different - are inputs different?

Put buildinfos into a log. Log has tree structures. Log infrastructure should be:

We want to look up output binaries later to run diffoscope on them. Keep them somewhere (cloud) stored by hash instead of names.

Hash tree log:

The fact that buildinfo captures output hash gives us the opportunity to look up this hash later, find the stored output binary and run diffoscope.

Outcome:

Just agree to log, then everyone can choose how to interpret them.

Binary Transparency II Post-It notes Binary Transparency II Post-It notes Binary Transparency II Post-It notes -