mirrors
/
jgit
mirror of https://github.com/eclipse/jgit.git
Watch 1
Star 0
Fork 0
Code Issues 0 Releases 204 Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
8241 Commits
49 Branches
Tree: 1b7eafab13
Branches Tags
${ item.name }
Create branch ${ searchTerm }
from '1b7eafab13'
${ noResults }
jgit/org.eclipse.jgit.gpg.bc/resources/org/eclipse/jgit/gpg/bc/internal/BCText.properties

BCText.properties 2.3KB
Raw Normal View History

GPG: compute the keygrip to find a secret key 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>
3 years ago
Decouple BouncyCastle from JGit Core 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>
4 years ago
GPG: handle extended private key format 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>
3 years ago
​
GPG: compute the keygrip to find a secret key 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>
3 years ago
Decouple BouncyCastle from JGit Core 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>
4 years ago
GPG: compute the keygrip to find a secret key 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>
3 years ago
Decouple BouncyCastle from JGit Core 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>
4 years ago
​
​
​
GPG: handle extended private key format 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>
3 years ago
Decouple BouncyCastle from JGit Core 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>
4 years ago
​
​
GPG signature verification via BouncyCastle 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>
3 years ago
GPG: handle extended private key format 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>
3 years ago
​
​
​
​
​
​
​
​
GPG signature verification via BouncyCastle 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>
3 years ago
​
​
​
​
​
Decouple BouncyCastle from JGit Core 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>
4 years ago
GPG: compute the keygrip to find a secret key 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>
3 years ago
​
​
​
 123456789101112131415161718192021222324252627282930313233343536 
  1. corrupt25519Key=Ed25519/Curve25519 public key has wrong length: {0}

  2. credentialPassphrase=Passphrase

  3. cryptCipherError=Cannot create cipher to decrypt: {0}

  4. cryptWrongDecryptedLength=Decrypted key has wrong length; expected {0} bytes, got only {1} bytes

  5. gpgFailedToParseSecretKey=Failed to parse secret key file {0}. Is the entered passphrase correct?

  6. gpgNoCredentialsProvider=missing credentials provider

  7. gpgNoKeygrip=Cannot find key {0}: cannot determine key grip

  8. gpgNoKeyring=neither pubring.kbx nor secring.gpg files found

  9. gpgNoKeyInLegacySecring=no matching secret key found in legacy secring.gpg for key or user id: {0}

  10. gpgNoPublicKeyFound=Unable to find a public-key with key or user id: {0}

  11. gpgNoSecretKeyForPublicKey=unable to find associated secret key for public key: {0}

  12. gpgNoSuchAlgorithm=Cannot decrypt encrypted secret key: encryption algorithm {0} is not available

  13. gpgNotASigningKey=Secret key ({0}) is not suitable for signing

  14. gpgKeyInfo=GPG Key (fingerprint {0})

  15. gpgSigningCancelled=Signing was cancelled

  16. nonSignatureError=Signature does not decode into a signature object

  17. secretKeyTooShort=Secret key file corrupt; only {0} bytes read

  18. sexprHexNotClosed=Hex number in s-expression not closed

  19. sexprHexOdd=Hex number in s-expression has an odd number of digits

  20. sexprStringInvalidEscape=Invalid escape {0} in s-expression

  21. sexprStringInvalidEscapeAtEnd=Invalid s-expression: quoted string ends with escape character

  22. sexprStringInvalidHexEscape=Invalid hex escape in s-expression

  23. sexprStringInvalidOctalEscape=Invalid octal escape in s-expression

  24. sexprStringNotClosed=String in s-expression not closed

  25. sexprUnhandled=Unhandled token {0} in s-expression

  26. signatureInconsistent=Inconsistent signature; key ID {0} does not match issuer fingerprint {1}

  27. signatureKeyLookupError=Error occurred while looking for public key

  28. signatureNoKeyInfo=No way to determine a public key from the signature

  29. signatureNoPublicKey=No public key found to verify the signature

  30. signatureParseError=Signature cannot be parsed

  31. signatureVerificationError=Signature verification failed

  32. unableToSignCommitNoSecretKey=Unable to sign commit. Signing key not available.

  33. uncompressed25519Key=Cannot handle ed25519 public key with uncompressed data: {0}

  34. unknownCurve=Unknown curve {0}

  35. unknownCurveParameters=Curve {0} does not have a prime field

  36. unknownKeyType=Unknown key type {0}