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

[Hans-Christoph Steiner]

Daniel Kahn Gillmor wrote:
> 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.

There needs to be a canonical, immutable signature (which could be a set of
individual signatures) on the final, official package for this to be a
workable system.  I like the idea of having a threshold of builder signatures
before a package is accepted into the official repo.  That makes a canonical
signature easy to: it would just be a whatever signatures that triggered the
inclusion, then perhaps also a dak signature.

Android's APK signature is a good example of this.  The Android system uses
TOFU/POP on the set of signatures.  At least one signature is required for an
APK to be installed, but it can also be many signatures.  Then whenever
updating, the new APK's set of signatures must match the installed APK's set.
 This means that it is easy to install test versions of packages as long as it
is not updating an installed package with a different signature.


>>    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

I strongly disagree.  Adding a separate file for the signature turns it into
something that only security-conscious techie people will do because it turns
it into a conscious decision and action.  Only a minority of techies actively
think about verifying software, it is basically a non-existent practice for
non-techies.  The signature and it's verification must be transparent to
actually work for the 99% of users who do not think about this stuff.

Having the signature embedded in the file itself means that .deb files can be
freely swapped via whatever available means, be it USB thumb drives, direct
download, LibraryBox, the cloud, SparkleShare, email, IM, whatever.  Then the
signature can be transparently verified by dpkg on install, and the user can
be entirely ignorant that the signature even exists unless there is a problem
with it.

.hc

-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81