On 09/19/2014 06:07 AM, Elmar Stellnberger wrote: > Isn`t there really any way to include the signatures in the header of > the .deb files? > Why not simply add multiple signature files in the control.tar.gz of a > .deb just next > to the md5sums which should in deed be a sha256sums (otherwise there is > no way > to establish a 'chain of trust'). That would not add any non-determinism > because > if it is done right then we can have all the signers in the package! If we succeed in creating reproducible builds (we're farther along toward that goal than i had dared hope, it's exciting!) then one of the nice opportunites we have is for other people or organizations to corroborate the build after the package is first distributed. For example, an upload to sid might have one signature (by the original uploader), but maybe it waits to transition to testing until there are corroborations from multiple builders. (Note: this is not a concrete proposal or an expectation of exactly what will happen, just a thought experiment) In this scenario, how do you propose to add those signatures into the package? If we bundle them into the .deb, then the size and digest of the .deb itself changes after it is first distributed. This seems like it would violate all sorts of existing expectations -- i can't imagine how many different tools and pieces of infrastructure expect that foo_1.2-3_mipsel.deb should always have the same size and digest. > It would be far better than detaching the signatures from the package > because > the general use case where you need package signatures is the manual > download > of packages. Detached signatures are completely useless for such a use > case! I don't think this is the case. People who download a .deb and verify it could also download the associated .buildinfo file and whichever signatures they'd like (or all of them) and verify the package that way. --dkg
Attachment:
signature.asc
Description: OpenPGP digital signature