aboutsummaryrefslogtreecommitdiffstats
path: root/org.eclipse.jgit.gpg.bc/src
Commit message (Collapse)AuthorAgeFilesLines
* GPG: use BC PGP secret key parsing out of the boxThomas Wolf2024-11-066-1468/+61
| | | | | | | | | Remove the custom S-expression parsing; BC has gotten many improvements in 1.79 regarding PGP ed25519 keys, AES/OCB encryption, and generally parsing key files. It now can do all we need. Change-Id: I392443e040cce150a9575d18795a7cb8195a3515 Signed-off-by: Thomas Wolf <twolf@apache.org>
* [errorprone] bc: Remove unused SExprParser#parseSecretKeyIvan Frade2024-11-051-148/+0
| | | | | | | | | | errorprone complains about using Date in the SExprParser class. All the usages are in a variant of the parseSecretKey method that doesn't have any callers. Remove the unused method. Change-Id: I80f5aa58877b9da31729cb90b0219e45d96144a8
* Update bouncycastle to 1.79Matthias Sohn2024-11-051-0/+7
| | | | Change-Id: Ib81d73075ebc9dcdc73aacf30fa02ad56a502d51
* Signing: refactor interfacesThomas Wolf2024-08-245-248/+105
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Add a missing license headerThomas Wolf2024-08-241-0/+9
| | | | Change-Id: Iccb922ea73b0bfd6360ea2182b88c520a951a0a2 Signed-off-by: Thomas Wolf <twolf@apache.org>
* [gpg] Correct finding public keys from pubring.gpgThomas Wolf2024-04-084-56/+172
| | | | | | | | | | | With a master key not enabled for signing, and a signing sub-key, key lookup went wrong in several ways and might not find a suitable key for signing or for signature verification. Fix the code so that it finds the sub-key, even if user.signingKey is specified not with a key ID but with an with an e-mail. (Sub-keys don't have user ids, those are attached only on the master key.) Change-Id: I9d1f641c49b173d4daffb3fd2e74f5aabd856e39 Signed-off-by: Thomas Wolf <twolf@apache.org>
* [gpg] Fix reading ed25519 GPG keysThomas Wolf2024-04-083-25/+149
| | | | | | | | | | | | The S-expression parser from Bouncy Castle parsed such keys wrongly; there is a "flags" sub-list before the "q" value. Additionally, the parser validates the key read against the given public key, this failed because Bouncy Castle does not know the OID of curve name "Ed25519". Fix this and add a test for reading an ed25519 GPG key. Bug: jgit-27 Change-Id: Ia50445b88759927d2e80b9871d498fbe5ad201bc Signed-off-by: Thomas Wolf <twolf@apache.org>
* [gpg] Refactor the GpgSignatureVerifierThomas Wolf2024-02-011-52/+12
| | | | | | | | | | | | | | | | Add a new method verify(GpgConfig, byte[], byte[]) and deprecate the existing verify(byte[], byte[]). Some implementations of the interface may need the GpgConfig. Factor out extracting the raw armored signature from commits or tags into an abstract AbstractGpgSignatureVerifier class so that different implementations don't have to re-implement that bit. Call the new verify method, passing along the GpgConfig. This makes the GPG interfaces more versatile and facilitates implementing an alternate GpgSignatureVerifier. Change-Id: I9cf093caa9fdebede801d665f2591cd9b275e1fd
* gpg.bc: Supress errorprone InsecureCryptoUsageIvan Frade2023-11-171-0/+4
| | | | | | | | | | | From errorprone doc: "Dynamically constructed transformation strings are also flagged, as they may conceal an instance of ECB mode." https://errorprone.info/bugpattern/InsecureCryptoUsage Silence the message as a quick relief. Change-Id: I348f0fff0e3b24ce1f11917e849b4095b186d1f0
* [errorprone] Fix InconsistentCapitalizationMatthias Sohn2023-10-061-3/+3
| | | | | | See https://errorprone.info/bugpattern/InconsistentCapitalization Change-Id: Ibd71a992128ca2e5f916a08dd11da67c5a2f8aad
* [errorprone] Suppress MissingSummary for translation bundlesMatthias Sohn2023-09-251-0/+1
| | | | Change-Id: I4da51c7e089366b016a0cc64f768a151c24bc956
* Fix all Javadoc warnings and fail on themAntoine Musso2023-06-165-3/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes all the javadoc warnings, stops ignoring doclint 'missing' category and fails the build on javadoc warnings for public and protected classes and class members. Since javadoc doesn't allow access specifiers when specifying doclint configuration we cannot set `-Xdoclint:all,-missing/private` hence there is no simple way to skip private elements from doclint. Therefore we check javadoc using the Eclipse Java compiler (which is used by default) and javadoc configuration in `.settings/org.eclipse.jdt.core.prefs` files. This allows more fine grained configuration. We can reconsider this when javadoc starts supporting access specifiers in the doclint configuration. Below are detailled explanations for most modifications. @inheritDoc =========== doclint complains about explicits `{@inheritDoc}` when the parent does not have any documentation. As far as I can tell, javadoc defaults to inherit comments and should only be used when one wants to append extra documentation from the parent. Given the parent has no documentation, remove those usages which doclint complains about. In some case I have moved up the documentation from the concrete class up to the abstract class. Remove `{@inheritDoc}` on overriden methods which don't add additional documentation since javadoc defaults to inherit javadoc of overridden methods. @value to @link =============== In PackConfig, DEFAULT_SEARCH_FOR_REUSE_TIMEOUT and similar are forged from Integer.MAX_VALUE and are thus not considered constants (I guess cause the value would depends on the platform). Replace it with a link to `Integer.MAX_VALUE`. In `StringUtils.toBoolean`, @value was used to refer to the `stringValue` parameter. I have replaced it with `{@code stringValue}`. {@link <url>} to <a> ==================== @link does not support being given an external URL. Replaces them with HTML `<a>`. @since: being invalid ===================== org.eclipse.jgit/src/org/eclipse/jgit/util/Equality.java has an invalid tag `@since: ` due to the extra `:`. Javadoc does not complain about it with version 11.0.18+10 but does with 11.0.19.7. It is invalid regardless. invalid HTML syntax =================== - javadoc doesn't allow <br/>, <p/> and </p> anymore, use <br> and <p> instead - replace <tt>code</tt> by {@code code} - <table> tags don't allow summary attribute, specify caption as <caption>caption</caption> to fix this doclint visibility issue ======================== In the private abstract classes `BaseDirCacheEditor` and `BasePackConnection` links to other methods in the abstract class are inherited in the public subclasses but doclint gets confused and considers them unreachable. The HTML documentation for the sub classes shows the relative links in the sub classes, so it is all correct. It must be a bug somewhere in javadoc. Mute those warnings with: @SuppressWarnings("doclint:missing") Misc ==== Replace `<` and `>` with HTML encoded entities (`&lt; and `&gt;`). In `SshConstants` I went enclosing a serie of -> arrows in @literal. Additional tags =============== Configure maven-javad0c-plugin to allow the following additional tags defined in https://openjdk.org/jeps/8068562: - apiNote - implSpec - implNote Missing javadoc =============== Add missing @params and descriptions Change-Id: I840056389aa59135cfb360da0d5e40463ce35bd0 Also-By: Matthias Sohn <matthias.sohn@sap.com>
* KeyGrip: fix build error on java 15Matthias Sohn2021-09-291-2/+4
| | | | | | | | CryptlibObjectIdentifiers can't be used because bouncycastle doesn't export the package org.bouncycastle.asn1.cryptlib. Bug: 573638 Change-Id: I1f9e2af02d9fec69d2249a7d78301ba4b333a9ba
* [gpg] Better GPG home directory determinationThomas Wolf2021-08-182-15/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | GPG can use customized directories instead of the standard ~/.gnupg or %APPDATA%\gnupg directories: * Environment variable GNUPGHOME can define the location. * On Windows, a registry key may define the location (but this is deprecated). * Portable installations may use a directory defined via a file "gpgconf.ctl". * GPG programs may take a --homedir command-line argument, which overrides anything. Implement handling of environment variable GNUPGHOME. The other ways of GPG to get its home directory are outside the reach of JGit. Provide a system property "jgit.gpg.home" that the user can set in such cases. Do tilde replacement for the system property and for GNUPGHOME. Note that on VMS, the default directory would be ~/gnupg (without dot). This is not accounted for, but a user on VMS could now use either the system property or GNUPGHOME to direct JGit to the right directory. Bug: 575327 Change-Id: Id5ea04a85d58dba0c0df7a705777630d36042467 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* [gpg] Update to Bouncy Castle 1.69Thomas Wolf2021-07-261-1/+1
| | | | | | Bump lower bound in MANIFEST.MF and adapt code. Change-Id: I3a3c7948e5fc29f5517fe84209fcea81834e8e5b
* GPG: fix reading unprotected old-format secret keysThomas Wolf2021-02-221-6/+6
| | | | | | | | Fix code and add a test case. The old code passed on the original input stream, which has already been consumed. Bug: 570501 Change-Id: I81f60698ce42443df57e59b1d1ab155574136fa8 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* GPG: handle extended private key formatThomas Wolf2021-02-198-43/+1691
| | | | | | | | | | | | | | | | | | | | | | | | | Add detection for the key-value pair format that was available in gpg-agent for some time already and that has become the default since gpg-agent 2.2.20. If a secret key in the .gnupg/private-keys-v1.d directory is found to have this format, extract the human-readable key from it, convert it to the binary serialized form and hand that to BouncyCastle. Encrypted keys in the new format may use AES/OCB. OCB is a patent- encumbered algorithm; although there is a license for open-source software, that may not be good enough and OCB may not be available in Java. It is not available in the default security provider in Java, and it is also not available in the BouncyCastle version included in Eclipse. Implement AES/OCB decryption, throwing a PGPException with a nice message if the algorithm is not available. Include a copy of the normal s-expression parser of BouncyCastle and fix it to properly handle data from such keys: such keys do not contain an internal hash since the AES/OCB cipher includes and checks a MAC already. Bug: 570501 Change-Id: Ifa6391a809a84cfc6ae7c6610af6a79204b4143b Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* [GPG] Provide a factory for the BouncyCastleGpgSignerThomas Wolf2021-02-191-0/+34
| | | | | | | Otherwise client code has no way to ever create an instance without using internal non-API. Change-Id: I6201f98d4b1704a053159967b8adacd98e368522 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* GPG: compute the keygrip to find a secret keyThomas Wolf2021-02-163-58/+382
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The gpg-agent stores secret keys in individual files in the secret key directory private-keys-v1.d. The files have the key's keygrip (in upper case) as name and extension ".key". A keygrip is a SHA1 hash over the parameters of the public key. By computing this keygrip, we can pre-compute the expected file name and then check only that one file instead of having to iterate over all keys stored in that directory. This file naming scheme is actually an implementation detail of gpg-agent. It is unlikely to change, though. The keygrip itself is computed via libgcrypt and will remain stable according to the GPG main author.[1] Add an implementation for calculating the keygrip and include tests. Do not iterate over files in BouncyCastleGpgKeyLocator but only check the single file identified by the keygrip. Ideally upstream BouncyCastle would provide such a getKeyGrip() method. But as it re-builds GPG and libgcrypt internals, it's doubtful it would be included there, and since BouncyCastle even lacks a number of curve OIDs for ed25519/curve25519 and uses the short-Weierstrass parameters instead of the more common Montgomery parameters, including it there might be quite a bit of work. [1] http://gnupg.10057.n7.nabble.com/GnuPG-2-1-x-and-2-2-x-keyring-formats-tp54146p54154.html Bug: 547536 Change-Id: I30022a0e7b33b1bf35aec1222f84591f0c30ddfd Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* GPG signature verification via BouncyCastleThomas Wolf2021-02-165-22/+492
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a GpgSignatureVerifier interface, plus a factory to create instances thereof that is provided via the ServiceLoader mechanism. Implement the new interface for BouncyCastle. A verifier maintains an internal LRU cache of previously found public keys to speed up verifying multiple objects (tag or commits). Mergetags are not handled. Provide a new VerifySignatureCommand in org.eclipse.jgit.api together with a factory method Git.verifySignature(). The command can verify signatures on tags or commits, and can be limited to accept only tags or commits. Provide a new public WrongObjectTypeException thrown when the command is limited to either tags or commits and a name resolves to some other object kind. In jgit.pgm, implement "git tag -v", "git log --show-signature", and "git show --show-signature". The output is similar to command-line gpg invoked via git, but not identical. In particular, lines are not prefixed by "gpg:" but by "bc:". Trust levels for public keys are read from the keys' trust packets, not from GPG's internal trust database. A trust packet may or may not be set. Command-line GPG produces more warning lines depending on the trust level, warning about keys with a trust level below "full". There are no unit tests because JGit still doesn't have any setup to do signing unit tests; this would require at least a faked .gpg directory with pre-created key rings and keys, and a way to make the BouncyCastle classes use that directory instead of the default. See bug 547538 and also bug 544847. Tested manually with a small test repository containing signed and unsigned commits and tags, with signatures made with different keys and made by command-line git using GPG 2.2.25 and by JGit using BouncyCastle 1.65. Bug: 547751 Change-Id: If7e34aeed6ca6636a92bf774d893d98f6d459181 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* GPG: support git config gpg.programThomas Wolf2021-02-071-2/+34
| | | | | | | | | | | | | | Add it to the GpgConfig. Change GpgConfig to load the values once only. Add a parameter to the GpgObjectSigner interface's operations to pass in a GpgConfig. Update CommitCommand and TagCommand to pass the value to the signer. Let the signer decide whether it can actually produce the wanted signature type (openpgp or x509). No behavior change. But this makes it possible to implement different signers that might support x509 signatures, or use gpg.program and shell out to an external GPG executable for signing. Change-Id: I427f83eb1ece81c310e1cddd85315f6f88cc99ea Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* GPG user ID matching: use case-insensitive matchingThomas Wolf2020-12-291-4/+15
| | | | | | | | | | | | | Although not mentioned in the GPG documentation at [1], GPG uses case-insensitive matching also for the '<' (exact e-mail) and '@' (partial e-mail) operators. Matching for '=' (full exact match) is case-sensitive. Compare [2]. [1] https://www.gnupg.org/documentation/manuals/gnupg/Specify-a-User-ID.html [2] https://dev.gnupg.org/source/gnupg/browse/master/g10/keyring.c;22f7dddc34446a8c3e9eddf6cb281f16802351d7$890 Bug: 547789 Change-Id: I2f5ab65807d5dde3aa00ff032894701bbd8418c9 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* Enable GpgSigner to also sign tagsThomas Wolf2020-12-071-3/+13
| | | | | | | | | | | | | | Factor out a common ObjectBuilder as super class of CommitBuilder and TagBuilder, and make the GpgSigner work on ObjectBuilder. In order not to break API, add the new method for signing an ObjectBuilder in a new interface GpgObjectSigner. The signature for a tag is just tacked onto the end of the tag message. The message of a signed tag must end in LF. Bug: 386908 Change-Id: I5e021e3c927f4051825cd7355b129113b949455e Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* GPG: include signer's user ID in the signatureThomas Wolf2020-09-051-5/+34
| | | | | | | | | | | Signing a commit with command line git and gpg 2.2.20 includes the e-mail part of the key's user ID as a "Signer's User ID" subpacket on the signature. Implement this for signing via Bouncy Castle. Bug: 564386 Change-Id: I68906b895349359596cf3451d65f2840c60df856 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* GPG: don't prompt for a passphrase for unprotected keysThomas Wolf2020-06-043-23/+80
| | | | | | | | | | | | | | | | | | | | BouncyCastle supports reading GPG keys without passphrase since 1.62. Handle this in JGit, too, and don't prompt for a passphrase unless it's necessary. Make two passes over the private key files, a first pass without passphrase provider. If that succeeds it has managed to read a matching key without passphrase. Otherwise, ask the user for the passphrase and make a second pass over the key files. BouncyCastle 1.65 still has no method to get the GPG "key grip" from a given public key, so JGit still cannot determine the correct file to read up front. (The file name is the key grip as 40 hex digits, upper case, with extension ".key"). Bug: 548763 Change-Id: I448181276548c08716d913c7ba1b4bc64c62f952 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* Decouple BouncyCastle from JGit CoreMatthias Sohn2020-06-015-0/+921
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>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-05 12:31:33 +0000