A package with some new signatures added is no more the old package.
It should have a different checksum and be made available again for update.
Perhaps someone wants to install the package not before certain signatures
have been added.
Your thought experiment would this way of course require an adjusted
toolchain i.e. sth. like dpkg-cmp that outputs differences in the
description
tags, signatures and file content separately. I believe this would be
the best
way to do it because you seldomly need to compare two packages while you
will need to install individually downloaded packages more often. Just think
f.i. about printer driver, device firmware, 3rd party software or singleton
packages which you do not want to add to apt. Downloading two files all
the time would be far more enervating than a well programmed dpkg-cmp.
... and as long as the tool should not be available simply un-ar and compare
the data.tar.gz-s.
Am 19.09.14 um 15:16 schrieb Daniel Kahn Gillmor:
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
--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/541f134a.3080...@gmail.com
