Grep not actually reproducible on Arch but do we have a bigger issue?
cen
imbacen at gmail.com
Fri May 1 23:15:57 UTC 2026
On 02/05/2026 00:35, kpcyrd wrote:
> repro-threshold only acts as a rebuilderd client, if you configure "I
> want two parties to confirm they could reproduce the build server
> output from the alleged source code", and two if the rebuilders you've
> configured as trusted could indeed reproduce the binaries immediately
> after they've been released, repro-threshold would accept the package
> as valid - unless there's a collusion, the security guarantees still
> hold.
>
> The package eventually becoming unreproducible is "only" a problem if
> you later want to prove this to an auditor (or yourself), but can't.
That seems correct, I was wrongly thinking about a scenario where A and
B agree on a package but then the package would be rebuilt upstream 3
months later for some reason and become non-reproducible. But in
reality that never happens because upstream never rebuilds the same
exact thing, there is a version bump involved.
> I did this manually in the past using the *-repro-status[0][1] tools.
> :) Right now you need to run the tool multiple times, there's no flag
> (yet) to query multiple at the same time and compare results.
>
> [0]: https://github.com/archlinux/arch-repro-status
> [1]: https://github.com/kpcyrd/debian-repro-status
Right, so some kind of a daily scheduler that basically does the same
thing and flags the differences. Then I can add a nice shiny badge to
each package either saying "This package has been confirmed by N
different rebuilders" or one that says "Rebuilders disagree about this
package" or something like that and that's a giant red flag to
investigate it.
It makes more sense to do it periodically and not live because the
agreement can change over time.
As always, thank you for comprehensive response.
Best regards
More information about the rb-general
mailing list