Re: [Reproducible-builds] concrete steps for improving apt downloading security and privacy
Daniel Kahn Gillmor wrote:
> Thanks for the discussion, Hans.
>
> On 09/19/2014 02:47 PM, Hans-Christoph Steiner wrote:
>> 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.
>
> But some repositories could have different rules for package inclusion
> than others, right? for example, say debian wanted to offer an
> unstable-reproducible suite, which only permitted packages that had been
> independently rebuilt reproducibly by multiple DDs and at least two
> different buildds. Ideally, the packages that are shared between this
> repository and other repositories would be identical.
>
> Note that if .deb files are internally signed, two developers *cannot*
> create the same exact .deb if they do not share their secret keys.
You're missing one key detail here, let's see if I can suss it out:
* the builds are _exactly_ the same, except the signatures
* the embedded signature does not sign the signature files (see
jar and apk formats, which are almost the same, for examples)
* anyone can just copy other dev's signature into the package and it
will validate because the package contents are exactly the same
* the signature files sign the package contents, not the hash of
whole .deb file (i.e. control.tar.gz and data.tar.gz).
Therefore two developers can easily create the same .deb if that have access
to the signature file since they can just copy it. No need to run the signing
process again. If people create their own .deb files in a reproducible
process, then copy in the same signature files, then the hash of the .deb will
be the same.
>> 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.
>
> I agree with this sentiment, i think we're trying to sort out what is
> the "right 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.
>
> but the .buildinfo file is designed to say "i generated the .deb that
> matches this digest exactly", which the corroborating builder cannot do,
> because they cannot produce the internal signature.
No need to produce the signature, just copy it!
> Plus, we now have two different places to look for signatures. one
> "canonical" one and then some external ones, and the signatures
> themselves have different properties (one signs parts of the deb, the
> other signs the whole .deb; one signs the build environment, the other
> does not, etc)
Definitely look at jar signing, it handles multiple signatures fine. I see no
reason why you can't include an unlimited number of signatures in a .deb.
Changing the number of signatures will change the hash of the .deb, that is
why there needs to be a canonical set of signatures for each .deb.
As for signing the hash of the entire .deb, that is what apt already gives us,
that does not need to be reproduced in the dpkg-sig embedded signature. For
people who want to verify the contents of a .deb with any kind of signature,
then a tool will have to compare the hashes of control.tar.gz and data.tar.gz.
>> 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.
>
> Again, i think this is getting ahead of the discussion. i'm not
> proposing that we try to set debian (or other derived distro) archive
> policy here, i just think we want to think
>
>> In any case, the .deb needs to remain unchanged.
>
> right. but it can't be unchanged if the archive distributor decides
> that a different signer is the "canonical" signer. So you're making the
> contents of the .deb dependent on archive policy, rather than the other
> way around.
>
> I *want* ubuntu and debian and mint to all ship the exact same .deb for
> any packages that are reproducible (and eventually, all packages!) that
> they share, and i also want those different distros to be able to
> produce the reproducible .deb independently of one another. If
> foo_1.2-3_mipsel.deb is built first on the ubuntu builders and ubuntu
> decides to include it in the archive, and then debian is able to
> reproduce that build and wants to include it in debian, these should be
> the same .deb file, even though the archive gating infrastructure is
> independent.
There just needs to be a standard way to point to the .deb file with the
canonical signature on it. So whichever distro picks up a .deb from another
would run their build, download the canonical .deb, and copy in the signature.
>> 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..."
>
> exactly, and i think this is a good thing. it's a clear external signal
> that they're transporting a signed object. Users can also sneakernet
> around arbitrary .tgz files, or .zip files, or .dmg's or whatever. we
> can't stop them from doing that, but we *can* say "if you want to
> sneakernet things around with any sort of cryptographic security, you
> should be sneakernetting things that look like *.debs, and nothing else".
I still strongly disagree. Very very few people care enough to learn a
separate process. For security to be usable, it needs to be as transparent
and automatic as possible. APKs and Android have demonstrated that you can
have this kind of system working well. They've made the whole process easier
by requiring the upstream developer be the manager of the signing. I think
setting up a similar role in Debian will be quite beneficial, and dak and the
package maintainer are natural roles to be the signer.
> If we say "some .deb files might be signed, some might not, good luck
> with that" it's less clear.
>
> There is a long-standing, widely understood idea about what a .deb is.
> Changing that to be something that only a given party can generate goes
> directly against the goal of having builds be reproducible.
>
> We know that detached signatures allow us the flexibility to do all
> kinds of clever archive-decided policy while sharing a broad consensus
> about the byte-for-byte nature of any piece of compiled code.
>
> Detached signatures fail at ease of manual transport.
>
> Introducing a package wrapper that includes signatures to facilitate
> manual transport seems like the way to solve that problem, rather than
> having to embed or privilege any one canonical signature above another,
> or introduce two different-yet-similar mechanisms for individual binary
> package signing and verification.
We have detached signatures in apt, I see no good reason to introduce a second
detached sig format. I don't think it solves anything. If the embedded
signatures are tied to the reproducible process, then anyone can freely
generate the .deb since they can copy the canonical signature into place.
There just needs to be a trusted role to generate and distribute the canonical
signature in a way that makes sense.
.hc
--
PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81
Reply to: