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

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.


Attachment: signature.asc
Description: OpenPGP digital signature

Reproducible-builds mailing list

Reply via email to