aboutsummaryrefslogtreecommitdiffstats
path: root/org.eclipse.jgit/src/org/eclipse/jgit/lib/GpgSigner.java
Commit message (Collapse)AuthorAgeFilesLines
* Signing: refactor interfacesThomas Wolf2024-08-241-141/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a big API-breaking change cleaning up the signing interfaces. Initially, these interfaces were GPG/OpenPGP-specific. When EGit added new signers and signature verifiers that called an external GPG executable, they were found inadequate and were extended to be able to pass in the GpgConfig to get access to the "gpg.program" setting. With the introduction of X.509 S/MIME signing, it was discovered that the interfaces were still not quite adequate, and the "Gpg" prefix on the class names were confusing. Since 7.0 is a major version bump, I'm taking this chance to overhaul these interfaces from ground up. For signing, there is a new Signer interface. With it goes a SignerFactory SPI interface, and a final Signers class managing the currently set signers. By default, signers for the different signature types are created from the signer factories, which are discovered via the ServiceLoader. External code can install its own signers, overriding the default factories. For signature verification, exactly the same mechanism is used. This simplifies the setup of signers and signature verifiers, and makes it all more regular. Signer instances just get a byte[] to sign and don't have to worry about ObjectBuilders at all. SignatureVerifier instances also just get the data and signature as byte[] and don't have to worry about extracting the signature from a commit or tag, or about what kind of signature it is. Both Signers and SignatureVerifiers always get passed the Repository and the GpgConfig. The repository will be needed in an implementation for SSH signatures because gpg.ssh.* configs may need to be loaded explicitly, and some of those values need the current workspace location. For signature verification, there is exactly one place in core JGit in SignatureVerifiers that extracts signatures, determines the signature type, and then calls the right signature verifier. Change RevTag to recognize all signature types known in git (GPG, X509, and SSH). Change-Id: I26d2731e7baebb38976c87b7f328b63a239760d5 Signed-off-by: Thomas Wolf <twolf@apache.org>
* GpgSigner: prevent class lock inversion on the default signerThomas Wolf2022-04-141-14/+30
| | | | | | | | | | | | | | Don't store the default signer in a static field of the abstract superclass GpgSigner. This many lead to a lock inversion on the class initialization locks if there are concurrent loads of the GpgSigner class and of one of its subclasses, and that subclass happens to be the one the ServiceLoader wants to load. Use the holder pattern to de-couple the loading of class GpgSigner from the ServiceLoader call. Bug: 579550 Change-Id: Ifac0ea0c8985a09fe0518d0dabc072fafd6db907 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* Decouple BouncyCastle from JGit CoreMatthias Sohn2020-06-011-2/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | Motivation: BouncyCastle serves as 'default' implementation of the GPG Signer. If a client application does not use it there is no need to pull in this dependency, especially since BouncyCastle is a large library. Move the classes depending on BouncyCastle to an OSGi fragment extending the org.eclipse.jgit bundle. They are moved to a distinct internal package in order to avoid split packages. This doesn't break public API since these classes were already in an internal package before this change. Add a new feature org.eclipse.jgit.gpg.bc to enable installation. With that users can now decide if they want to install it. Attempts to sign a commit if org.eclipse.jgit.gpg.bc isn't available will result in ServiceUnavailableException being thrown. Bug: 559106 Change-Id: I42fd6c00002e17aa9a7be96ae434b538ea86ccf8 Also-by: Michael Dardis <git@md-5.net> Signed-off-by: Michael Dardis <git@md-5.net> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com> Signed-off-by: David Ostrovsky <david@ostrovsky.org>
* Update EDL 1.0 license headers to new short SPDX compliant formatMatthias Sohn2020-01-041-38/+5
| | | | | | | | | | This is the format given by the Eclipse legal doc generator [1]. [1] https://www.eclipse.org/projects/tools/documentation.php?id=technology.jgit Bug: 548298 Change-Id: I8d8cabc998ba1b083e3f0906a8d558d391ffb6c4 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Allow to check for signing keyGunnar Wagenknecht2019-01-221-3/+29
| | | | | | | | | The new API is intended for UIs to check if signing will be possible or would fail Bug: 543579 Change-Id: I6ce1fd4210e46d49dcdf420c99d08c93e022136c Signed-off-by: Gunnar Wagenknecht <gunnar@wagenknecht.org>
* Implement signing commits using BouncyCastleMedha Bhargav Prabhala2019-01-161-2/+14
| | | | | | | | | | | | | This also includes a change to generating the jgit CLI jar. Shading is no longer possible because it breaks the signature of BouncyCastle. Instead, the Spring Boot Loader Maven plug-in is now used to generate an executable jar. Bug: 382212 Change-Id: I35ee3d4b06d9d479475ab2e51b29bed49661bbdc Also-by: Gunnar Wagenknecht <gunnar@wagenknecht.org> Signed-off-by: Gunnar Wagenknecht <gunnar@wagenknecht.org> Signed-off-by: Medha Bhargav Prabhala <mprabhala@salesforce.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Allow CommitCommand to sign commitsGunnar Wagenknecht2019-01-161-0/+100
This change introduces the concept of a GpgSigner which will sign commits. The GpgSigner will be of a specific implementation (eg., Bouncycastle or OpenPgP executable). The actual implementation is not part of this change. Bug: 382212 Change-Id: Iea5da1e885c039e06bc8d679d46b124cbe504c8e Also-by: Medha Bhargav Prabhala <mprabhala@salesforce.com> Signed-off-by: Medha Bhargav Prabhala <mprabhala@salesforce.com> Signed-off-by: Gunnar Wagenknecht <gunnar@wagenknecht.org>