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

[Hans-Christoph Steiner]

Daniel Kahn Gillmor wrote:
> Hi Hans--
> 
> I think we're in agreement here about most things actually, despite our
> back-and-forth.  hopefully this is a clarifying response:
> 
>> Daniel Kahn Gillmor wrote:
> In that case, the .deb that was installed on a sid system *is not* the
> .deb that is installed on a testing system.
>
> If i run a mixed unstable/testing system (i do, actually, this is not
> hypothetical) should i need to re-install foo_1.2-3_mipsel.deb when that
> package transitions from unstable to testing (without any changes made
> to it other than new signatures)?  That seems odd, but the .debs are now
> no longer bytewise identical.  should archive operators who are doing
> rsync mirroring of a number of pools update their .debs as new
> signatures are added to them?  can they still use rsync for this cleanly
> without a massive increase in bandwidth between mirrors or do we need to
> define a new synchronization mechanism?
> 
> The question of what is a "canonical, immutable signature" for any given
> distribution is also problematic, because it ties the policy of the
> distribution (already defined by what that apt repository includes and
> references in Release.gpg) to a set of individual package signatures.
> But this is exactly the point where we'd like more flexibility.  People
> who care about apt repo X and use it online can use Release.gpg, while
> people who are *not* using the apt repo might have a different set of
> policies.  And some repos might want to share specific packages with
> each other -- what if their signing policies about the "canonical"
> signature conflict?  should they have to rebuild the package?

Packages should not be accepted into any official repo, sid included, without
some verification builds.  A .deb should remain unchanged once it is accepted
into any official repo (maybe experimental could be an exception, but not
sid).  I think that is essential.

I see no reason for changing the .deb between sid and testing, except for
perhaps how existing implementations are doing it.  It is usually worth the
work to do things right way, rather than the easy way.

The build verification process needs to happen between the package upload and
publishing to sid or security updates.  Two builds is easy: the .deb that the
uploader generates and the one the Debian process makes.  That is probably enough.

In Debian's case, it probably is too complicated to include multiple
signatures.  In that case, there should be only one canonical signature by dak
once the build verification signature threshold has been passed. Then all of
the other signatures could be added to .buildinfo or .changes or whatever
other file.

Another option is to do it like f-droid.org does.  F-droid.org generates a APK
signing key for each app, then manages the signing on a specialized signing
server.  Or another option is just requiring all the signers to be from the
debian-keyring, rather than an exact match for previous signers.  In any case,
the .deb needs to remain unchanged.




> You're entirely right that when fetching files via the web directly
> (instead of an apt repository) or sneakernet, people tend to transfer
> only the minimal set of possible files, and therefore having detached
> signatures is a bad idea for adoption.
> 
> But i don't think this addresses the concern raised above that specific
> .deb files have constant size and contents, which is an assumption that
> permeates the repository, mirror, and distribution mechanisms.
> Rejecting that assumption means potentially breaking a lot of
> infrastructure that currently works, as well as forcing incompatible
> policy changes on archive operators.
> 
> So i'd like to have this cake and eat it too, please :)
> 
> Here's a proposal for chewing over:
> 
>  * define a new package format called .debs
> 
>  * foo_1.2-3_mipsel.debs is a tarball that contains at least three files:
> 
> foo_1.2-3_mipsel.deb
> foo_1.2-3_mipsel.buildinfo
> foo_1.2-3_mipsel.buildinfo.0EE5BE979282D80B9F7540F1CCD2ED94D21739E9.asc
> 
>   (it can contain more than one .asc if it wants to include multiple
> signatures)
> 
>  * if you invoke "dpkg -i foo_1.2-3_mipsel.debs", dpkg should unpack and
> inspect the .debs, and the signatures, and refuse to install the .deb if
> the signatures don't meet local policy.  (i'm hand-waving here about
> what "local policy" is, since i think that's a separate discussion)
> 
> Now we can leave the current online archive distribution alone -- apt
> works (modulo bugs) and archive operators can continue to function as
> they currently do.  But we tell users and upstream developers that if
> they want to install packages via sneakernet or by downloading them
> individually from the web that they really should be passing around
> .debs files, and not .deb files.  We could even modify dpkg to reject
> installations of plain .deb files unless a package manager (which has
> presumably already verified the package by other means) is doing the
> installation.
> 
> what do you think?
> 
> 	--dkg

I think this can be done using the existing .deb format.  This.debs approach
also requires a conscious opt-in: "we tell users and upstream developers that
if they want to install packages via sneakernet..."

.hc


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