All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Shawn O. Pearce" <spearce@spearce.org>
To: "Balasubramaniam, Arunan" <Arunan.Balasubramaniam@misys.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: Implementing commit signing
Date: Thu, 9 Oct 2008 11:00:26 -0700	[thread overview]
Message-ID: <20081009180026.GX8203@spearce.org> (raw)
In-Reply-To: <E74D836C8B2CEF4A89F47E8ACECEEF9B748DCD@maildub1.misys.global.ad>

"Balasubramaniam, Arunan" <Arunan.Balasubramaniam@misys.com> wrote:
> Shawn O. Pearce wrote:
> 
> > But as I think about it more, if you signed the diff, excluding the
> > line offsets in the hunk headers (so file paths, context and -/+
> > lines), the "author" line and the message, leaving out the other
> > fields of the commit message, it may be possible to still include
> > the signature in an email formatted patch and carry it through a
> > "git format-patch | git am" pipeline and still have it verify.
> 
> Would this be dangerous? If you were to leave out the parent fields in
> the commit message, surely you could then reapply an old commit (that
> say introduced a bug)?

Well, the idea was to sign the diff, but in a way that would
reasonably allow it to be applied with limited fuzz, such as what
git-apply would accept.  Thus signed changes could be emailed out
by git format-patch and git send-email, and applied with git am,
and the signature is still valid so long as the committer didn't
mess with the patch.

Obviously if a commit was reverted and then reapplied again later,
yes, the signature on the reapply may actually be valid, as the
parents weren't taken into consideration.

If the format-patch output was modified to include the parent when
the signature was included then git am could be trained to verify
HEAD == parent before applying the commit.  Then you can include
the parent as part of the signature, but still enable a format-patch
and am based workflow.
 
> > Yes, absolutely, so long as the implementation in Java was reasonably
> > sane.  E.g. we'd prefer you used a pure Java implementation of
> > GnuPG
> 
> I don't think that there is a Java GPG implementation about, some
> searching
> didn't find any live looking projects .

Bouncy Castle:  http://www.bouncycastle.org/java.html

> Would a JNI wrapper to say GPGME
> (http://www.gnupg.org/related_software/gpgme/index.en.html) be
> acceptable?

No, JNI isn't "pure Java".

-- 
Shawn.

  reply	other threads:[~2008-10-09 18:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-09 17:53 Implementing commit signing Balasubramaniam, Arunan
2008-10-09 18:00 ` Shawn O. Pearce [this message]
  -- strict thread matches above, loose matches on Subject: below --
2008-10-10 14:19 Balasubramaniam, Arunan
2008-10-09 14:03 Balasubramaniam, Arunan
2008-10-09 15:44 ` Shawn O. Pearce

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081009180026.GX8203@spearce.org \
    --to=spearce@spearce.org \
    --cc=Arunan.Balasubramaniam@misys.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.