[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111101223917.GG32161@thunk.org>
Date: Tue, 1 Nov 2011 18:39:17 -0400
From: Ted Ts'o <tytso@....edu>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Junio C Hamano <gitster@...ox.com>, git@...r.kernel.org,
James Bottomley <James.Bottomley@...senpartnership.com>,
Jeff Garzik <jeff@...zik.org>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-ide@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [git patches] libata updates, GPG signed (but see admin notes)
On Tue, Nov 01, 2011 at 02:21:59PM -0700, Linus Torvalds wrote:
> So I'm wondering if we want to save it at all. it's quite possible
> that realistically speaking "google the mailing list archives" is the
> *right* way to look up the signature if it is ever needed later.
Given the number of trees that you merge in every merge window (never
mind over an entire release), I don't think "google the mailing list
archives" is going to scale. Finding some way to keep it along with
the merge window seems the right thing. I agree that it should hidden
normally, but that's a UI display issue. Heck, we could just hide
after the terminating NULL in the commit description, per a discussion
on the git list 2-3 weeks ago. :-)
> Because in many ways, "git request-pull" is when you do want to sign
> stuff. A developer might well want to push out his stuff for some
> random internal testing (linux-next, for example), and then only later
> decide "Ok, it was all good, now I want to make it 'official' and ask
> Linus to pull it", and sign it at *that* time, rather than when
> actually pushing it out.
Sure, the signed content should be buried in the commit that it
describes. Whether we carry it in an emphemeral tag or in the git
request-pull is not really important from a security perspective. The
tag is nicer simply because the person doing the pull won't need to
cut and paste the signature information.
One approach which might work is if git request-pull sends the e-mail
message with the git shortlog and diffstat, *and* an MIME attachment
that contained all of the necessary information. The maintainer would
then save the attachment, and feed it to git, which will display the
git shortlog and diffstat, ask for confirmation, and then embed the
digital signature into the merge commit.
The only problem with that is (a) you'd have to get over your hatred
of attachment (but if you're using Gmail hopefully that's relative
convenient :-), and (b) LKML list filter would have to be taught to
tolerate git-generated attachments.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists