lkml.org 
[lkml]   [2005]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Git-commits mailing list feed.
    Linus Torvalds wrote:
    >
    > On Sun, 24 Apr 2005, David A. Wheeler wrote:
    >
    >>It may be better to have them as simple detached signatures, which are
    >>completely separate files (see gpg --detached).
    >
    > Actually, if we do totally separate files, then the detached thing is ok,
    > and we migth decide to not call the objects at all, since that seems to be
    > unnecessarily complex.
    >
    > Maybe we'll just have signed tags by doing exactly that: just a collection
    > of detached signature files. The question becomes one of how to name such
    > things in a distributed tree. That is the thing that using an object for
    > them would have solved very naturally.

    I agree, naming signatures using the same way other objects are named
    would be very clean. So, why not? It's perfectly reasonable to
    just store detached signatures as hashed objects, just like the rest;
    just create a new object type ("signature").
    If 3 different keys are used to sign the same object, the detached
    signatures will have different hash values, so they'll get named easily.

    Now you just have to FIND the signature of a signed object,
    i.e. efficiently go the "other way" from signed object to detached
    signature. A separate directory with this mapping, or embedding the
    mapping inside the object directory (HASH.d/<list>) both solve it.

    The more I think about it, the more I think a separate "reverse"
    index directory would be a better idea. It just needs to from
    "me" to "who references me", at least so that you can quickly
    find all signatures of a given object. If the reverse directory
    gets wonky, anyone can just delete the reverse index directory
    at any time & reconstruct it by iterating the objects.
    Before "-----BEGIN PGP SIGNATURE-----" you should add:
    signatureof HASHVALUE
    to make reconstruction easy; PGP processors ignore stuff
    before "-----". The PGP data does include a hash, but it's not
    easy to get it out (I don't see a way to do it in gpg from the
    command line), and it's quite possible that a signer won't
    use SHA-1 when they sign something (they may not even
    realize it; it depends on their implementation's configuration).
    Better to include something about what was signed with the signature.

    Hmm, probably worth backtracking to see what's needed.
    There needs to be a way to identify tags, and a way to sign that
    tag so that you can decide to trust some tags & not others.
    There needs to be a way to sign commits, and store that info
    for later. And really, these are special cases of general
    assertions about other things; you might want someone to be
    able to make other signed assertions (e.g., that it
    passed test suite XYZ).

    If tags & commits are all you plan to sign for now, well, you
    already have commits. You can just add a "tag" type and a
    "signature" type of object (the "signature" is just a detached
    OpenPGP signature). "signature" can sign tag or commit types.
    I still like the idea of a more general "assertion" type, esp.
    for assertions that something passed a test suite on a certain date
    or was reviewed at a certain date by someone, but admittedly
    that could be added later in the same manner.

    Then you need to be able to quickly find a signature, given a
    commit or tag. A "reverse" directory then does that nicely,
    and if you put enough information in front of the signature,
    you can regenerate the reverse directory whenever you wish.

    --- David A. Wheeler
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-04-25 05:13    [W:4.030 / U:0.372 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site