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