[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Official Debian digital 'branding' of debs

>>"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,
        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. 

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