[Reproducible-builds] concrete steps for improving apt downloading security and privacy

[Elmar Stellnberger]

    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
>