[lkml]   [2005]   [Apr]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Git-commits mailing list feed.
    Paul Jakma wrote:
    > On Sun, 24 Apr 2005, David A. Wheeler wrote:
    > Hmm, what do you mean by "repeating what gets signed"?

    Forget it, irrelevant. I vaguely remembered some problem with
    gpg's detached signatures, but it was probably either a really
    early alpha version or someone was using "--clearsign" instead
    of "--armor". I just did a quick check with:
    gpg --armor --detach -o junk.sig junk.c
    and it worked "as expected"; no repeat of the data.

    >> Yes, and see my earlier posting. It'd be easy to store signatures in
    >> the current objects directory, of course. The trick is to be able
    >> to go from signed-object to the signature;
    > Two ways:
    > 1. An index of sigs to signed-object.
    > (or more generally: objects to referring-objects)

    Right. I suggested putting it in the same directory as the objects,
    so that rsync users get them "for free", but a separate directory
    has its own advantages & that'd be fine too.
    In fact, the more I think about it, I think it'd be cleaner
    to have it separate. You could prepend on top of the signature
    (if signatures are separate from assertions) WHAT got signed so
    that the index could be recreated from scratch when desired.

    > 2. Just give people the URI of the signature, let them (or their
    > tools) follow the 'parent' link to the object of interest

    If you mean "the signatures aren't stored with the objects", NO.
    Please don't! If the signatures are not stored in the database,
    then over time they'll get lost. It's important to me to
    store the record of trust, as well as what changed, so that
    ANYONE can later go back and verify that things are as they're
    supposed to be, or exactly who trusted what.

    > I think it might be more useful just to provide a general index to
    > lookup 'referring' objects (if git does not already - I dont think it
    > does, but I dont know enough to know for sure).

    git definitely doesn't have this currently, though you could run the
    fsck tools which end up creating a lot of the info (but it's then
    thrown away).

    > So you could ask "which
    > {commit,tag,signature,tree}(s) refer(s) to this object?" - that general
    > concept will always work.

    Yes. The problem is that maintaining the index is a pain.
    It's probably worth it for signatures, because the primary use
    is the other direction ("who signed this?"); it's not clear that
    the other direction is common for other data.

    --- David A. Wheeler
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-04-25 04:16    [W:0.023 / U:2.156 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site