lkml.org 
[lkml]   [2011]   [Nov]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [git patches] libata updates, GPG signed (but see admin notes)
    On Fri, Nov 4, 2011 at 7:59 AM, Ted Ts'o <tytso@mit.edu> wrote:
    >
    > Note that a repository format change will break a bunch of other
    > things as well, including references in commit descriptions ("This
    > fixes a regression introduced in commit 42DEADBEEF")

    No they won't. Not if you do it right. It's easy enough to
    automatically replace the SHA1's in the description, the same way we
    replace everything else.

    Really. It's *trivial*.

    Maybe some current tools don't do it, but if I were to convert the
    kernel tree, I'd absolutely *require* the conversion to be done right.
    And "right" means "don't just get the parent SHA1's right, but the
    ones hiding in the description too".

    Any conversion tool has to keep track of the translation from "old
    SHA1 to new SHA1" *anyway* because of all the other issues (ie exactly
    things like parent pointers etc), so conversion tools by definition
    have the information to do things like this right.

    But "internal cryptographic signatures" are fundamentally different. A
    conversion tool *cannot* convert them, since it won't have access to
    the private keys in question, and thus cannot fix up the signature.

    Sure, if I do the conversion, I could make *my* signatures match. And
    that is true for every signer out there - individually. But only
    individually, never collectively. Sure, we could all meet in one place
    and synchronously re-sign things on our private machines with some
    "distributed conversion tool", but realistically that really really
    doesn't work.

    It's a fundamental problem. And it really isn't a theoretical one -
    it's one we know will happen *some* day.

    I haven't worried about SHA1, exactly because I know it's not a real
    problem - we can always convert. But internal signatures very
    fundamentally change that.

    And it really is about *internal* signatures. The kinds of signed tags
    we have now are not a problem. Those can trivially be converted in a
    distributed manner, exactly because they are "detatched" from what
    they sign. We carry them along with the git repo, but they don't mess
    up history, and they can be re-created individually without changing
    anything else.

    And yes, this was actually a design issue for me, which is why I feel
    so strongly about it. I actually *thought* about issues like this
    five+ years ago: I wanted to have cryptographic security, but I very
    much on purpose wanted it to be "outside" the repo.

    (Ok, so the git tag objects can sign other git tag objects
    recursively, and in that case you have an ordering issue where a
    conversion would first have to get somebody to re-sign their "inner"
    tag before the "outer" signature can be re-created, but even if that
    were to happen - and I don't think anybody does it - it's a trivial
    problem with no real complexity issues).

    >>  - they are ugly as heck, and you really don't want to see them in
    >> 99.999% of all cases.
    >
    > So we can make them be hidden from "git log" and "gik" by default.
    > That bit is a bit gross, I agree, but 3rd party verification really is
    > a good thing, which I'm hoping can be added in a relatively clean
    > fashion.

    I agree that we can hide them - that's after all what the pgpsig thing
    does in the "internal commit signature" that git has in pu/next. That
    one hides ie even more specifically, by putting it in the headers of
    the commit, but that's just a random implementation detail.

    But I really think that "internal signatures" that actually affect the
    SHA1 of the object and its history have fundamental design problems.
    They may not be "insurmountably bad", but they are definitely real.

    Linus
    --
    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: 2011-11-04 16:17    [W:0.024 / U:59.056 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site