Community
Participate
Working Groups
As of Git 1.7.9 it is possible to create signed commits. {J,E}Git should also allow creating signed commits.
Just as with signed tags, this requires a cryptographical library with PGP-support, e.g. Bonycastle. As I understand it, parts of bonycastle is not compatible with Eclipse wrt to the IP rules.
Changing importance to enhancement and moving to jgit since most of the work needs to be done there. Chris filed CQ 5136 [1] in May 2011 to get bouncy castle approved for use in jgit. This CQ is under IP review since end of May 2012 (a pretty long way :(, Sharon promised that she'll review it after Juno is over :). As soon as this is approved we can start implementing both signed tags and signed commits. [1] https://dev.eclipse.org/ipzilla/show_bug.cgi?id=5136
May I offer a suggestion with regards to IP on this enhancement. The integration with a cryptographic solution to do signing can be done via an extension point made via EGit. If EGit publishes an extension point to sign a block of text, an extension provider could implement a signing function (potentially by invoking an external program). It removes IP responsibility from the JGit and EGit teams. We could then encourage groups like Bonycastle to build a fairly trivial plug-in to execute a portion of their code to do the encryption. The interface for the extension point could be as simple as public interface IEgitCommentSigner { public String signGitContent(String content); }
Good news, bouncy castle is finally approved :) I also added the bundles in Orbit via bug 390058
What's the current status on this? Is it possible to sign commits via Egit or Jgit? Is there a known workaround?
signing is still not implemented. Waiting for JCE signing certificates since a long time. I will ping webmaster once more to make progress there.
(In reply to Matthias Sohn from comment #6) > signing is still not implemented. Waiting for JCE signing certificates since > a long time. I will ping webmaster once more to make progress there. What about the proposal to make bouncy castle an extension module for egit that is provided from outside and thus bypassing the ridiculously slow IP. Providing bc through Orbit is not helping at all IMHO, especially with security related libs where updating regularly is not optional...
(In reply to Jörg Sesterhenn from comment #7) > What about the proposal to make bouncy castle an extension module for egit > that is provided from outside and thus bypassing the ridiculously slow IP. I don't think it's a matter of IP. Looking at this doc: http://www.oracle.com/technetwork/java/javase/tech/getcodesigningcertificate-361306.html It seems that Oracle is giving out those certificates only to trusted entities. I don't think they will give it to some random external project trying to sign JCE providers.
(In reply to Matthias Sohn from comment #6) > signing is still not implemented. Waiting for JCE signing certificates since > a long time. I will ping webmaster once more to make progress there. My bad. See bug 467064.
What's the current status here? Given that bug 467064 is fixed, does that mean we are ok to start implementing signed commit/tag support in JGit? Or is there some other CQ/signing process that we're still waiting on? Somewhat related, I hesitate to say it, but I might like to start the CQ process for Bouncy Castle 1.59. We would love to be able to use JGit's BC support from Gerrit, but Gerrit has already upgraded its Bouncy Castle dependency, and its build system won't deal with having multiple versions of BC in the classpath. FWIW, I might be able to volunteer myself or someone on my team at Google to implement signed commit support. No promises yet, just throwing it out there :)
(In reply to Dave Borowitz from comment #10) > What's the current status here? Given that bug 467064 is fixed, does that > mean we are ok to start implementing signed commit/tag support in JGit? Yes. It's now possible to start implementing support for signing commits in JGit. > Somewhat related, I hesitate to say it, but I might like to start the CQ > process for Bouncy Castle 1.59. Please don't hesitate. Just get the CQs in and I'll approve. > FWIW, I might be able to volunteer myself or someone on my team at Google to > implement signed commit support. That would be fantastic. I'll have cycles to help testing patches/reviews.
(In reply to Dave Borowitz from comment #10) > What's the current status here? Given that bug 467064 is fixed, does that > mean we are ok to start implementing signed commit/tag support in JGit? Or > is there some other CQ/signing process that we're still waiting on? no, we just need someone doing the implementation :-) > Somewhat related, I hesitate to say it, but I might like to start the CQ > process for Bouncy Castle 1.59. We would love to be able to use JGit's BC > support from Gerrit, but Gerrit has already upgraded its Bouncy Castle > dependency, and its build system won't deal with having multiple versions of > BC in the classpath. +1 > FWIW, I might be able to volunteer myself or someone on my team at Google to > implement signed commit support. No promises yet, just throwing it out there > :) +1
Meanwhile bouncycastle 1.60 was released
Also see https://git.eclipse.org/r/#/c/124569/ where David Turner started with a small step.
Design doc with scope/goals for initial work here: https://docs.google.com/document/d/1qhQ1D3JSLoGxdkFabzJaPAhv0eW-9IzkW1if_HkqVyY/edit#
Gerrit change https://git.eclipse.org/r/133403 was merged to [master]. Commit: http://git.eclipse.org/c/jgit/jgit.git/commit/?id=9150f5d83654b2589c4dba2aeb76582de8df37f4
Gerrit change https://git.eclipse.org/r/133417 was merged to [master]. Commit: http://git.eclipse.org/c/jgit/jgit.git/commit/?id=137e91a4654b4f516d1f82885c669e14473dbfd6
Gerrit change https://git.eclipse.org/r/133402 was merged to [master]. Commit: http://git.eclipse.org/c/jgit/jgit.git/commit/?id=2343c688b19d9bce4e75ada280be44043ad2dca2
(adapting the summary to what was initially requested) The changes that just went in allow signing commits in JGit. BouncyCastle will be used for signing. Signing will lookup GPG keys in the usual locations (eg., ~/.gnupg/pubring.kbx). Support for 'user.signingkey' is included. Thus, if the config value is set it will be used for looking up an appropriate key. If it's not set, the committers email address will be used to find a suitable key. I'll mark this one fixed. Please open new once for any additional feature requests or bugs you discover.
Can someone please update this ticket to point to the documentation for how to use this feature? If you try to Google for docs, most links just take you to this ticket. There is a mention of the feature in the release notes for 5.3 but no examples https://wiki.eclipse.org/JGit/New_and_Noteworthy/5.3 A Google doc (linked below) that seems to be mostly an internal document void of examples https://docs.google.com/document/d/1qhQ1D3JSLoGxdkFabzJaPAhv0eW-9IzkW1if_HkqVyY/edit And a test in the repo with no real comments to explain what's going on https://git.eclipse.org/c/jgit/jgit.git/tree/org.eclipse.jgit.test/tst/org/eclipse/jgit/api/CommitCommandTest.java?id=2343c688b19d9bce4e75ada280be44043ad2dca2#n636 Is there a more comprehensive document that explains this feature, or is the test above the closest thing to an example that exists?
(In reply to Brad Wood from comment #20) > Can someone please update this ticket to point to the documentation for how > to use this feature? Yes, we're poor on documentation. The BouncyCastle-based signer lives in bundle org.eclipse.jgit.gpg.bc. GpgSigner in org.eclipse.jgit uses the ServiceLocator mechanism to find the concrete implementation. org.eclipse.jgit.gpg.bc is an OSGi fragment for host bundle org.eclipse.jgit, so in an OSGi environment it should find the implementation right away. In other environments you may have to ensure the class loader has the fragment on its classpath, or use GpgSigner.setDefault() explicitly. The CommitCommand and TagCommand by default use this default GpgSigner, but in newer JGit versions, you can set a signer explicitly on the command. Finding keys in based on the git config mechanisms: either user.signingKey is defined, or the GpgSigner can find a GPG key for user.email. If a key is found and signing is enabled, either from the config or explicitly, the commit or tag will be signed. For tags, we added the extension interface GpgObjectSigner. The base directories where to look for keys are hard-wired to the "standard" GPG directories. Using non-standard custom locations is currently not supported. It's possible to write an implementation of GpgSigner/GpgObjectSigner that uses an external gpg executable, see for instance EGit's ExternalGpgSigner. Uses of the JGit support for signing can also be found in EGit's CommitOperation and TagOperation; the uses in EGit UI, in particular CreateTagDialog and CommitInfoBuilder, may also be interesting. For signature verification, similar mechanisms are used, with GpgSignatureVerifierFactory and GpgSignatureVerifier.
