Re: Official Debian digital 'branding' of debs
Hi,
>>"Brian" == Brian Warner <warner@lothar.com> writes:
Brian> My $0.02 ...
Brian> Split the problem into two pieces, as Manoj suggested:
Brian> 1: debs are signed by their developers. The signature needs to
Brian> be inside the .deb file, not in an external list or
Brian> Packages or changes file (an extra foo.sig member of the ar
Brian> archive for each current member makes sense to me). The
Brian> .deb you install might have come off an official CD, been
Brian> downloaded from a mirror, or copied third hand off a floppy
Brian> that your cousin's fishing buddy's plumber found under a
Brian> dumpster in a dark alley one evening.. all with identical
Brian> validity. End-to-end authentication, not link-to-link.
Brian> 2: The .deb is "official" if it is signed by the key of a
Brian> current developer in good standing. Determining *that* is
Brian> left as a (contentious) exercise for the reader. (but note
Brian> that it is much more of a policy thing than a technical
Brian> thing).
Actually, you can do this by getting the most recent
debian-keyring package. Suppose the debian keyring is signed
by the master debian key. You can then check the integrity of the
master key (go to the debian web site, or look at developers .sigs (I
shall have the fingerprint in my .sig), look at the Debian T shirt,
whatever.
When you are sure you have a good key, make sure you have a
valid keyring. The detatched sig on the key ring shall be on the same
place as the ring itself.
Now, you validate the .deb file against this keyring -- if the
key is not in the keyring, you have your answer.
Brian> Some observations, though: having a master key sign all the
Brian> developers keys is bad; it doesn't scale and is hard to
Brian> revoke.
Indeed. That is why I proposed the *keyring* be signed by the
debian key, not each and every individual key in the keyring.
Brian> Besides, signature on keys should mean faith in the
Brian> name-key binding, not faith in the name-being-a-
Brian> current-debian-developer binding. Having all the "official"
Brian> keys in a single keyring (which is authenticated or blessed
Brian> through some other mechanism) might work, GPG lets you
Brian> specify arbitrary sets of keyrings, you could use only
Brian> /usr/share/keyrings/debian-keyring.gpg while verifying a
Brian> .deb. Perhaps that keyring ought to be signed by the
Brian> "master" key, with a detached signature that is a part of
Brian> the debian-keyring package. Whenever a new version is
This was indeed the gist of my proposal (I did not think I had
to dot the i's and cross the t's ;-)
Brian> produced it is the Leader's responsibility to review the
Brian> list of keys against the list of developers and then decide
Brian> to sign the keyring (assuming the Project Leader is the
Brian> holder of the "master" key). A separate tool, included with
Brian> the keyring package, could be run periodically to a: verify
Brian> the signature on the keyring, and b: check www.debian.org
Brian> to see if the master key has changed, asking the user to
Brian> verify the change and do something to update the
Brian> checking-key if so. Ok, probably in the opposite order.
Umm, we should ahve a whole set of people who need to be
collectively responsible for handling the key. Oh, let a small number
have the right to revoke the key in an emergency, but let all of the
debian key masters be required to create a new one.
Brian> This implies that the developer of the debian-keyring
Brian> package must be a previously-valid developer. A brand new
Brian> developer taking over that job (starting with the version
Brian> that included their own key) would break the trust chain.
I would be hesitant to allow novice developers in that role anyway.
Brian> Also, I'm afraid that I see autobuilders fundamentally at odds
Brian> with signed packages. The only person who can take
Brian> responsibility for the contents of a .deb is the developer,
Brian> and if they aren't there while the package is being compiled
Brian> then they can't honestly take responsibility for what goes
Brian> into it. We could have an autobuilder signature (with all the
Brian> accompanying key compromise risks), but it would have far less
Brian> meaning than a human claiming that they had reviewed the
Brian> package and believed it to be free of tampering.
Autobuilders can't sign packages.
manoj
--
"In corporate life, I think there are three important areas which
contracts can't deal with, the area of conflict, the area of change
and area of reaching potential. To me a covenant is a relationship
that is based on such things as shared ideals and shared value
systems and shared ideas and shared agreement as to the processes we
are going to use for working together. In many cases they develop
into real love relationships." Max DePree, chairman and CEO of Herman
Miller Inc., "Herman Miller's Secrets of Corporate Creativity", The
Wall Street Journal, May 3, 1988
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Reply to: