Hi, Quoting Holger Levsen (2016-12-19 10:35:53) > On Mon, Dec 19, 2016 at 10:02:58AM +0100, Johannes Schauer wrote: > > Other ways to solve this problem include: > > - only accept .buildinfo files that include the .dsc filename and checksum > > - accept .changes files that reference both the .buildinfo and the .dsc > > those two seem sensible to me.
I see why you think those make sense and I see how I could agree with you. But thinking about this again, I think that the problem with implementing these two options would be that they would sneak in an unexpected privacy breach. If I add an option like --rebuild-and-verify=foo.buildinfo then the documentation for that command line option can include a big fat warning that using this option will try accessing snapshot.d.o to retrieve the right package versions. Including this warning if the buildinfo is used implicitly (for example if only a .changes file is passed) is not so easy. Furthermore, .changes files will now nearly always include a reference to the .buildinfo file. So if a .changes file were used, then another command line argument would be needed to turn the buildinfo verification on or off (depending on what the default is). Lastly, accepting bare .buildinfo files requires them to reference the .dsc which I find quite limiting. Builders should be able to verify .buildinfo files that do not contain the source package. Given all these arguments, adding a --rebuild-and-verify=foo.buildinfo option to sbuild sounds like the most sane thing to do. It would even not require the existing interface to change (the positional argument is a single source package). Any thoughts? cheers, josch
signature.asc
Description: signature
_______________________________________________ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds