| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Signature verification needs quite a bit of infrastructure. There are
two files to read: a list of allowed signers, and a list of revoked keys
or certificates. Introduce a SigningKeyDatabase abstraction for these,
and give client code the possibility to plug in its own implementation.
Loading these files afresh for every signature to be checked would be
prohibitively expensive. Introduce a cache of SigningKeyDatabases, and
have them reload the files only when they have changed.
Include a default implementation that works with the OpenSSH allowed
signers file and with OpenSSH revocation lists. Binary KRLs are parsed
according to [1]; the test data was generated using the OpenSSH test
script[2].
[1] https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.krl
[2] https://github.com/openssh/openssh-portable/blob/67a115e/regress/krl.sh
Bug: jgit-44
Change-Id: I6a2fa24f38a2f2fe63ffb353da5b6665ca7277e1
Signed-off-by: Thomas Wolf <twolf@apache.org>
|
|
|
Implement a Signer and its factory, and publish the factory for the
ServiceLoader. SSH signatures can be created directly if the key is
given via a file in user.signingKey and the private key can be found.
Otherwise, signing is delegated to an SSH agent, if available.
If a certificate is used as public key, the signer verifies the
certificate (correct signature, and valid at the commit time).
SSH signatures are documented at [1].
[1] https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.sshsig
Bug: jgit-44
Change-Id: I3848ccc06ba3be5e868f879bd5705fee1b39c632
Signed-off-by: Thomas Wolf <twolf@apache.org>
|
