2023-03-21 06:26:02 +00:00
|
|
|
#include "git-compat-util.h"
|
2021-02-11 02:08:06 +00:00
|
|
|
#include "commit.h"
|
2017-06-14 18:07:36 +00:00
|
|
|
#include "config.h"
|
2023-04-22 20:17:26 +00:00
|
|
|
#include "date.h"
|
2023-03-21 06:25:54 +00:00
|
|
|
#include "gettext.h"
|
2011-09-08 04:19:47 +00:00
|
|
|
#include "run-command.h"
|
|
|
|
#include "strbuf.h"
|
2021-09-10 20:07:39 +00:00
|
|
|
#include "dir.h"
|
2023-02-24 00:09:29 +00:00
|
|
|
#include "ident.h"
|
2011-09-08 04:19:47 +00:00
|
|
|
#include "gpg-interface.h"
|
2023-04-22 20:17:20 +00:00
|
|
|
#include "path.h"
|
2011-09-08 04:19:47 +00:00
|
|
|
#include "sigchain.h"
|
2016-06-17 23:38:43 +00:00
|
|
|
#include "tempfile.h"
|
2021-09-10 20:07:37 +00:00
|
|
|
#include "alias.h"
|
2011-09-08 04:19:47 +00:00
|
|
|
|
config: add ctx arg to config_fn_t
Add a new "const struct config_context *ctx" arg to config_fn_t to hold
additional information about the config iteration operation.
config_context has a "struct key_value_info kvi" member that holds
metadata about the config source being read (e.g. what kind of config
source it is, the filename, etc). In this series, we're only interested
in .kvi, so we could have just used "struct key_value_info" as an arg,
but config_context makes it possible to add/adjust members in the future
without changing the config_fn_t signature. We could also consider other
ways of organizing the args (e.g. moving the config name and value into
config_context or key_value_info), but in my experiments, the
incremental benefit doesn't justify the added complexity (e.g. a
config_fn_t will sometimes invoke another config_fn_t but with a
different config value).
In subsequent commits, the .kvi member will replace the global "struct
config_reader" in config.c, making config iteration a global-free
operation. It requires much more work for the machinery to provide
meaningful values of .kvi, so for now, merely change the signature and
call sites, pass NULL as a placeholder value, and don't rely on the arg
in any meaningful way.
Most of the changes are performed by
contrib/coccinelle/config_fn_ctx.pending.cocci, which, for every
config_fn_t:
- Modifies the signature to accept "const struct config_context *ctx"
- Passes "ctx" to any inner config_fn_t, if needed
- Adds UNUSED attributes to "ctx", if needed
Most config_fn_t instances are easily identified by seeing if they are
called by the various config functions. Most of the remaining ones are
manually named in the .cocci patch. Manual cleanups are still needed,
but the majority of it is trivial; it's either adjusting config_fn_t
that the .cocci patch didn't catch, or adding forward declarations of
"struct config_context ctx" to make the signatures make sense.
The non-trivial changes are in cases where we are invoking a config_fn_t
outside of config machinery, and we now need to decide what value of
"ctx" to pass. These cases are:
- trace2/tr2_cfg.c:tr2_cfg_set_fl()
This is indirectly called by git_config_set() so that the trace2
machinery can notice the new config values and update its settings
using the tr2 config parsing function, i.e. tr2_cfg_cb().
- builtin/checkout.c:checkout_main()
This calls git_xmerge_config() as a shorthand for parsing a CLI arg.
This might be worth refactoring away in the future, since
git_xmerge_config() can call git_default_config(), which can do much
more than just parsing.
Handle them by creating a KVI_INIT macro that initializes "struct
key_value_info" to a reasonable default, and use that to construct the
"ctx" arg.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-28 19:26:22 +00:00
|
|
|
static int git_gpg_config(const char *, const char *,
|
|
|
|
const struct config_context *, void *);
|
2023-02-09 20:24:14 +00:00
|
|
|
|
|
|
|
static void gpg_interface_lazy_init(void)
|
|
|
|
{
|
|
|
|
static int done;
|
|
|
|
|
|
|
|
if (done)
|
|
|
|
return;
|
|
|
|
done = 1;
|
|
|
|
git_config(git_gpg_config, NULL);
|
|
|
|
}
|
|
|
|
|
2011-09-08 04:19:47 +00:00
|
|
|
static char *configured_signing_key;
|
2021-09-10 20:07:39 +00:00
|
|
|
static const char *ssh_default_key_command, *ssh_allowed_signers, *ssh_revocation_file;
|
gpg-interface: add minTrustLevel as a configuration option
Previously, signature verification for merge and pull operations checked
if the key had a trust-level of either TRUST_NEVER or TRUST_UNDEFINED in
verify_merge_signature(). If that was the case, the process die()d.
The other code paths that did signature verification relied entirely on
the return code from check_commit_signature(). And signatures made with
a good key, irregardless of its trust level, was considered valid by
check_commit_signature().
This difference in behavior might induce users to erroneously assume
that the trust level of a key in their keyring is always considered by
Git, even for operations where it is not (e.g. during a verify-commit or
verify-tag).
The way it worked was by gpg-interface.c storing the result from the
key/signature status *and* the lowest-two trust levels in the `result`
member of the signature_check structure (the last of these status lines
that were encountered got written to `result`). These are documented in
GPG under the subsection `General status codes` and `Key related`,
respectively [1].
The GPG documentation says the following on the TRUST_ status codes [1]:
"""
These are several similar status codes:
- TRUST_UNDEFINED <error_token>
- TRUST_NEVER <error_token>
- TRUST_MARGINAL [0 [<validation_model>]]
- TRUST_FULLY [0 [<validation_model>]]
- TRUST_ULTIMATE [0 [<validation_model>]]
For good signatures one of these status lines are emitted to
indicate the validity of the key used to create the signature.
The error token values are currently only emitted by gpgsm.
"""
My interpretation is that the trust level is conceptionally different
from the validity of the key and/or signature. That seems to also have
been the assumption of the old code in check_signature() where a result
of 'G' (as in GOODSIG) and 'U' (as in TRUST_NEVER or TRUST_UNDEFINED)
were both considered a success.
The two cases where a result of 'U' had special meaning were in
verify_merge_signature() (where this caused git to die()) and in
format_commit_one() (where it affected the output of the %G? format
specifier).
I think it makes sense to refactor the processing of TRUST_ status lines
such that users can configure a minimum trust level that is enforced
globally, rather than have individual parts of git (e.g. merge) do it
themselves (except for a grace period with backward compatibility).
I also think it makes sense to not store the trust level in the same
struct member as the key/signature status. While the presence of a
TRUST_ status code does imply that the signature is good (see the first
paragraph in the included snippet above), as far as I can tell, the
order of the status lines from GPG isn't well-defined; thus it would
seem plausible that the trust level could be overwritten with the
key/signature status if they were stored in the same member of the
signature_check structure.
This patch introduces a new configuration option: gpg.minTrustLevel. It
consolidates trust-level verification to gpg-interface.c and adds a new
`trust_level` member to the signature_check structure.
Backward-compatibility is maintained by introducing a special case in
verify_merge_signature() such that if no user-configurable
gpg.minTrustLevel is set, then the old behavior of rejecting
TRUST_UNDEFINED and TRUST_NEVER is enforced. If, on the other hand,
gpg.minTrustLevel is set, then that value overrides the old behavior.
Similarly, the %G? format specifier will continue show 'U' for
signatures made with a key that has a trust level of TRUST_UNDEFINED or
TRUST_NEVER, even though the 'U' character no longer exist in the
`result` member of the signature_check structure. A new format
specifier, %GT, is also introduced for users that want to show all
possible trust levels for a signature.
Another approach would have been to simply drop the trust-level
requirement in verify_merge_signature(). This would also have made the
behavior consistent with other parts of git that perform signature
verification. However, requiring a minimum trust level for signing keys
does seem to have a real-world use-case. For example, the build system
used by the Qubes OS project currently parses the raw output from
verify-tag in order to assert a minimum trust level for keys used to
sign git tags [2].
[1] https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/doc/DETAILS;h=bd00006e933ac56719b1edd2478ecd79273eae72;hb=refs/heads/master
[2] https://github.com/QubesOS/qubes-builder/blob/9674c1991deef45b1a1b1c71fddfab14ba50dccf/scripts/verify-git-tag#L43
Signed-off-by: Hans Jerry Illikainen <hji@dyntopia.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-27 13:55:57 +00:00
|
|
|
static enum signature_trust_level configured_min_trust_level = TRUST_UNDEFINED;
|
|
|
|
|
2018-07-17 12:50:09 +00:00
|
|
|
struct gpg_format {
|
|
|
|
const char *name;
|
|
|
|
const char *program;
|
|
|
|
const char **verify_args;
|
|
|
|
const char **sigs;
|
2021-09-10 20:07:34 +00:00
|
|
|
int (*verify_signed_buffer)(struct signature_check *sigc,
|
2021-12-09 08:52:43 +00:00
|
|
|
struct gpg_format *fmt,
|
|
|
|
const char *signature,
|
2021-09-10 20:07:34 +00:00
|
|
|
size_t signature_size);
|
|
|
|
int (*sign_buffer)(struct strbuf *buffer, struct strbuf *signature,
|
|
|
|
const char *signing_key);
|
2021-09-10 20:07:37 +00:00
|
|
|
const char *(*get_default_key)(void);
|
2021-09-10 20:07:38 +00:00
|
|
|
const char *(*get_key_id)(void);
|
2018-07-17 12:50:09 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static const char *openpgp_verify_args[] = {
|
|
|
|
"--keyid-format=long",
|
|
|
|
NULL
|
|
|
|
};
|
|
|
|
static const char *openpgp_sigs[] = {
|
|
|
|
"-----BEGIN PGP SIGNATURE-----",
|
|
|
|
"-----BEGIN PGP MESSAGE-----",
|
|
|
|
NULL
|
|
|
|
};
|
|
|
|
|
2018-07-17 12:50:12 +00:00
|
|
|
static const char *x509_verify_args[] = {
|
|
|
|
NULL
|
|
|
|
};
|
|
|
|
static const char *x509_sigs[] = {
|
|
|
|
"-----BEGIN SIGNED MESSAGE-----",
|
|
|
|
NULL
|
|
|
|
};
|
|
|
|
|
2021-09-10 20:07:36 +00:00
|
|
|
static const char *ssh_verify_args[] = { NULL };
|
|
|
|
static const char *ssh_sigs[] = {
|
|
|
|
"-----BEGIN SSH SIGNATURE-----",
|
|
|
|
NULL
|
|
|
|
};
|
|
|
|
|
2021-09-10 20:07:34 +00:00
|
|
|
static int verify_gpg_signed_buffer(struct signature_check *sigc,
|
2021-12-09 08:52:43 +00:00
|
|
|
struct gpg_format *fmt,
|
|
|
|
const char *signature,
|
2021-09-10 20:07:34 +00:00
|
|
|
size_t signature_size);
|
2021-09-10 20:07:39 +00:00
|
|
|
static int verify_ssh_signed_buffer(struct signature_check *sigc,
|
2021-12-09 08:52:43 +00:00
|
|
|
struct gpg_format *fmt,
|
|
|
|
const char *signature,
|
2021-09-10 20:07:39 +00:00
|
|
|
size_t signature_size);
|
2021-09-10 20:07:34 +00:00
|
|
|
static int sign_buffer_gpg(struct strbuf *buffer, struct strbuf *signature,
|
|
|
|
const char *signing_key);
|
2021-09-10 20:07:36 +00:00
|
|
|
static int sign_buffer_ssh(struct strbuf *buffer, struct strbuf *signature,
|
|
|
|
const char *signing_key);
|
2021-09-10 20:07:34 +00:00
|
|
|
|
2021-09-10 20:07:37 +00:00
|
|
|
static const char *get_default_ssh_signing_key(void);
|
|
|
|
|
2021-09-10 20:07:38 +00:00
|
|
|
static const char *get_ssh_key_id(void);
|
|
|
|
|
2018-07-17 12:50:09 +00:00
|
|
|
static struct gpg_format gpg_format[] = {
|
2021-09-10 20:07:34 +00:00
|
|
|
{
|
|
|
|
.name = "openpgp",
|
|
|
|
.program = "gpg",
|
|
|
|
.verify_args = openpgp_verify_args,
|
|
|
|
.sigs = openpgp_sigs,
|
|
|
|
.verify_signed_buffer = verify_gpg_signed_buffer,
|
|
|
|
.sign_buffer = sign_buffer_gpg,
|
2021-09-10 20:07:37 +00:00
|
|
|
.get_default_key = NULL,
|
2021-09-10 20:07:38 +00:00
|
|
|
.get_key_id = NULL,
|
2018-07-17 12:50:09 +00:00
|
|
|
},
|
2021-09-10 20:07:34 +00:00
|
|
|
{
|
|
|
|
.name = "x509",
|
|
|
|
.program = "gpgsm",
|
|
|
|
.verify_args = x509_verify_args,
|
|
|
|
.sigs = x509_sigs,
|
|
|
|
.verify_signed_buffer = verify_gpg_signed_buffer,
|
|
|
|
.sign_buffer = sign_buffer_gpg,
|
2021-09-10 20:07:37 +00:00
|
|
|
.get_default_key = NULL,
|
2021-09-10 20:07:38 +00:00
|
|
|
.get_key_id = NULL,
|
2018-07-17 12:50:12 +00:00
|
|
|
},
|
2021-09-10 20:07:36 +00:00
|
|
|
{
|
|
|
|
.name = "ssh",
|
|
|
|
.program = "ssh-keygen",
|
|
|
|
.verify_args = ssh_verify_args,
|
|
|
|
.sigs = ssh_sigs,
|
2021-09-10 20:07:39 +00:00
|
|
|
.verify_signed_buffer = verify_ssh_signed_buffer,
|
2021-09-10 20:07:37 +00:00
|
|
|
.sign_buffer = sign_buffer_ssh,
|
|
|
|
.get_default_key = get_default_ssh_signing_key,
|
2021-09-10 20:07:38 +00:00
|
|
|
.get_key_id = get_ssh_key_id,
|
2021-09-10 20:07:36 +00:00
|
|
|
},
|
2018-07-17 12:50:09 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static struct gpg_format *use_format = &gpg_format[0];
|
2011-09-08 04:19:47 +00:00
|
|
|
|
2018-07-17 12:50:09 +00:00
|
|
|
static struct gpg_format *get_format_by_name(const char *str)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(gpg_format); i++)
|
|
|
|
if (!strcmp(gpg_format[i].name, str))
|
|
|
|
return gpg_format + i;
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct gpg_format *get_format_by_sig(const char *sig)
|
|
|
|
{
|
|
|
|
int i, j;
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(gpg_format); i++)
|
|
|
|
for (j = 0; gpg_format[i].sigs[j]; j++)
|
|
|
|
if (starts_with(sig, gpg_format[i].sigs[j]))
|
|
|
|
return gpg_format + i;
|
|
|
|
return NULL;
|
|
|
|
}
|
2014-08-19 20:18:07 +00:00
|
|
|
|
2014-06-23 07:05:47 +00:00
|
|
|
void signature_check_clear(struct signature_check *sigc)
|
|
|
|
{
|
2017-06-15 23:15:49 +00:00
|
|
|
FREE_AND_NULL(sigc->payload);
|
2021-09-10 20:07:34 +00:00
|
|
|
FREE_AND_NULL(sigc->output);
|
2017-06-15 23:15:49 +00:00
|
|
|
FREE_AND_NULL(sigc->gpg_status);
|
|
|
|
FREE_AND_NULL(sigc->signer);
|
|
|
|
FREE_AND_NULL(sigc->key);
|
2018-10-22 16:38:20 +00:00
|
|
|
FREE_AND_NULL(sigc->fingerprint);
|
2018-10-22 16:38:21 +00:00
|
|
|
FREE_AND_NULL(sigc->primary_key_fingerprint);
|
2014-06-23 07:05:47 +00:00
|
|
|
}
|
|
|
|
|
2018-10-20 19:30:20 +00:00
|
|
|
/* An exclusive status -- only one of them can appear in output */
|
|
|
|
#define GPG_STATUS_EXCLUSIVE (1<<0)
|
2018-10-22 16:38:19 +00:00
|
|
|
/* The status includes key identifier */
|
|
|
|
#define GPG_STATUS_KEYID (1<<1)
|
|
|
|
/* The status includes user identifier */
|
|
|
|
#define GPG_STATUS_UID (1<<2)
|
2018-10-22 16:38:20 +00:00
|
|
|
/* The status includes key fingerprints */
|
|
|
|
#define GPG_STATUS_FINGERPRINT (1<<3)
|
gpg-interface: add minTrustLevel as a configuration option
Previously, signature verification for merge and pull operations checked
if the key had a trust-level of either TRUST_NEVER or TRUST_UNDEFINED in
verify_merge_signature(). If that was the case, the process die()d.
The other code paths that did signature verification relied entirely on
the return code from check_commit_signature(). And signatures made with
a good key, irregardless of its trust level, was considered valid by
check_commit_signature().
This difference in behavior might induce users to erroneously assume
that the trust level of a key in their keyring is always considered by
Git, even for operations where it is not (e.g. during a verify-commit or
verify-tag).
The way it worked was by gpg-interface.c storing the result from the
key/signature status *and* the lowest-two trust levels in the `result`
member of the signature_check structure (the last of these status lines
that were encountered got written to `result`). These are documented in
GPG under the subsection `General status codes` and `Key related`,
respectively [1].
The GPG documentation says the following on the TRUST_ status codes [1]:
"""
These are several similar status codes:
- TRUST_UNDEFINED <error_token>
- TRUST_NEVER <error_token>
- TRUST_MARGINAL [0 [<validation_model>]]
- TRUST_FULLY [0 [<validation_model>]]
- TRUST_ULTIMATE [0 [<validation_model>]]
For good signatures one of these status lines are emitted to
indicate the validity of the key used to create the signature.
The error token values are currently only emitted by gpgsm.
"""
My interpretation is that the trust level is conceptionally different
from the validity of the key and/or signature. That seems to also have
been the assumption of the old code in check_signature() where a result
of 'G' (as in GOODSIG) and 'U' (as in TRUST_NEVER or TRUST_UNDEFINED)
were both considered a success.
The two cases where a result of 'U' had special meaning were in
verify_merge_signature() (where this caused git to die()) and in
format_commit_one() (where it affected the output of the %G? format
specifier).
I think it makes sense to refactor the processing of TRUST_ status lines
such that users can configure a minimum trust level that is enforced
globally, rather than have individual parts of git (e.g. merge) do it
themselves (except for a grace period with backward compatibility).
I also think it makes sense to not store the trust level in the same
struct member as the key/signature status. While the presence of a
TRUST_ status code does imply that the signature is good (see the first
paragraph in the included snippet above), as far as I can tell, the
order of the status lines from GPG isn't well-defined; thus it would
seem plausible that the trust level could be overwritten with the
key/signature status if they were stored in the same member of the
signature_check structure.
This patch introduces a new configuration option: gpg.minTrustLevel. It
consolidates trust-level verification to gpg-interface.c and adds a new
`trust_level` member to the signature_check structure.
Backward-compatibility is maintained by introducing a special case in
verify_merge_signature() such that if no user-configurable
gpg.minTrustLevel is set, then the old behavior of rejecting
TRUST_UNDEFINED and TRUST_NEVER is enforced. If, on the other hand,
gpg.minTrustLevel is set, then that value overrides the old behavior.
Similarly, the %G? format specifier will continue show 'U' for
signatures made with a key that has a trust level of TRUST_UNDEFINED or
TRUST_NEVER, even though the 'U' character no longer exist in the
`result` member of the signature_check structure. A new format
specifier, %GT, is also introduced for users that want to show all
possible trust levels for a signature.
Another approach would have been to simply drop the trust-level
requirement in verify_merge_signature(). This would also have made the
behavior consistent with other parts of git that perform signature
verification. However, requiring a minimum trust level for signing keys
does seem to have a real-world use-case. For example, the build system
used by the Qubes OS project currently parses the raw output from
verify-tag in order to assert a minimum trust level for keys used to
sign git tags [2].
[1] https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/doc/DETAILS;h=bd00006e933ac56719b1edd2478ecd79273eae72;hb=refs/heads/master
[2] https://github.com/QubesOS/qubes-builder/blob/9674c1991deef45b1a1b1c71fddfab14ba50dccf/scripts/verify-git-tag#L43
Signed-off-by: Hans Jerry Illikainen <hji@dyntopia.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-27 13:55:57 +00:00
|
|
|
/* The status includes trust level */
|
|
|
|
#define GPG_STATUS_TRUST_LEVEL (1<<4)
|
2018-10-22 16:38:19 +00:00
|
|
|
|
|
|
|
/* Short-hand for standard exclusive *SIG status with keyid & UID */
|
|
|
|
#define GPG_STATUS_STDSIG (GPG_STATUS_EXCLUSIVE|GPG_STATUS_KEYID|GPG_STATUS_UID)
|
2018-10-20 19:30:20 +00:00
|
|
|
|
2014-08-14 22:31:13 +00:00
|
|
|
static struct {
|
|
|
|
char result;
|
|
|
|
const char *check;
|
2018-10-20 19:30:20 +00:00
|
|
|
unsigned int flags;
|
2014-08-14 22:31:13 +00:00
|
|
|
} sigcheck_gpg_status[] = {
|
2018-10-22 16:38:19 +00:00
|
|
|
{ 'G', "GOODSIG ", GPG_STATUS_STDSIG },
|
|
|
|
{ 'B', "BADSIG ", GPG_STATUS_STDSIG },
|
|
|
|
{ 'E', "ERRSIG ", GPG_STATUS_EXCLUSIVE|GPG_STATUS_KEYID },
|
|
|
|
{ 'X', "EXPSIG ", GPG_STATUS_STDSIG },
|
|
|
|
{ 'Y', "EXPKEYSIG ", GPG_STATUS_STDSIG },
|
|
|
|
{ 'R', "REVKEYSIG ", GPG_STATUS_STDSIG },
|
2018-10-22 16:38:20 +00:00
|
|
|
{ 0, "VALIDSIG ", GPG_STATUS_FINGERPRINT },
|
gpg-interface: add minTrustLevel as a configuration option
Previously, signature verification for merge and pull operations checked
if the key had a trust-level of either TRUST_NEVER or TRUST_UNDEFINED in
verify_merge_signature(). If that was the case, the process die()d.
The other code paths that did signature verification relied entirely on
the return code from check_commit_signature(). And signatures made with
a good key, irregardless of its trust level, was considered valid by
check_commit_signature().
This difference in behavior might induce users to erroneously assume
that the trust level of a key in their keyring is always considered by
Git, even for operations where it is not (e.g. during a verify-commit or
verify-tag).
The way it worked was by gpg-interface.c storing the result from the
key/signature status *and* the lowest-two trust levels in the `result`
member of the signature_check structure (the last of these status lines
that were encountered got written to `result`). These are documented in
GPG under the subsection `General status codes` and `Key related`,
respectively [1].
The GPG documentation says the following on the TRUST_ status codes [1]:
"""
These are several similar status codes:
- TRUST_UNDEFINED <error_token>
- TRUST_NEVER <error_token>
- TRUST_MARGINAL [0 [<validation_model>]]
- TRUST_FULLY [0 [<validation_model>]]
- TRUST_ULTIMATE [0 [<validation_model>]]
For good signatures one of these status lines are emitted to
indicate the validity of the key used to create the signature.
The error token values are currently only emitted by gpgsm.
"""
My interpretation is that the trust level is conceptionally different
from the validity of the key and/or signature. That seems to also have
been the assumption of the old code in check_signature() where a result
of 'G' (as in GOODSIG) and 'U' (as in TRUST_NEVER or TRUST_UNDEFINED)
were both considered a success.
The two cases where a result of 'U' had special meaning were in
verify_merge_signature() (where this caused git to die()) and in
format_commit_one() (where it affected the output of the %G? format
specifier).
I think it makes sense to refactor the processing of TRUST_ status lines
such that users can configure a minimum trust level that is enforced
globally, rather than have individual parts of git (e.g. merge) do it
themselves (except for a grace period with backward compatibility).
I also think it makes sense to not store the trust level in the same
struct member as the key/signature status. While the presence of a
TRUST_ status code does imply that the signature is good (see the first
paragraph in the included snippet above), as far as I can tell, the
order of the status lines from GPG isn't well-defined; thus it would
seem plausible that the trust level could be overwritten with the
key/signature status if they were stored in the same member of the
signature_check structure.
This patch introduces a new configuration option: gpg.minTrustLevel. It
consolidates trust-level verification to gpg-interface.c and adds a new
`trust_level` member to the signature_check structure.
Backward-compatibility is maintained by introducing a special case in
verify_merge_signature() such that if no user-configurable
gpg.minTrustLevel is set, then the old behavior of rejecting
TRUST_UNDEFINED and TRUST_NEVER is enforced. If, on the other hand,
gpg.minTrustLevel is set, then that value overrides the old behavior.
Similarly, the %G? format specifier will continue show 'U' for
signatures made with a key that has a trust level of TRUST_UNDEFINED or
TRUST_NEVER, even though the 'U' character no longer exist in the
`result` member of the signature_check structure. A new format
specifier, %GT, is also introduced for users that want to show all
possible trust levels for a signature.
Another approach would have been to simply drop the trust-level
requirement in verify_merge_signature(). This would also have made the
behavior consistent with other parts of git that perform signature
verification. However, requiring a minimum trust level for signing keys
does seem to have a real-world use-case. For example, the build system
used by the Qubes OS project currently parses the raw output from
verify-tag in order to assert a minimum trust level for keys used to
sign git tags [2].
[1] https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/doc/DETAILS;h=bd00006e933ac56719b1edd2478ecd79273eae72;hb=refs/heads/master
[2] https://github.com/QubesOS/qubes-builder/blob/9674c1991deef45b1a1b1c71fddfab14ba50dccf/scripts/verify-git-tag#L43
Signed-off-by: Hans Jerry Illikainen <hji@dyntopia.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-27 13:55:57 +00:00
|
|
|
{ 0, "TRUST_", GPG_STATUS_TRUST_LEVEL },
|
|
|
|
};
|
|
|
|
|
2022-07-11 05:00:50 +00:00
|
|
|
/* Keep the order same as enum signature_trust_level */
|
|
|
|
static struct sigcheck_gpg_trust_level {
|
gpg-interface: add minTrustLevel as a configuration option
Previously, signature verification for merge and pull operations checked
if the key had a trust-level of either TRUST_NEVER or TRUST_UNDEFINED in
verify_merge_signature(). If that was the case, the process die()d.
The other code paths that did signature verification relied entirely on
the return code from check_commit_signature(). And signatures made with
a good key, irregardless of its trust level, was considered valid by
check_commit_signature().
This difference in behavior might induce users to erroneously assume
that the trust level of a key in their keyring is always considered by
Git, even for operations where it is not (e.g. during a verify-commit or
verify-tag).
The way it worked was by gpg-interface.c storing the result from the
key/signature status *and* the lowest-two trust levels in the `result`
member of the signature_check structure (the last of these status lines
that were encountered got written to `result`). These are documented in
GPG under the subsection `General status codes` and `Key related`,
respectively [1].
The GPG documentation says the following on the TRUST_ status codes [1]:
"""
These are several similar status codes:
- TRUST_UNDEFINED <error_token>
- TRUST_NEVER <error_token>
- TRUST_MARGINAL [0 [<validation_model>]]
- TRUST_FULLY [0 [<validation_model>]]
- TRUST_ULTIMATE [0 [<validation_model>]]
For good signatures one of these status lines are emitted to
indicate the validity of the key used to create the signature.
The error token values are currently only emitted by gpgsm.
"""
My interpretation is that the trust level is conceptionally different
from the validity of the key and/or signature. That seems to also have
been the assumption of the old code in check_signature() where a result
of 'G' (as in GOODSIG) and 'U' (as in TRUST_NEVER or TRUST_UNDEFINED)
were both considered a success.
The two cases where a result of 'U' had special meaning were in
verify_merge_signature() (where this caused git to die()) and in
format_commit_one() (where it affected the output of the %G? format
specifier).
I think it makes sense to refactor the processing of TRUST_ status lines
such that users can configure a minimum trust level that is enforced
globally, rather than have individual parts of git (e.g. merge) do it
themselves (except for a grace period with backward compatibility).
I also think it makes sense to not store the trust level in the same
struct member as the key/signature status. While the presence of a
TRUST_ status code does imply that the signature is good (see the first
paragraph in the included snippet above), as far as I can tell, the
order of the status lines from GPG isn't well-defined; thus it would
seem plausible that the trust level could be overwritten with the
key/signature status if they were stored in the same member of the
signature_check structure.
This patch introduces a new configuration option: gpg.minTrustLevel. It
consolidates trust-level verification to gpg-interface.c and adds a new
`trust_level` member to the signature_check structure.
Backward-compatibility is maintained by introducing a special case in
verify_merge_signature() such that if no user-configurable
gpg.minTrustLevel is set, then the old behavior of rejecting
TRUST_UNDEFINED and TRUST_NEVER is enforced. If, on the other hand,
gpg.minTrustLevel is set, then that value overrides the old behavior.
Similarly, the %G? format specifier will continue show 'U' for
signatures made with a key that has a trust level of TRUST_UNDEFINED or
TRUST_NEVER, even though the 'U' character no longer exist in the
`result` member of the signature_check structure. A new format
specifier, %GT, is also introduced for users that want to show all
possible trust levels for a signature.
Another approach would have been to simply drop the trust-level
requirement in verify_merge_signature(). This would also have made the
behavior consistent with other parts of git that perform signature
verification. However, requiring a minimum trust level for signing keys
does seem to have a real-world use-case. For example, the build system
used by the Qubes OS project currently parses the raw output from
verify-tag in order to assert a minimum trust level for keys used to
sign git tags [2].
[1] https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/doc/DETAILS;h=bd00006e933ac56719b1edd2478ecd79273eae72;hb=refs/heads/master
[2] https://github.com/QubesOS/qubes-builder/blob/9674c1991deef45b1a1b1c71fddfab14ba50dccf/scripts/verify-git-tag#L43
Signed-off-by: Hans Jerry Illikainen <hji@dyntopia.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-27 13:55:57 +00:00
|
|
|
const char *key;
|
2022-07-11 05:00:50 +00:00
|
|
|
const char *display_key;
|
gpg-interface: add minTrustLevel as a configuration option
Previously, signature verification for merge and pull operations checked
if the key had a trust-level of either TRUST_NEVER or TRUST_UNDEFINED in
verify_merge_signature(). If that was the case, the process die()d.
The other code paths that did signature verification relied entirely on
the return code from check_commit_signature(). And signatures made with
a good key, irregardless of its trust level, was considered valid by
check_commit_signature().
This difference in behavior might induce users to erroneously assume
that the trust level of a key in their keyring is always considered by
Git, even for operations where it is not (e.g. during a verify-commit or
verify-tag).
The way it worked was by gpg-interface.c storing the result from the
key/signature status *and* the lowest-two trust levels in the `result`
member of the signature_check structure (the last of these status lines
that were encountered got written to `result`). These are documented in
GPG under the subsection `General status codes` and `Key related`,
respectively [1].
The GPG documentation says the following on the TRUST_ status codes [1]:
"""
These are several similar status codes:
- TRUST_UNDEFINED <error_token>
- TRUST_NEVER <error_token>
- TRUST_MARGINAL [0 [<validation_model>]]
- TRUST_FULLY [0 [<validation_model>]]
- TRUST_ULTIMATE [0 [<validation_model>]]
For good signatures one of these status lines are emitted to
indicate the validity of the key used to create the signature.
The error token values are currently only emitted by gpgsm.
"""
My interpretation is that the trust level is conceptionally different
from the validity of the key and/or signature. That seems to also have
been the assumption of the old code in check_signature() where a result
of 'G' (as in GOODSIG) and 'U' (as in TRUST_NEVER or TRUST_UNDEFINED)
were both considered a success.
The two cases where a result of 'U' had special meaning were in
verify_merge_signature() (where this caused git to die()) and in
format_commit_one() (where it affected the output of the %G? format
specifier).
I think it makes sense to refactor the processing of TRUST_ status lines
such that users can configure a minimum trust level that is enforced
globally, rather than have individual parts of git (e.g. merge) do it
themselves (except for a grace period with backward compatibility).
I also think it makes sense to not store the trust level in the same
struct member as the key/signature status. While the presence of a
TRUST_ status code does imply that the signature is good (see the first
paragraph in the included snippet above), as far as I can tell, the
order of the status lines from GPG isn't well-defined; thus it would
seem plausible that the trust level could be overwritten with the
key/signature status if they were stored in the same member of the
signature_check structure.
This patch introduces a new configuration option: gpg.minTrustLevel. It
consolidates trust-level verification to gpg-interface.c and adds a new
`trust_level` member to the signature_check structure.
Backward-compatibility is maintained by introducing a special case in
verify_merge_signature() such that if no user-configurable
gpg.minTrustLevel is set, then the old behavior of rejecting
TRUST_UNDEFINED and TRUST_NEVER is enforced. If, on the other hand,
gpg.minTrustLevel is set, then that value overrides the old behavior.
Similarly, the %G? format specifier will continue show 'U' for
signatures made with a key that has a trust level of TRUST_UNDEFINED or
TRUST_NEVER, even though the 'U' character no longer exist in the
`result` member of the signature_check structure. A new format
specifier, %GT, is also introduced for users that want to show all
possible trust levels for a signature.
Another approach would have been to simply drop the trust-level
requirement in verify_merge_signature(). This would also have made the
behavior consistent with other parts of git that perform signature
verification. However, requiring a minimum trust level for signing keys
does seem to have a real-world use-case. For example, the build system
used by the Qubes OS project currently parses the raw output from
verify-tag in order to assert a minimum trust level for keys used to
sign git tags [2].
[1] https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/doc/DETAILS;h=bd00006e933ac56719b1edd2478ecd79273eae72;hb=refs/heads/master
[2] https://github.com/QubesOS/qubes-builder/blob/9674c1991deef45b1a1b1c71fddfab14ba50dccf/scripts/verify-git-tag#L43
Signed-off-by: Hans Jerry Illikainen <hji@dyntopia.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-27 13:55:57 +00:00
|
|
|
enum signature_trust_level value;
|
|
|
|
} sigcheck_gpg_trust_level[] = {
|
2022-07-11 05:00:50 +00:00
|
|
|
{ "UNDEFINED", "undefined", TRUST_UNDEFINED },
|
|
|
|
{ "NEVER", "never", TRUST_NEVER },
|
|
|
|
{ "MARGINAL", "marginal", TRUST_MARGINAL },
|
|
|
|
{ "FULLY", "fully", TRUST_FULLY },
|
|
|
|
{ "ULTIMATE", "ultimate", TRUST_ULTIMATE },
|
2014-08-14 22:31:13 +00:00
|
|
|
};
|
|
|
|
|
2019-11-21 23:43:35 +00:00
|
|
|
static void replace_cstring(char **field, const char *line, const char *next)
|
|
|
|
{
|
|
|
|
free(*field);
|
|
|
|
|
|
|
|
if (line && next)
|
|
|
|
*field = xmemdupz(line, next - line);
|
|
|
|
else
|
|
|
|
*field = NULL;
|
|
|
|
}
|
|
|
|
|
gpg-interface: add minTrustLevel as a configuration option
Previously, signature verification for merge and pull operations checked
if the key had a trust-level of either TRUST_NEVER or TRUST_UNDEFINED in
verify_merge_signature(). If that was the case, the process die()d.
The other code paths that did signature verification relied entirely on
the return code from check_commit_signature(). And signatures made with
a good key, irregardless of its trust level, was considered valid by
check_commit_signature().
This difference in behavior might induce users to erroneously assume
that the trust level of a key in their keyring is always considered by
Git, even for operations where it is not (e.g. during a verify-commit or
verify-tag).
The way it worked was by gpg-interface.c storing the result from the
key/signature status *and* the lowest-two trust levels in the `result`
member of the signature_check structure (the last of these status lines
that were encountered got written to `result`). These are documented in
GPG under the subsection `General status codes` and `Key related`,
respectively [1].
The GPG documentation says the following on the TRUST_ status codes [1]:
"""
These are several similar status codes:
- TRUST_UNDEFINED <error_token>
- TRUST_NEVER <error_token>
- TRUST_MARGINAL [0 [<validation_model>]]
- TRUST_FULLY [0 [<validation_model>]]
- TRUST_ULTIMATE [0 [<validation_model>]]
For good signatures one of these status lines are emitted to
indicate the validity of the key used to create the signature.
The error token values are currently only emitted by gpgsm.
"""
My interpretation is that the trust level is conceptionally different
from the validity of the key and/or signature. That seems to also have
been the assumption of the old code in check_signature() where a result
of 'G' (as in GOODSIG) and 'U' (as in TRUST_NEVER or TRUST_UNDEFINED)
were both considered a success.
The two cases where a result of 'U' had special meaning were in
verify_merge_signature() (where this caused git to die()) and in
format_commit_one() (where it affected the output of the %G? format
specifier).
I think it makes sense to refactor the processing of TRUST_ status lines
such that users can configure a minimum trust level that is enforced
globally, rather than have individual parts of git (e.g. merge) do it
themselves (except for a grace period with backward compatibility).
I also think it makes sense to not store the trust level in the same
struct member as the key/signature status. While the presence of a
TRUST_ status code does imply that the signature is good (see the first
paragraph in the included snippet above), as far as I can tell, the
order of the status lines from GPG isn't well-defined; thus it would
seem plausible that the trust level could be overwritten with the
key/signature status if they were stored in the same member of the
signature_check structure.
This patch introduces a new configuration option: gpg.minTrustLevel. It
consolidates trust-level verification to gpg-interface.c and adds a new
`trust_level` member to the signature_check structure.
Backward-compatibility is maintained by introducing a special case in
verify_merge_signature() such that if no user-configurable
gpg.minTrustLevel is set, then the old behavior of rejecting
TRUST_UNDEFINED and TRUST_NEVER is enforced. If, on the other hand,
gpg.minTrustLevel is set, then that value overrides the old behavior.
Similarly, the %G? format specifier will continue show 'U' for
signatures made with a key that has a trust level of TRUST_UNDEFINED or
TRUST_NEVER, even though the 'U' character no longer exist in the
`result` member of the signature_check structure. A new format
specifier, %GT, is also introduced for users that want to show all
possible trust levels for a signature.
Another approach would have been to simply drop the trust-level
requirement in verify_merge_signature(). This would also have made the
behavior consistent with other parts of git that perform signature
verification. However, requiring a minimum trust level for signing keys
does seem to have a real-world use-case. For example, the build system
used by the Qubes OS project currently parses the raw output from
verify-tag in order to assert a minimum trust level for keys used to
sign git tags [2].
[1] https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/doc/DETAILS;h=bd00006e933ac56719b1edd2478ecd79273eae72;hb=refs/heads/master
[2] https://github.com/QubesOS/qubes-builder/blob/9674c1991deef45b1a1b1c71fddfab14ba50dccf/scripts/verify-git-tag#L43
Signed-off-by: Hans Jerry Illikainen <hji@dyntopia.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-27 13:55:57 +00:00
|
|
|
static int parse_gpg_trust_level(const char *level,
|
|
|
|
enum signature_trust_level *res)
|
|
|
|
{
|
|
|
|
size_t i;
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(sigcheck_gpg_trust_level); i++) {
|
|
|
|
if (!strcmp(sigcheck_gpg_trust_level[i].key, level)) {
|
|
|
|
*res = sigcheck_gpg_trust_level[i].value;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2018-07-11 08:38:25 +00:00
|
|
|
static void parse_gpg_output(struct signature_check *sigc)
|
2014-08-14 22:31:13 +00:00
|
|
|
{
|
|
|
|
const char *buf = sigc->gpg_status;
|
2018-10-20 19:30:20 +00:00
|
|
|
const char *line, *next;
|
2018-10-22 16:38:21 +00:00
|
|
|
int i, j;
|
2018-10-20 19:30:20 +00:00
|
|
|
int seen_exclusive_status = 0;
|
|
|
|
|
|
|
|
/* Iterate over all lines */
|
|
|
|
for (line = buf; *line; line = strchrnul(line+1, '\n')) {
|
|
|
|
while (*line == '\n')
|
|
|
|
line++;
|
2019-07-16 18:47:37 +00:00
|
|
|
if (!*line)
|
|
|
|
break;
|
|
|
|
|
2018-10-20 19:30:20 +00:00
|
|
|
/* Skip lines that don't start with GNUPG status */
|
|
|
|
if (!skip_prefix(line, "[GNUPG:] ", &line))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* Iterate over all search strings */
|
|
|
|
for (i = 0; i < ARRAY_SIZE(sigcheck_gpg_status); i++) {
|
|
|
|
if (skip_prefix(line, sigcheck_gpg_status[i].check, &line)) {
|
gpg-interface: add minTrustLevel as a configuration option
Previously, signature verification for merge and pull operations checked
if the key had a trust-level of either TRUST_NEVER or TRUST_UNDEFINED in
verify_merge_signature(). If that was the case, the process die()d.
The other code paths that did signature verification relied entirely on
the return code from check_commit_signature(). And signatures made with
a good key, irregardless of its trust level, was considered valid by
check_commit_signature().
This difference in behavior might induce users to erroneously assume
that the trust level of a key in their keyring is always considered by
Git, even for operations where it is not (e.g. during a verify-commit or
verify-tag).
The way it worked was by gpg-interface.c storing the result from the
key/signature status *and* the lowest-two trust levels in the `result`
member of the signature_check structure (the last of these status lines
that were encountered got written to `result`). These are documented in
GPG under the subsection `General status codes` and `Key related`,
respectively [1].
The GPG documentation says the following on the TRUST_ status codes [1]:
"""
These are several similar status codes:
- TRUST_UNDEFINED <error_token>
- TRUST_NEVER <error_token>
- TRUST_MARGINAL [0 [<validation_model>]]
- TRUST_FULLY [0 [<validation_model>]]
- TRUST_ULTIMATE [0 [<validation_model>]]
For good signatures one of these status lines are emitted to
indicate the validity of the key used to create the signature.
The error token values are currently only emitted by gpgsm.
"""
My interpretation is that the trust level is conceptionally different
from the validity of the key and/or signature. That seems to also have
been the assumption of the old code in check_signature() where a result
of 'G' (as in GOODSIG) and 'U' (as in TRUST_NEVER or TRUST_UNDEFINED)
were both considered a success.
The two cases where a result of 'U' had special meaning were in
verify_merge_signature() (where this caused git to die()) and in
format_commit_one() (where it affected the output of the %G? format
specifier).
I think it makes sense to refactor the processing of TRUST_ status lines
such that users can configure a minimum trust level that is enforced
globally, rather than have individual parts of git (e.g. merge) do it
themselves (except for a grace period with backward compatibility).
I also think it makes sense to not store the trust level in the same
struct member as the key/signature status. While the presence of a
TRUST_ status code does imply that the signature is good (see the first
paragraph in the included snippet above), as far as I can tell, the
order of the status lines from GPG isn't well-defined; thus it would
seem plausible that the trust level could be overwritten with the
key/signature status if they were stored in the same member of the
signature_check structure.
This patch introduces a new configuration option: gpg.minTrustLevel. It
consolidates trust-level verification to gpg-interface.c and adds a new
`trust_level` member to the signature_check structure.
Backward-compatibility is maintained by introducing a special case in
verify_merge_signature() such that if no user-configurable
gpg.minTrustLevel is set, then the old behavior of rejecting
TRUST_UNDEFINED and TRUST_NEVER is enforced. If, on the other hand,
gpg.minTrustLevel is set, then that value overrides the old behavior.
Similarly, the %G? format specifier will continue show 'U' for
signatures made with a key that has a trust level of TRUST_UNDEFINED or
TRUST_NEVER, even though the 'U' character no longer exist in the
`result` member of the signature_check structure. A new format
specifier, %GT, is also introduced for users that want to show all
possible trust levels for a signature.
Another approach would have been to simply drop the trust-level
requirement in verify_merge_signature(). This would also have made the
behavior consistent with other parts of git that perform signature
verification. However, requiring a minimum trust level for signing keys
does seem to have a real-world use-case. For example, the build system
used by the Qubes OS project currently parses the raw output from
verify-tag in order to assert a minimum trust level for keys used to
sign git tags [2].
[1] https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/doc/DETAILS;h=bd00006e933ac56719b1edd2478ecd79273eae72;hb=refs/heads/master
[2] https://github.com/QubesOS/qubes-builder/blob/9674c1991deef45b1a1b1c71fddfab14ba50dccf/scripts/verify-git-tag#L43
Signed-off-by: Hans Jerry Illikainen <hji@dyntopia.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-27 13:55:57 +00:00
|
|
|
/*
|
|
|
|
* GOODSIG, BADSIG etc. can occur only once for
|
|
|
|
* each signature. Therefore, if we had more
|
|
|
|
* than one then we're dealing with multiple
|
|
|
|
* signatures. We don't support them
|
|
|
|
* currently, and they're rather hard to
|
|
|
|
* create, so something is likely fishy and we
|
|
|
|
* should reject them altogether.
|
|
|
|
*/
|
2018-10-20 19:30:20 +00:00
|
|
|
if (sigcheck_gpg_status[i].flags & GPG_STATUS_EXCLUSIVE) {
|
2018-11-02 15:53:57 +00:00
|
|
|
if (seen_exclusive_status++)
|
gpg-interface: add minTrustLevel as a configuration option
Previously, signature verification for merge and pull operations checked
if the key had a trust-level of either TRUST_NEVER or TRUST_UNDEFINED in
verify_merge_signature(). If that was the case, the process die()d.
The other code paths that did signature verification relied entirely on
the return code from check_commit_signature(). And signatures made with
a good key, irregardless of its trust level, was considered valid by
check_commit_signature().
This difference in behavior might induce users to erroneously assume
that the trust level of a key in their keyring is always considered by
Git, even for operations where it is not (e.g. during a verify-commit or
verify-tag).
The way it worked was by gpg-interface.c storing the result from the
key/signature status *and* the lowest-two trust levels in the `result`
member of the signature_check structure (the last of these status lines
that were encountered got written to `result`). These are documented in
GPG under the subsection `General status codes` and `Key related`,
respectively [1].
The GPG documentation says the following on the TRUST_ status codes [1]:
"""
These are several similar status codes:
- TRUST_UNDEFINED <error_token>
- TRUST_NEVER <error_token>
- TRUST_MARGINAL [0 [<validation_model>]]
- TRUST_FULLY [0 [<validation_model>]]
- TRUST_ULTIMATE [0 [<validation_model>]]
For good signatures one of these status lines are emitted to
indicate the validity of the key used to create the signature.
The error token values are currently only emitted by gpgsm.
"""
My interpretation is that the trust level is conceptionally different
from the validity of the key and/or signature. That seems to also have
been the assumption of the old code in check_signature() where a result
of 'G' (as in GOODSIG) and 'U' (as in TRUST_NEVER or TRUST_UNDEFINED)
were both considered a success.
The two cases where a result of 'U' had special meaning were in
verify_merge_signature() (where this caused git to die()) and in
format_commit_one() (where it affected the output of the %G? format
specifier).
I think it makes sense to refactor the processing of TRUST_ status lines
such that users can configure a minimum trust level that is enforced
globally, rather than have individual parts of git (e.g. merge) do it
themselves (except for a grace period with backward compatibility).
I also think it makes sense to not store the trust level in the same
struct member as the key/signature status. While the presence of a
TRUST_ status code does imply that the signature is good (see the first
paragraph in the included snippet above), as far as I can tell, the
order of the status lines from GPG isn't well-defined; thus it would
seem plausible that the trust level could be overwritten with the
key/signature status if they were stored in the same member of the
signature_check structure.
This patch introduces a new configuration option: gpg.minTrustLevel. It
consolidates trust-level verification to gpg-interface.c and adds a new
`trust_level` member to the signature_check structure.
Backward-compatibility is maintained by introducing a special case in
verify_merge_signature() such that if no user-configurable
gpg.minTrustLevel is set, then the old behavior of rejecting
TRUST_UNDEFINED and TRUST_NEVER is enforced. If, on the other hand,
gpg.minTrustLevel is set, then that value overrides the old behavior.
Similarly, the %G? format specifier will continue show 'U' for
signatures made with a key that has a trust level of TRUST_UNDEFINED or
TRUST_NEVER, even though the 'U' character no longer exist in the
`result` member of the signature_check structure. A new format
specifier, %GT, is also introduced for users that want to show all
possible trust levels for a signature.
Another approach would have been to simply drop the trust-level
requirement in verify_merge_signature(). This would also have made the
behavior consistent with other parts of git that perform signature
verification. However, requiring a minimum trust level for signing keys
does seem to have a real-world use-case. For example, the build system
used by the Qubes OS project currently parses the raw output from
verify-tag in order to assert a minimum trust level for keys used to
sign git tags [2].
[1] https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/doc/DETAILS;h=bd00006e933ac56719b1edd2478ecd79273eae72;hb=refs/heads/master
[2] https://github.com/QubesOS/qubes-builder/blob/9674c1991deef45b1a1b1c71fddfab14ba50dccf/scripts/verify-git-tag#L43
Signed-off-by: Hans Jerry Illikainen <hji@dyntopia.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-27 13:55:57 +00:00
|
|
|
goto error;
|
2018-10-20 19:30:20 +00:00
|
|
|
}
|
|
|
|
|
2018-10-22 16:38:20 +00:00
|
|
|
if (sigcheck_gpg_status[i].result)
|
|
|
|
sigc->result = sigcheck_gpg_status[i].result;
|
2018-10-22 16:38:19 +00:00
|
|
|
/* Do we have key information? */
|
|
|
|
if (sigcheck_gpg_status[i].flags & GPG_STATUS_KEYID) {
|
2018-10-20 19:30:20 +00:00
|
|
|
next = strchrnul(line, ' ');
|
2019-11-21 23:43:35 +00:00
|
|
|
replace_cstring(&sigc->key, line, next);
|
2018-10-22 16:38:19 +00:00
|
|
|
/* Do we have signer information? */
|
|
|
|
if (*next && (sigcheck_gpg_status[i].flags & GPG_STATUS_UID)) {
|
2018-10-20 19:30:20 +00:00
|
|
|
line = next + 1;
|
|
|
|
next = strchrnul(line, '\n');
|
2019-11-21 23:43:35 +00:00
|
|
|
replace_cstring(&sigc->signer, line, next);
|
2018-10-20 19:30:20 +00:00
|
|
|
}
|
|
|
|
}
|
gpg-interface: add minTrustLevel as a configuration option
Previously, signature verification for merge and pull operations checked
if the key had a trust-level of either TRUST_NEVER or TRUST_UNDEFINED in
verify_merge_signature(). If that was the case, the process die()d.
The other code paths that did signature verification relied entirely on
the return code from check_commit_signature(). And signatures made with
a good key, irregardless of its trust level, was considered valid by
check_commit_signature().
This difference in behavior might induce users to erroneously assume
that the trust level of a key in their keyring is always considered by
Git, even for operations where it is not (e.g. during a verify-commit or
verify-tag).
The way it worked was by gpg-interface.c storing the result from the
key/signature status *and* the lowest-two trust levels in the `result`
member of the signature_check structure (the last of these status lines
that were encountered got written to `result`). These are documented in
GPG under the subsection `General status codes` and `Key related`,
respectively [1].
The GPG documentation says the following on the TRUST_ status codes [1]:
"""
These are several similar status codes:
- TRUST_UNDEFINED <error_token>
- TRUST_NEVER <error_token>
- TRUST_MARGINAL [0 [<validation_model>]]
- TRUST_FULLY [0 [<validation_model>]]
- TRUST_ULTIMATE [0 [<validation_model>]]
For good signatures one of these status lines are emitted to
indicate the validity of the key used to create the signature.
The error token values are currently only emitted by gpgsm.
"""
My interpretation is that the trust level is conceptionally different
from the validity of the key and/or signature. That seems to also have
been the assumption of the old code in check_signature() where a result
of 'G' (as in GOODSIG) and 'U' (as in TRUST_NEVER or TRUST_UNDEFINED)
were both considered a success.
The two cases where a result of 'U' had special meaning were in
verify_merge_signature() (where this caused git to die()) and in
format_commit_one() (where it affected the output of the %G? format
specifier).
I think it makes sense to refactor the processing of TRUST_ status lines
such that users can configure a minimum trust level that is enforced
globally, rather than have individual parts of git (e.g. merge) do it
themselves (except for a grace period with backward compatibility).
I also think it makes sense to not store the trust level in the same
struct member as the key/signature status. While the presence of a
TRUST_ status code does imply that the signature is good (see the first
paragraph in the included snippet above), as far as I can tell, the
order of the status lines from GPG isn't well-defined; thus it would
seem plausible that the trust level could be overwritten with the
key/signature status if they were stored in the same member of the
signature_check structure.
This patch introduces a new configuration option: gpg.minTrustLevel. It
consolidates trust-level verification to gpg-interface.c and adds a new
`trust_level` member to the signature_check structure.
Backward-compatibility is maintained by introducing a special case in
verify_merge_signature() such that if no user-configurable
gpg.minTrustLevel is set, then the old behavior of rejecting
TRUST_UNDEFINED and TRUST_NEVER is enforced. If, on the other hand,
gpg.minTrustLevel is set, then that value overrides the old behavior.
Similarly, the %G? format specifier will continue show 'U' for
signatures made with a key that has a trust level of TRUST_UNDEFINED or
TRUST_NEVER, even though the 'U' character no longer exist in the
`result` member of the signature_check structure. A new format
specifier, %GT, is also introduced for users that want to show all
possible trust levels for a signature.
Another approach would have been to simply drop the trust-level
requirement in verify_merge_signature(). This would also have made the
behavior consistent with other parts of git that perform signature
verification. However, requiring a minimum trust level for signing keys
does seem to have a real-world use-case. For example, the build system
used by the Qubes OS project currently parses the raw output from
verify-tag in order to assert a minimum trust level for keys used to
sign git tags [2].
[1] https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/doc/DETAILS;h=bd00006e933ac56719b1edd2478ecd79273eae72;hb=refs/heads/master
[2] https://github.com/QubesOS/qubes-builder/blob/9674c1991deef45b1a1b1c71fddfab14ba50dccf/scripts/verify-git-tag#L43
Signed-off-by: Hans Jerry Illikainen <hji@dyntopia.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-27 13:55:57 +00:00
|
|
|
|
|
|
|
/* Do we have trust level? */
|
|
|
|
if (sigcheck_gpg_status[i].flags & GPG_STATUS_TRUST_LEVEL) {
|
|
|
|
/*
|
|
|
|
* GPG v1 and v2 differs in how the
|
|
|
|
* TRUST_ lines are written. Some
|
|
|
|
* trust lines contain no additional
|
|
|
|
* space-separated information for v1.
|
|
|
|
*/
|
|
|
|
size_t trust_size = strcspn(line, " \n");
|
|
|
|
char *trust = xmemdupz(line, trust_size);
|
|
|
|
|
|
|
|
if (parse_gpg_trust_level(trust, &sigc->trust_level)) {
|
|
|
|
free(trust);
|
|
|
|
goto error;
|
|
|
|
}
|
|
|
|
free(trust);
|
|
|
|
}
|
|
|
|
|
2018-10-22 16:38:20 +00:00
|
|
|
/* Do we have fingerprint? */
|
|
|
|
if (sigcheck_gpg_status[i].flags & GPG_STATUS_FINGERPRINT) {
|
2019-11-22 20:23:12 +00:00
|
|
|
const char *limit;
|
|
|
|
char **field;
|
|
|
|
|
2018-10-22 16:38:20 +00:00
|
|
|
next = strchrnul(line, ' ');
|
2019-11-21 23:43:35 +00:00
|
|
|
replace_cstring(&sigc->fingerprint, line, next);
|
2018-10-22 16:38:21 +00:00
|
|
|
|
2019-11-22 20:23:12 +00:00
|
|
|
/*
|
|
|
|
* Skip interim fields. The search is
|
|
|
|
* limited to the same line since only
|
|
|
|
* OpenPGP signatures has a field with
|
|
|
|
* the primary fingerprint.
|
|
|
|
*/
|
|
|
|
limit = strchrnul(line, '\n');
|
2018-10-22 16:38:21 +00:00
|
|
|
for (j = 9; j > 0; j--) {
|
2019-11-22 20:23:12 +00:00
|
|
|
if (!*next || limit <= next)
|
2018-10-22 16:38:21 +00:00
|
|
|
break;
|
|
|
|
line = next + 1;
|
|
|
|
next = strchrnul(line, ' ');
|
|
|
|
}
|
|
|
|
|
2019-11-22 20:23:12 +00:00
|
|
|
field = &sigc->primary_key_fingerprint;
|
|
|
|
if (!j) {
|
|
|
|
next = strchrnul(line, '\n');
|
|
|
|
replace_cstring(field, line, next);
|
|
|
|
} else {
|
|
|
|
replace_cstring(field, NULL, NULL);
|
|
|
|
}
|
2018-10-22 16:38:20 +00:00
|
|
|
}
|
2018-10-20 19:30:20 +00:00
|
|
|
|
|
|
|
break;
|
gpg-interface: use more status letters
According to gpg2's doc/DETAILS:
For each signature only one of the codes GOODSIG, BADSIG,
EXPSIG, EXPKEYSIG, REVKEYSIG or ERRSIG will be emitted.
gpg1 ("classic") behaves the same (although doc/DETAILS differs).
Currently, we parse gpg's status output for GOODSIG, BADSIG and
trust information and translate that into status codes G, B, U, N
for the %G? format specifier.
git-verify-* returns success in the GOODSIG case only. This is
somewhat in disagreement with gpg, which considers the first 5 of
the 6 above as VALIDSIG, but we err on the very safe side.
Introduce additional status codes E, X, Y, R for ERRSIG, EXPSIG,
EXPKEYSIG, and REVKEYSIG so that a user of %G? gets more information
about the absence of a 'G' on first glance.
Requested-by: Alex <agrambot@gmail.com>
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-12 13:04:15 +00:00
|
|
|
}
|
2014-08-14 22:31:13 +00:00
|
|
|
}
|
|
|
|
}
|
2018-10-20 19:30:20 +00:00
|
|
|
return;
|
|
|
|
|
gpg-interface: add minTrustLevel as a configuration option
Previously, signature verification for merge and pull operations checked
if the key had a trust-level of either TRUST_NEVER or TRUST_UNDEFINED in
verify_merge_signature(). If that was the case, the process die()d.
The other code paths that did signature verification relied entirely on
the return code from check_commit_signature(). And signatures made with
a good key, irregardless of its trust level, was considered valid by
check_commit_signature().
This difference in behavior might induce users to erroneously assume
that the trust level of a key in their keyring is always considered by
Git, even for operations where it is not (e.g. during a verify-commit or
verify-tag).
The way it worked was by gpg-interface.c storing the result from the
key/signature status *and* the lowest-two trust levels in the `result`
member of the signature_check structure (the last of these status lines
that were encountered got written to `result`). These are documented in
GPG under the subsection `General status codes` and `Key related`,
respectively [1].
The GPG documentation says the following on the TRUST_ status codes [1]:
"""
These are several similar status codes:
- TRUST_UNDEFINED <error_token>
- TRUST_NEVER <error_token>
- TRUST_MARGINAL [0 [<validation_model>]]
- TRUST_FULLY [0 [<validation_model>]]
- TRUST_ULTIMATE [0 [<validation_model>]]
For good signatures one of these status lines are emitted to
indicate the validity of the key used to create the signature.
The error token values are currently only emitted by gpgsm.
"""
My interpretation is that the trust level is conceptionally different
from the validity of the key and/or signature. That seems to also have
been the assumption of the old code in check_signature() where a result
of 'G' (as in GOODSIG) and 'U' (as in TRUST_NEVER or TRUST_UNDEFINED)
were both considered a success.
The two cases where a result of 'U' had special meaning were in
verify_merge_signature() (where this caused git to die()) and in
format_commit_one() (where it affected the output of the %G? format
specifier).
I think it makes sense to refactor the processing of TRUST_ status lines
such that users can configure a minimum trust level that is enforced
globally, rather than have individual parts of git (e.g. merge) do it
themselves (except for a grace period with backward compatibility).
I also think it makes sense to not store the trust level in the same
struct member as the key/signature status. While the presence of a
TRUST_ status code does imply that the signature is good (see the first
paragraph in the included snippet above), as far as I can tell, the
order of the status lines from GPG isn't well-defined; thus it would
seem plausible that the trust level could be overwritten with the
key/signature status if they were stored in the same member of the
signature_check structure.
This patch introduces a new configuration option: gpg.minTrustLevel. It
consolidates trust-level verification to gpg-interface.c and adds a new
`trust_level` member to the signature_check structure.
Backward-compatibility is maintained by introducing a special case in
verify_merge_signature() such that if no user-configurable
gpg.minTrustLevel is set, then the old behavior of rejecting
TRUST_UNDEFINED and TRUST_NEVER is enforced. If, on the other hand,
gpg.minTrustLevel is set, then that value overrides the old behavior.
Similarly, the %G? format specifier will continue show 'U' for
signatures made with a key that has a trust level of TRUST_UNDEFINED or
TRUST_NEVER, even though the 'U' character no longer exist in the
`result` member of the signature_check structure. A new format
specifier, %GT, is also introduced for users that want to show all
possible trust levels for a signature.
Another approach would have been to simply drop the trust-level
requirement in verify_merge_signature(). This would also have made the
behavior consistent with other parts of git that perform signature
verification. However, requiring a minimum trust level for signing keys
does seem to have a real-world use-case. For example, the build system
used by the Qubes OS project currently parses the raw output from
verify-tag in order to assert a minimum trust level for keys used to
sign git tags [2].
[1] https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/doc/DETAILS;h=bd00006e933ac56719b1edd2478ecd79273eae72;hb=refs/heads/master
[2] https://github.com/QubesOS/qubes-builder/blob/9674c1991deef45b1a1b1c71fddfab14ba50dccf/scripts/verify-git-tag#L43
Signed-off-by: Hans Jerry Illikainen <hji@dyntopia.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-27 13:55:57 +00:00
|
|
|
error:
|
2018-10-20 19:30:20 +00:00
|
|
|
sigc->result = 'E';
|
|
|
|
/* Clear partial data to avoid confusion */
|
2018-10-22 16:38:21 +00:00
|
|
|
FREE_AND_NULL(sigc->primary_key_fingerprint);
|
2018-10-22 16:38:20 +00:00
|
|
|
FREE_AND_NULL(sigc->fingerprint);
|
2018-10-20 19:30:20 +00:00
|
|
|
FREE_AND_NULL(sigc->signer);
|
|
|
|
FREE_AND_NULL(sigc->key);
|
2014-08-14 22:31:13 +00:00
|
|
|
}
|
|
|
|
|
2021-09-10 20:07:34 +00:00
|
|
|
static int verify_gpg_signed_buffer(struct signature_check *sigc,
|
2021-12-09 08:52:43 +00:00
|
|
|
struct gpg_format *fmt,
|
|
|
|
const char *signature,
|
2021-09-10 20:07:34 +00:00
|
|
|
size_t signature_size)
|
2020-03-04 11:48:04 +00:00
|
|
|
{
|
|
|
|
struct child_process gpg = CHILD_PROCESS_INIT;
|
|
|
|
struct tempfile *temp;
|
|
|
|
int ret;
|
2021-09-10 20:07:34 +00:00
|
|
|
struct strbuf gpg_stdout = STRBUF_INIT;
|
|
|
|
struct strbuf gpg_stderr = STRBUF_INIT;
|
2020-03-04 11:48:04 +00:00
|
|
|
|
|
|
|
temp = mks_tempfile_t(".git_vtag_tmpXXXXXX");
|
|
|
|
if (!temp)
|
|
|
|
return error_errno(_("could not create temporary file"));
|
|
|
|
if (write_in_full(temp->fd, signature, signature_size) < 0 ||
|
|
|
|
close_tempfile_gently(temp) < 0) {
|
|
|
|
error_errno(_("failed writing detached signature to '%s'"),
|
|
|
|
temp->filename.buf);
|
|
|
|
delete_tempfile(&temp);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2020-07-28 20:24:53 +00:00
|
|
|
strvec_push(&gpg.args, fmt->program);
|
|
|
|
strvec_pushv(&gpg.args, fmt->verify_args);
|
|
|
|
strvec_pushl(&gpg.args,
|
strvec: fix indentation in renamed calls
Code which split an argv_array call across multiple lines, like:
argv_array_pushl(&args, "one argument",
"another argument", "and more",
NULL);
was recently mechanically renamed to use strvec, which results in
mis-matched indentation like:
strvec_pushl(&args, "one argument",
"another argument", "and more",
NULL);
Let's fix these up to align the arguments with the opening paren. I did
this manually by sifting through the results of:
git jump grep 'strvec_.*,$'
and liberally applying my editor's auto-format. Most of the changes are
of the form shown above, though I also normalized a few that had
originally used a single-tab indentation (rather than our usual style of
aligning with the open paren). I also rewrapped a couple of obvious
cases (e.g., where previously too-long lines became short enough to fit
on one), but I wasn't aggressive about it. In cases broken to three or
more lines, the grouping of arguments is sometimes meaningful, and it
wasn't worth my time or reviewer time to ponder each case individually.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-28 20:26:31 +00:00
|
|
|
"--status-fd=1",
|
|
|
|
"--verify", temp->filename.buf, "-",
|
|
|
|
NULL);
|
2020-03-04 11:48:04 +00:00
|
|
|
|
|
|
|
sigchain_push(SIGPIPE, SIG_IGN);
|
2021-12-09 08:52:43 +00:00
|
|
|
ret = pipe_command(&gpg, sigc->payload, sigc->payload_len, &gpg_stdout, 0,
|
2021-09-10 20:07:34 +00:00
|
|
|
&gpg_stderr, 0);
|
2020-03-04 11:48:04 +00:00
|
|
|
sigchain_pop(SIGPIPE);
|
|
|
|
|
|
|
|
delete_tempfile(&temp);
|
|
|
|
|
2021-09-10 20:07:34 +00:00
|
|
|
ret |= !strstr(gpg_stdout.buf, "\n[GNUPG:] GOODSIG ");
|
|
|
|
sigc->output = strbuf_detach(&gpg_stderr, NULL);
|
|
|
|
sigc->gpg_status = strbuf_detach(&gpg_stdout, NULL);
|
|
|
|
|
|
|
|
parse_gpg_output(sigc);
|
|
|
|
|
|
|
|
strbuf_release(&gpg_stdout);
|
|
|
|
strbuf_release(&gpg_stderr);
|
2020-03-04 11:48:04 +00:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2021-09-10 20:07:39 +00:00
|
|
|
static void parse_ssh_output(struct signature_check *sigc)
|
|
|
|
{
|
|
|
|
const char *line, *principal, *search;
|
2021-10-18 17:15:00 +00:00
|
|
|
char *to_free;
|
2021-09-10 20:07:39 +00:00
|
|
|
char *key = NULL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* ssh-keygen output should be:
|
|
|
|
* Good "git" signature for PRINCIPAL with RSA key SHA256:FINGERPRINT
|
|
|
|
*
|
|
|
|
* or for valid but unknown keys:
|
|
|
|
* Good "git" signature with RSA key SHA256:FINGERPRINT
|
|
|
|
*
|
|
|
|
* Note that "PRINCIPAL" can contain whitespace, "RSA" and
|
|
|
|
* "SHA256" part could be a different token that names of
|
|
|
|
* the algorithms used, and "FINGERPRINT" is a hexadecimal
|
|
|
|
* string. By finding the last occurence of " with ", we can
|
|
|
|
* reliably parse out the PRINCIPAL.
|
|
|
|
*/
|
|
|
|
sigc->result = 'B';
|
|
|
|
sigc->trust_level = TRUST_NEVER;
|
|
|
|
|
2021-10-18 17:15:00 +00:00
|
|
|
line = to_free = xmemdupz(sigc->output, strcspn(sigc->output, "\n"));
|
2021-09-10 20:07:39 +00:00
|
|
|
|
|
|
|
if (skip_prefix(line, "Good \"git\" signature for ", &line)) {
|
|
|
|
/* Search for the last "with" to get the full principal */
|
|
|
|
principal = line;
|
|
|
|
do {
|
|
|
|
search = strstr(line, " with ");
|
|
|
|
if (search)
|
|
|
|
line = search + 1;
|
|
|
|
} while (search != NULL);
|
2021-10-30 17:04:56 +00:00
|
|
|
if (line == principal)
|
|
|
|
goto cleanup;
|
|
|
|
|
|
|
|
/* Valid signature and known principal */
|
|
|
|
sigc->result = 'G';
|
|
|
|
sigc->trust_level = TRUST_FULLY;
|
2021-09-10 20:07:39 +00:00
|
|
|
sigc->signer = xmemdupz(principal, line - principal - 1);
|
|
|
|
} else if (skip_prefix(line, "Good \"git\" signature with ", &line)) {
|
|
|
|
/* Valid signature, but key unknown */
|
|
|
|
sigc->result = 'G';
|
|
|
|
sigc->trust_level = TRUST_UNDEFINED;
|
|
|
|
} else {
|
2021-10-18 17:15:00 +00:00
|
|
|
goto cleanup;
|
2021-09-10 20:07:39 +00:00
|
|
|
}
|
|
|
|
|
2021-10-30 17:07:38 +00:00
|
|
|
key = strstr(line, "key ");
|
2021-09-10 20:07:39 +00:00
|
|
|
if (key) {
|
2021-10-30 17:07:38 +00:00
|
|
|
sigc->fingerprint = xstrdup(strstr(line, "key ") + 4);
|
2021-09-10 20:07:39 +00:00
|
|
|
sigc->key = xstrdup(sigc->fingerprint);
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* Output did not match what we expected
|
|
|
|
* Treat the signature as bad
|
|
|
|
*/
|
|
|
|
sigc->result = 'B';
|
|
|
|
}
|
2021-10-18 17:15:00 +00:00
|
|
|
|
|
|
|
cleanup:
|
|
|
|
free(to_free);
|
2021-09-10 20:07:39 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static int verify_ssh_signed_buffer(struct signature_check *sigc,
|
2021-12-09 08:52:43 +00:00
|
|
|
struct gpg_format *fmt,
|
|
|
|
const char *signature,
|
2021-09-10 20:07:39 +00:00
|
|
|
size_t signature_size)
|
|
|
|
{
|
|
|
|
struct child_process ssh_keygen = CHILD_PROCESS_INIT;
|
|
|
|
struct tempfile *buffer_file;
|
|
|
|
int ret = -1;
|
|
|
|
const char *line;
|
|
|
|
char *principal;
|
|
|
|
struct strbuf ssh_principals_out = STRBUF_INIT;
|
|
|
|
struct strbuf ssh_principals_err = STRBUF_INIT;
|
|
|
|
struct strbuf ssh_keygen_out = STRBUF_INIT;
|
|
|
|
struct strbuf ssh_keygen_err = STRBUF_INIT;
|
2021-12-09 08:52:45 +00:00
|
|
|
struct strbuf verify_time = STRBUF_INIT;
|
|
|
|
const struct date_mode verify_date_mode = {
|
|
|
|
.type = DATE_STRFTIME,
|
|
|
|
.strftime_fmt = "%Y%m%d%H%M%S",
|
|
|
|
/* SSH signing key validity has no timezone information - Use the local timezone */
|
|
|
|
.local = 1,
|
|
|
|
};
|
2021-09-10 20:07:39 +00:00
|
|
|
|
|
|
|
if (!ssh_allowed_signers) {
|
|
|
|
error(_("gpg.ssh.allowedSignersFile needs to be configured and exist for ssh signature verification"));
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
buffer_file = mks_tempfile_t(".git_vtag_tmpXXXXXX");
|
|
|
|
if (!buffer_file)
|
|
|
|
return error_errno(_("could not create temporary file"));
|
|
|
|
if (write_in_full(buffer_file->fd, signature, signature_size) < 0 ||
|
|
|
|
close_tempfile_gently(buffer_file) < 0) {
|
|
|
|
error_errno(_("failed writing detached signature to '%s'"),
|
|
|
|
buffer_file->filename.buf);
|
|
|
|
delete_tempfile(&buffer_file);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2021-12-09 08:52:45 +00:00
|
|
|
if (sigc->payload_timestamp)
|
|
|
|
strbuf_addf(&verify_time, "-Overify-time=%s",
|
2024-04-05 17:44:59 +00:00
|
|
|
show_date(sigc->payload_timestamp, 0, verify_date_mode));
|
2021-12-09 08:52:45 +00:00
|
|
|
|
2021-09-10 20:07:39 +00:00
|
|
|
/* Find the principal from the signers */
|
|
|
|
strvec_pushl(&ssh_keygen.args, fmt->program,
|
|
|
|
"-Y", "find-principals",
|
|
|
|
"-f", ssh_allowed_signers,
|
|
|
|
"-s", buffer_file->filename.buf,
|
2021-12-09 08:52:45 +00:00
|
|
|
verify_time.buf,
|
2021-09-10 20:07:39 +00:00
|
|
|
NULL);
|
|
|
|
ret = pipe_command(&ssh_keygen, NULL, 0, &ssh_principals_out, 0,
|
|
|
|
&ssh_principals_err, 0);
|
|
|
|
if (ret && strstr(ssh_principals_err.buf, "usage:")) {
|
|
|
|
error(_("ssh-keygen -Y find-principals/verify is needed for ssh signature verification (available in openssh version 8.2p1+)"));
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
if (ret || !ssh_principals_out.len) {
|
|
|
|
/*
|
|
|
|
* We did not find a matching principal in the allowedSigners
|
|
|
|
* Check without validation
|
|
|
|
*/
|
|
|
|
child_process_init(&ssh_keygen);
|
|
|
|
strvec_pushl(&ssh_keygen.args, fmt->program,
|
|
|
|
"-Y", "check-novalidate",
|
|
|
|
"-n", "git",
|
|
|
|
"-s", buffer_file->filename.buf,
|
2021-12-09 08:52:45 +00:00
|
|
|
verify_time.buf,
|
2021-09-10 20:07:39 +00:00
|
|
|
NULL);
|
2021-12-09 08:52:43 +00:00
|
|
|
pipe_command(&ssh_keygen, sigc->payload, sigc->payload_len,
|
2021-09-10 20:07:39 +00:00
|
|
|
&ssh_keygen_out, 0, &ssh_keygen_err, 0);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Fail on unknown keys
|
|
|
|
* we still call check-novalidate to display the signature info
|
|
|
|
*/
|
|
|
|
ret = -1;
|
|
|
|
} else {
|
|
|
|
/* Check every principal we found (one per line) */
|
2022-01-07 09:07:35 +00:00
|
|
|
const char *next;
|
|
|
|
for (line = ssh_principals_out.buf;
|
|
|
|
*line;
|
|
|
|
line = next) {
|
|
|
|
const char *end_of_text;
|
|
|
|
|
|
|
|
next = end_of_text = strchrnul(line, '\n');
|
|
|
|
|
|
|
|
/* Did we find a LF, and did we have CR before it? */
|
|
|
|
if (*end_of_text &&
|
|
|
|
line < end_of_text &&
|
|
|
|
end_of_text[-1] == '\r')
|
|
|
|
end_of_text--;
|
|
|
|
|
|
|
|
/* Unless we hit NUL, skip over the LF we found */
|
|
|
|
if (*next)
|
|
|
|
next++;
|
|
|
|
|
|
|
|
/* Not all lines are data. Skip empty ones */
|
|
|
|
if (line == end_of_text)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* We now know we have an non-empty line. Process it */
|
|
|
|
principal = xmemdupz(line, end_of_text - line);
|
2021-09-10 20:07:39 +00:00
|
|
|
|
|
|
|
child_process_init(&ssh_keygen);
|
|
|
|
strbuf_release(&ssh_keygen_out);
|
|
|
|
strbuf_release(&ssh_keygen_err);
|
|
|
|
strvec_push(&ssh_keygen.args, fmt->program);
|
|
|
|
/*
|
|
|
|
* We found principals
|
|
|
|
* Try with each until we find a match
|
|
|
|
*/
|
|
|
|
strvec_pushl(&ssh_keygen.args, "-Y", "verify",
|
|
|
|
"-n", "git",
|
|
|
|
"-f", ssh_allowed_signers,
|
|
|
|
"-I", principal,
|
|
|
|
"-s", buffer_file->filename.buf,
|
2021-12-09 08:52:45 +00:00
|
|
|
verify_time.buf,
|
2021-09-10 20:07:39 +00:00
|
|
|
NULL);
|
|
|
|
|
|
|
|
if (ssh_revocation_file) {
|
|
|
|
if (file_exists(ssh_revocation_file)) {
|
|
|
|
strvec_pushl(&ssh_keygen.args, "-r",
|
|
|
|
ssh_revocation_file, NULL);
|
|
|
|
} else {
|
|
|
|
warning(_("ssh signing revocation file configured but not found: %s"),
|
|
|
|
ssh_revocation_file);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
sigchain_push(SIGPIPE, SIG_IGN);
|
2021-12-09 08:52:43 +00:00
|
|
|
ret = pipe_command(&ssh_keygen, sigc->payload, sigc->payload_len,
|
2021-09-10 20:07:39 +00:00
|
|
|
&ssh_keygen_out, 0, &ssh_keygen_err, 0);
|
|
|
|
sigchain_pop(SIGPIPE);
|
|
|
|
|
|
|
|
FREE_AND_NULL(principal);
|
|
|
|
|
|
|
|
if (!ret)
|
|
|
|
ret = !starts_with(ssh_keygen_out.buf, "Good");
|
|
|
|
|
|
|
|
if (!ret)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2024-03-12 09:17:27 +00:00
|
|
|
strbuf_stripspace(&ssh_keygen_out, NULL);
|
|
|
|
strbuf_stripspace(&ssh_keygen_err, NULL);
|
2021-09-10 20:07:39 +00:00
|
|
|
/* Add stderr outputs to show the user actual ssh-keygen errors */
|
|
|
|
strbuf_add(&ssh_keygen_out, ssh_principals_err.buf, ssh_principals_err.len);
|
|
|
|
strbuf_add(&ssh_keygen_out, ssh_keygen_err.buf, ssh_keygen_err.len);
|
|
|
|
sigc->output = strbuf_detach(&ssh_keygen_out, NULL);
|
|
|
|
sigc->gpg_status = xstrdup(sigc->output);
|
|
|
|
|
|
|
|
parse_ssh_output(sigc);
|
|
|
|
|
|
|
|
out:
|
|
|
|
if (buffer_file)
|
|
|
|
delete_tempfile(&buffer_file);
|
|
|
|
strbuf_release(&ssh_principals_out);
|
|
|
|
strbuf_release(&ssh_principals_err);
|
|
|
|
strbuf_release(&ssh_keygen_out);
|
|
|
|
strbuf_release(&ssh_keygen_err);
|
2021-12-09 08:52:45 +00:00
|
|
|
strbuf_release(&verify_time);
|
2021-09-10 20:07:39 +00:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2021-12-09 08:52:45 +00:00
|
|
|
static int parse_payload_metadata(struct signature_check *sigc)
|
|
|
|
{
|
|
|
|
const char *ident_line = NULL;
|
|
|
|
size_t ident_len;
|
|
|
|
struct ident_split ident;
|
|
|
|
const char *signer_header;
|
|
|
|
|
|
|
|
switch (sigc->payload_type) {
|
|
|
|
case SIGNATURE_PAYLOAD_COMMIT:
|
|
|
|
signer_header = "committer";
|
|
|
|
break;
|
|
|
|
case SIGNATURE_PAYLOAD_TAG:
|
|
|
|
signer_header = "tagger";
|
|
|
|
break;
|
|
|
|
case SIGNATURE_PAYLOAD_UNDEFINED:
|
|
|
|
case SIGNATURE_PAYLOAD_PUSH_CERT:
|
|
|
|
/* Ignore payloads we don't want to parse */
|
|
|
|
return 0;
|
|
|
|
default:
|
|
|
|
BUG("invalid value for sigc->payload_type");
|
|
|
|
}
|
|
|
|
|
|
|
|
ident_line = find_commit_header(sigc->payload, signer_header, &ident_len);
|
|
|
|
if (!ident_line || !ident_len)
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
if (split_ident_line(&ident, ident_line, ident_len))
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
if (!sigc->payload_timestamp && ident.date_begin && ident.date_end)
|
|
|
|
sigc->payload_timestamp = parse_timestamp(ident.date_begin, NULL, 10);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-12-09 08:52:43 +00:00
|
|
|
int check_signature(struct signature_check *sigc,
|
|
|
|
const char *signature, size_t slen)
|
2015-06-21 23:14:38 +00:00
|
|
|
{
|
2021-09-10 20:07:34 +00:00
|
|
|
struct gpg_format *fmt;
|
2015-06-21 23:14:38 +00:00
|
|
|
int status;
|
|
|
|
|
2023-02-09 20:24:14 +00:00
|
|
|
gpg_interface_lazy_init();
|
|
|
|
|
2015-06-21 23:14:38 +00:00
|
|
|
sigc->result = 'N';
|
gpg-interface: set trust level of missing key to "undefined"
In check_signature(), we initialize the trust_level field to "-1", with
the idea that if gpg does not return a trust level at all (if there is
no signature, or if the signature is made by an unknown key), we'll
use that value. But this has two problems:
1. Since the field is an enum, it's up to the compiler to decide what
underlying storage to use, and it only has to fit the values we've
declared. So we may not be able to store "-1" at all. And indeed,
on my system (linux with gcc), the resulting enum is an unsigned
32-bit value, and -1 becomes 4294967295.
The difference may seem academic (and you even get "-1" if you pass
it to printf("%d")), but it means that code like this:
status |= sigc->trust_level < configured_min_trust_level;
does not necessarily behave as expected. This turns out not to be a
bug in practice, though, because we keep the "-1" only when gpg did
not report a signature from a known key, in which case the line
above:
status |= sigc->result != 'G';
would always set status to non-zero anyway. So only a 'G' signature
with no parsed trust level would cause a problem, which doesn't
seem likely to trigger (outside of unexpected gpg behavior).
2. When using the "%GT" format placeholder, we pass the value to
gpg_trust_level_to_str(), which complains that the value is out of
range with a BUG(). This behavior was introduced by 803978da49
(gpg-interface: add function for converting trust level to string,
2022-07-11). Before that, we just did a switch() on the enum, and
anything that wasn't matched would end up as the empty string.
Curiously, solving this by naively doing:
if (level < 0)
return "";
in that function isn't sufficient. Because of (1) above, the
compiler can (and does in my case) actually remove that conditional
as dead code!
We can solve both by representing this state as an enum value. We could
do this by adding a new "unknown" value. But this really seems to match
the existing "undefined" level well. GPG describes this as "Not enough
information for calculation".
We have tests in t7510 that trigger this case (verifying a signature
from a key that we don't have, and then checking various %G
placeholders), but they didn't notice the BUG() because we didn't look
at %GT for that case! Let's make sure we check all %G placeholders for
each case in the formatting tests.
The interesting ones here are "show unknown signature with custom
format" and "show lack of signature with custom format", both of which
would BUG() before, and now turn %GT into "undefined". Prior to
803978da49 they would have turned it into the empty string, but I think
saying "undefined" consistently is a reasonable outcome, and probably
makes life easier for anyone parsing the output (and any such parser had
to be ready to see "undefined" already).
The other modified tests produce the same output before and after this
patch, but now we're consistently checking both %G? and %GT in all of
them.
Signed-off-by: Jeff King <peff@peff.net>
Reported-by: Rolf Eike Beer <eb@emlix.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-04-19 01:29:57 +00:00
|
|
|
sigc->trust_level = TRUST_UNDEFINED;
|
2015-06-21 23:14:38 +00:00
|
|
|
|
2021-09-10 20:07:34 +00:00
|
|
|
fmt = get_format_by_sig(signature);
|
|
|
|
if (!fmt)
|
|
|
|
die(_("bad/incompatible signature '%s'"), signature);
|
|
|
|
|
2021-12-09 08:52:45 +00:00
|
|
|
if (parse_payload_metadata(sigc))
|
|
|
|
return 1;
|
|
|
|
|
2021-12-09 08:52:43 +00:00
|
|
|
status = fmt->verify_signed_buffer(sigc, fmt, signature, slen);
|
2021-09-10 20:07:34 +00:00
|
|
|
|
|
|
|
if (status && !sigc->output)
|
|
|
|
return !!status;
|
|
|
|
|
gpg-interface: add minTrustLevel as a configuration option
Previously, signature verification for merge and pull operations checked
if the key had a trust-level of either TRUST_NEVER or TRUST_UNDEFINED in
verify_merge_signature(). If that was the case, the process die()d.
The other code paths that did signature verification relied entirely on
the return code from check_commit_signature(). And signatures made with
a good key, irregardless of its trust level, was considered valid by
check_commit_signature().
This difference in behavior might induce users to erroneously assume
that the trust level of a key in their keyring is always considered by
Git, even for operations where it is not (e.g. during a verify-commit or
verify-tag).
The way it worked was by gpg-interface.c storing the result from the
key/signature status *and* the lowest-two trust levels in the `result`
member of the signature_check structure (the last of these status lines
that were encountered got written to `result`). These are documented in
GPG under the subsection `General status codes` and `Key related`,
respectively [1].
The GPG documentation says the following on the TRUST_ status codes [1]:
"""
These are several similar status codes:
- TRUST_UNDEFINED <error_token>
- TRUST_NEVER <error_token>
- TRUST_MARGINAL [0 [<validation_model>]]
- TRUST_FULLY [0 [<validation_model>]]
- TRUST_ULTIMATE [0 [<validation_model>]]
For good signatures one of these status lines are emitted to
indicate the validity of the key used to create the signature.
The error token values are currently only emitted by gpgsm.
"""
My interpretation is that the trust level is conceptionally different
from the validity of the key and/or signature. That seems to also have
been the assumption of the old code in check_signature() where a result
of 'G' (as in GOODSIG) and 'U' (as in TRUST_NEVER or TRUST_UNDEFINED)
were both considered a success.
The two cases where a result of 'U' had special meaning were in
verify_merge_signature() (where this caused git to die()) and in
format_commit_one() (where it affected the output of the %G? format
specifier).
I think it makes sense to refactor the processing of TRUST_ status lines
such that users can configure a minimum trust level that is enforced
globally, rather than have individual parts of git (e.g. merge) do it
themselves (except for a grace period with backward compatibility).
I also think it makes sense to not store the trust level in the same
struct member as the key/signature status. While the presence of a
TRUST_ status code does imply that the signature is good (see the first
paragraph in the included snippet above), as far as I can tell, the
order of the status lines from GPG isn't well-defined; thus it would
seem plausible that the trust level could be overwritten with the
key/signature status if they were stored in the same member of the
signature_check structure.
This patch introduces a new configuration option: gpg.minTrustLevel. It
consolidates trust-level verification to gpg-interface.c and adds a new
`trust_level` member to the signature_check structure.
Backward-compatibility is maintained by introducing a special case in
verify_merge_signature() such that if no user-configurable
gpg.minTrustLevel is set, then the old behavior of rejecting
TRUST_UNDEFINED and TRUST_NEVER is enforced. If, on the other hand,
gpg.minTrustLevel is set, then that value overrides the old behavior.
Similarly, the %G? format specifier will continue show 'U' for
signatures made with a key that has a trust level of TRUST_UNDEFINED or
TRUST_NEVER, even though the 'U' character no longer exist in the
`result` member of the signature_check structure. A new format
specifier, %GT, is also introduced for users that want to show all
possible trust levels for a signature.
Another approach would have been to simply drop the trust-level
requirement in verify_merge_signature(). This would also have made the
behavior consistent with other parts of git that perform signature
verification. However, requiring a minimum trust level for signing keys
does seem to have a real-world use-case. For example, the build system
used by the Qubes OS project currently parses the raw output from
verify-tag in order to assert a minimum trust level for keys used to
sign git tags [2].
[1] https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/doc/DETAILS;h=bd00006e933ac56719b1edd2478ecd79273eae72;hb=refs/heads/master
[2] https://github.com/QubesOS/qubes-builder/blob/9674c1991deef45b1a1b1c71fddfab14ba50dccf/scripts/verify-git-tag#L43
Signed-off-by: Hans Jerry Illikainen <hji@dyntopia.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-27 13:55:57 +00:00
|
|
|
status |= sigc->result != 'G';
|
|
|
|
status |= sigc->trust_level < configured_min_trust_level;
|
2015-06-21 23:14:38 +00:00
|
|
|
|
2018-08-09 18:40:27 +00:00
|
|
|
return !!status;
|
2015-06-21 23:14:38 +00:00
|
|
|
}
|
|
|
|
|
2015-06-21 23:14:41 +00:00
|
|
|
void print_signature_buffer(const struct signature_check *sigc, unsigned flags)
|
|
|
|
{
|
2021-09-10 20:07:34 +00:00
|
|
|
const char *output = flags & GPG_VERIFY_RAW ? sigc->gpg_status :
|
|
|
|
sigc->output;
|
2015-06-21 23:14:42 +00:00
|
|
|
|
2015-06-21 23:14:41 +00:00
|
|
|
if (flags & GPG_VERIFY_VERBOSE && sigc->payload)
|
2021-12-09 08:52:43 +00:00
|
|
|
fwrite(sigc->payload, 1, sigc->payload_len, stdout);
|
2015-06-21 23:14:41 +00:00
|
|
|
|
2015-06-21 23:14:42 +00:00
|
|
|
if (output)
|
|
|
|
fputs(output, stderr);
|
2015-06-21 23:14:41 +00:00
|
|
|
}
|
|
|
|
|
2021-02-11 02:08:03 +00:00
|
|
|
size_t parse_signed_buffer(const char *buf, size_t size)
|
2014-08-19 20:18:07 +00:00
|
|
|
{
|
|
|
|
size_t len = 0;
|
2018-04-13 21:18:35 +00:00
|
|
|
size_t match = size;
|
|
|
|
while (len < size) {
|
|
|
|
const char *eol;
|
|
|
|
|
2018-07-17 12:50:09 +00:00
|
|
|
if (get_format_by_sig(buf + len))
|
2018-04-13 21:18:35 +00:00
|
|
|
match = len;
|
|
|
|
|
|
|
|
eol = memchr(buf + len, '\n', size - len);
|
2014-08-19 20:18:07 +00:00
|
|
|
len += eol ? eol - (buf + len) + 1 : size - len;
|
|
|
|
}
|
2018-04-13 21:18:35 +00:00
|
|
|
return match;
|
2014-08-19 20:18:07 +00:00
|
|
|
}
|
|
|
|
|
2021-02-11 02:08:03 +00:00
|
|
|
int parse_signature(const char *buf, size_t size, struct strbuf *payload, struct strbuf *signature)
|
|
|
|
{
|
|
|
|
size_t match = parse_signed_buffer(buf, size);
|
|
|
|
if (match != size) {
|
|
|
|
strbuf_add(payload, buf, match);
|
2021-02-11 02:08:06 +00:00
|
|
|
remove_signature(payload);
|
2021-02-11 02:08:03 +00:00
|
|
|
strbuf_add(signature, buf + match, size - match);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-09-08 04:19:47 +00:00
|
|
|
void set_signing_key(const char *key)
|
|
|
|
{
|
2023-02-09 20:24:14 +00:00
|
|
|
gpg_interface_lazy_init();
|
|
|
|
|
2011-09-08 04:19:47 +00:00
|
|
|
free(configured_signing_key);
|
|
|
|
configured_signing_key = xstrdup(key);
|
|
|
|
}
|
|
|
|
|
config: add ctx arg to config_fn_t
Add a new "const struct config_context *ctx" arg to config_fn_t to hold
additional information about the config iteration operation.
config_context has a "struct key_value_info kvi" member that holds
metadata about the config source being read (e.g. what kind of config
source it is, the filename, etc). In this series, we're only interested
in .kvi, so we could have just used "struct key_value_info" as an arg,
but config_context makes it possible to add/adjust members in the future
without changing the config_fn_t signature. We could also consider other
ways of organizing the args (e.g. moving the config name and value into
config_context or key_value_info), but in my experiments, the
incremental benefit doesn't justify the added complexity (e.g. a
config_fn_t will sometimes invoke another config_fn_t but with a
different config value).
In subsequent commits, the .kvi member will replace the global "struct
config_reader" in config.c, making config iteration a global-free
operation. It requires much more work for the machinery to provide
meaningful values of .kvi, so for now, merely change the signature and
call sites, pass NULL as a placeholder value, and don't rely on the arg
in any meaningful way.
Most of the changes are performed by
contrib/coccinelle/config_fn_ctx.pending.cocci, which, for every
config_fn_t:
- Modifies the signature to accept "const struct config_context *ctx"
- Passes "ctx" to any inner config_fn_t, if needed
- Adds UNUSED attributes to "ctx", if needed
Most config_fn_t instances are easily identified by seeing if they are
called by the various config functions. Most of the remaining ones are
manually named in the .cocci patch. Manual cleanups are still needed,
but the majority of it is trivial; it's either adjusting config_fn_t
that the .cocci patch didn't catch, or adding forward declarations of
"struct config_context ctx" to make the signatures make sense.
The non-trivial changes are in cases where we are invoking a config_fn_t
outside of config machinery, and we now need to decide what value of
"ctx" to pass. These cases are:
- trace2/tr2_cfg.c:tr2_cfg_set_fl()
This is indirectly called by git_config_set() so that the trace2
machinery can notice the new config values and update its settings
using the tr2 config parsing function, i.e. tr2_cfg_cb().
- builtin/checkout.c:checkout_main()
This calls git_xmerge_config() as a shorthand for parsing a CLI arg.
This might be worth refactoring away in the future, since
git_xmerge_config() can call git_default_config(), which can do much
more than just parsing.
Handle them by creating a KVI_INIT macro that initializes "struct
key_value_info" to a reasonable default, and use that to construct the
"ctx" arg.
Signed-off-by: Glen Choo <chooglen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-06-28 19:26:22 +00:00
|
|
|
static int git_gpg_config(const char *var, const char *value,
|
|
|
|
const struct config_context *ctx UNUSED,
|
|
|
|
void *cb UNUSED)
|
2011-09-08 04:19:47 +00:00
|
|
|
{
|
2018-07-17 12:50:09 +00:00
|
|
|
struct gpg_format *fmt = NULL;
|
|
|
|
char *fmtname = NULL;
|
gpg-interface: add minTrustLevel as a configuration option
Previously, signature verification for merge and pull operations checked
if the key had a trust-level of either TRUST_NEVER or TRUST_UNDEFINED in
verify_merge_signature(). If that was the case, the process die()d.
The other code paths that did signature verification relied entirely on
the return code from check_commit_signature(). And signatures made with
a good key, irregardless of its trust level, was considered valid by
check_commit_signature().
This difference in behavior might induce users to erroneously assume
that the trust level of a key in their keyring is always considered by
Git, even for operations where it is not (e.g. during a verify-commit or
verify-tag).
The way it worked was by gpg-interface.c storing the result from the
key/signature status *and* the lowest-two trust levels in the `result`
member of the signature_check structure (the last of these status lines
that were encountered got written to `result`). These are documented in
GPG under the subsection `General status codes` and `Key related`,
respectively [1].
The GPG documentation says the following on the TRUST_ status codes [1]:
"""
These are several similar status codes:
- TRUST_UNDEFINED <error_token>
- TRUST_NEVER <error_token>
- TRUST_MARGINAL [0 [<validation_model>]]
- TRUST_FULLY [0 [<validation_model>]]
- TRUST_ULTIMATE [0 [<validation_model>]]
For good signatures one of these status lines are emitted to
indicate the validity of the key used to create the signature.
The error token values are currently only emitted by gpgsm.
"""
My interpretation is that the trust level is conceptionally different
from the validity of the key and/or signature. That seems to also have
been the assumption of the old code in check_signature() where a result
of 'G' (as in GOODSIG) and 'U' (as in TRUST_NEVER or TRUST_UNDEFINED)
were both considered a success.
The two cases where a result of 'U' had special meaning were in
verify_merge_signature() (where this caused git to die()) and in
format_commit_one() (where it affected the output of the %G? format
specifier).
I think it makes sense to refactor the processing of TRUST_ status lines
such that users can configure a minimum trust level that is enforced
globally, rather than have individual parts of git (e.g. merge) do it
themselves (except for a grace period with backward compatibility).
I also think it makes sense to not store the trust level in the same
struct member as the key/signature status. While the presence of a
TRUST_ status code does imply that the signature is good (see the first
paragraph in the included snippet above), as far as I can tell, the
order of the status lines from GPG isn't well-defined; thus it would
seem plausible that the trust level could be overwritten with the
key/signature status if they were stored in the same member of the
signature_check structure.
This patch introduces a new configuration option: gpg.minTrustLevel. It
consolidates trust-level verification to gpg-interface.c and adds a new
`trust_level` member to the signature_check structure.
Backward-compatibility is maintained by introducing a special case in
verify_merge_signature() such that if no user-configurable
gpg.minTrustLevel is set, then the old behavior of rejecting
TRUST_UNDEFINED and TRUST_NEVER is enforced. If, on the other hand,
gpg.minTrustLevel is set, then that value overrides the old behavior.
Similarly, the %G? format specifier will continue show 'U' for
signatures made with a key that has a trust level of TRUST_UNDEFINED or
TRUST_NEVER, even though the 'U' character no longer exist in the
`result` member of the signature_check structure. A new format
specifier, %GT, is also introduced for users that want to show all
possible trust levels for a signature.
Another approach would have been to simply drop the trust-level
requirement in verify_merge_signature(). This would also have made the
behavior consistent with other parts of git that perform signature
verification. However, requiring a minimum trust level for signing keys
does seem to have a real-world use-case. For example, the build system
used by the Qubes OS project currently parses the raw output from
verify-tag in order to assert a minimum trust level for keys used to
sign git tags [2].
[1] https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/doc/DETAILS;h=bd00006e933ac56719b1edd2478ecd79273eae72;hb=refs/heads/master
[2] https://github.com/QubesOS/qubes-builder/blob/9674c1991deef45b1a1b1c71fddfab14ba50dccf/scripts/verify-git-tag#L43
Signed-off-by: Hans Jerry Illikainen <hji@dyntopia.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-27 13:55:57 +00:00
|
|
|
char *trust;
|
|
|
|
int ret;
|
2018-07-17 12:50:09 +00:00
|
|
|
|
2011-09-08 04:19:47 +00:00
|
|
|
if (!strcmp(var, "user.signingkey")) {
|
2018-04-13 21:18:30 +00:00
|
|
|
if (!value)
|
|
|
|
return config_error_nonbool(var);
|
2011-11-29 20:29:48 +00:00
|
|
|
set_signing_key(value);
|
2018-04-13 21:18:30 +00:00
|
|
|
return 0;
|
2011-11-29 20:29:48 +00:00
|
|
|
}
|
2018-04-13 21:18:30 +00:00
|
|
|
|
2018-07-17 12:50:07 +00:00
|
|
|
if (!strcmp(var, "gpg.format")) {
|
|
|
|
if (!value)
|
|
|
|
return config_error_nonbool(var);
|
2018-07-17 12:50:09 +00:00
|
|
|
fmt = get_format_by_name(value);
|
|
|
|
if (!fmt)
|
2022-01-31 22:07:47 +00:00
|
|
|
return error(_("invalid value for '%s': '%s'"),
|
2018-07-17 12:50:07 +00:00
|
|
|
var, value);
|
2018-07-17 12:50:09 +00:00
|
|
|
use_format = fmt;
|
|
|
|
return 0;
|
2018-07-17 12:50:07 +00:00
|
|
|
}
|
|
|
|
|
gpg-interface: add minTrustLevel as a configuration option
Previously, signature verification for merge and pull operations checked
if the key had a trust-level of either TRUST_NEVER or TRUST_UNDEFINED in
verify_merge_signature(). If that was the case, the process die()d.
The other code paths that did signature verification relied entirely on
the return code from check_commit_signature(). And signatures made with
a good key, irregardless of its trust level, was considered valid by
check_commit_signature().
This difference in behavior might induce users to erroneously assume
that the trust level of a key in their keyring is always considered by
Git, even for operations where it is not (e.g. during a verify-commit or
verify-tag).
The way it worked was by gpg-interface.c storing the result from the
key/signature status *and* the lowest-two trust levels in the `result`
member of the signature_check structure (the last of these status lines
that were encountered got written to `result`). These are documented in
GPG under the subsection `General status codes` and `Key related`,
respectively [1].
The GPG documentation says the following on the TRUST_ status codes [1]:
"""
These are several similar status codes:
- TRUST_UNDEFINED <error_token>
- TRUST_NEVER <error_token>
- TRUST_MARGINAL [0 [<validation_model>]]
- TRUST_FULLY [0 [<validation_model>]]
- TRUST_ULTIMATE [0 [<validation_model>]]
For good signatures one of these status lines are emitted to
indicate the validity of the key used to create the signature.
The error token values are currently only emitted by gpgsm.
"""
My interpretation is that the trust level is conceptionally different
from the validity of the key and/or signature. That seems to also have
been the assumption of the old code in check_signature() where a result
of 'G' (as in GOODSIG) and 'U' (as in TRUST_NEVER or TRUST_UNDEFINED)
were both considered a success.
The two cases where a result of 'U' had special meaning were in
verify_merge_signature() (where this caused git to die()) and in
format_commit_one() (where it affected the output of the %G? format
specifier).
I think it makes sense to refactor the processing of TRUST_ status lines
such that users can configure a minimum trust level that is enforced
globally, rather than have individual parts of git (e.g. merge) do it
themselves (except for a grace period with backward compatibility).
I also think it makes sense to not store the trust level in the same
struct member as the key/signature status. While the presence of a
TRUST_ status code does imply that the signature is good (see the first
paragraph in the included snippet above), as far as I can tell, the
order of the status lines from GPG isn't well-defined; thus it would
seem plausible that the trust level could be overwritten with the
key/signature status if they were stored in the same member of the
signature_check structure.
This patch introduces a new configuration option: gpg.minTrustLevel. It
consolidates trust-level verification to gpg-interface.c and adds a new
`trust_level` member to the signature_check structure.
Backward-compatibility is maintained by introducing a special case in
verify_merge_signature() such that if no user-configurable
gpg.minTrustLevel is set, then the old behavior of rejecting
TRUST_UNDEFINED and TRUST_NEVER is enforced. If, on the other hand,
gpg.minTrustLevel is set, then that value overrides the old behavior.
Similarly, the %G? format specifier will continue show 'U' for
signatures made with a key that has a trust level of TRUST_UNDEFINED or
TRUST_NEVER, even though the 'U' character no longer exist in the
`result` member of the signature_check structure. A new format
specifier, %GT, is also introduced for users that want to show all
possible trust levels for a signature.
Another approach would have been to simply drop the trust-level
requirement in verify_merge_signature(). This would also have made the
behavior consistent with other parts of git that perform signature
verification. However, requiring a minimum trust level for signing keys
does seem to have a real-world use-case. For example, the build system
used by the Qubes OS project currently parses the raw output from
verify-tag in order to assert a minimum trust level for keys used to
sign git tags [2].
[1] https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/doc/DETAILS;h=bd00006e933ac56719b1edd2478ecd79273eae72;hb=refs/heads/master
[2] https://github.com/QubesOS/qubes-builder/blob/9674c1991deef45b1a1b1c71fddfab14ba50dccf/scripts/verify-git-tag#L43
Signed-off-by: Hans Jerry Illikainen <hji@dyntopia.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-27 13:55:57 +00:00
|
|
|
if (!strcmp(var, "gpg.mintrustlevel")) {
|
|
|
|
if (!value)
|
|
|
|
return config_error_nonbool(var);
|
|
|
|
|
|
|
|
trust = xstrdup_toupper(value);
|
|
|
|
ret = parse_gpg_trust_level(trust, &configured_min_trust_level);
|
|
|
|
free(trust);
|
|
|
|
|
|
|
|
if (ret)
|
2022-01-31 22:07:47 +00:00
|
|
|
return error(_("invalid value for '%s': '%s'"),
|
|
|
|
var, value);
|
gpg-interface: add minTrustLevel as a configuration option
Previously, signature verification for merge and pull operations checked
if the key had a trust-level of either TRUST_NEVER or TRUST_UNDEFINED in
verify_merge_signature(). If that was the case, the process die()d.
The other code paths that did signature verification relied entirely on
the return code from check_commit_signature(). And signatures made with
a good key, irregardless of its trust level, was considered valid by
check_commit_signature().
This difference in behavior might induce users to erroneously assume
that the trust level of a key in their keyring is always considered by
Git, even for operations where it is not (e.g. during a verify-commit or
verify-tag).
The way it worked was by gpg-interface.c storing the result from the
key/signature status *and* the lowest-two trust levels in the `result`
member of the signature_check structure (the last of these status lines
that were encountered got written to `result`). These are documented in
GPG under the subsection `General status codes` and `Key related`,
respectively [1].
The GPG documentation says the following on the TRUST_ status codes [1]:
"""
These are several similar status codes:
- TRUST_UNDEFINED <error_token>
- TRUST_NEVER <error_token>
- TRUST_MARGINAL [0 [<validation_model>]]
- TRUST_FULLY [0 [<validation_model>]]
- TRUST_ULTIMATE [0 [<validation_model>]]
For good signatures one of these status lines are emitted to
indicate the validity of the key used to create the signature.
The error token values are currently only emitted by gpgsm.
"""
My interpretation is that the trust level is conceptionally different
from the validity of the key and/or signature. That seems to also have
been the assumption of the old code in check_signature() where a result
of 'G' (as in GOODSIG) and 'U' (as in TRUST_NEVER or TRUST_UNDEFINED)
were both considered a success.
The two cases where a result of 'U' had special meaning were in
verify_merge_signature() (where this caused git to die()) and in
format_commit_one() (where it affected the output of the %G? format
specifier).
I think it makes sense to refactor the processing of TRUST_ status lines
such that users can configure a minimum trust level that is enforced
globally, rather than have individual parts of git (e.g. merge) do it
themselves (except for a grace period with backward compatibility).
I also think it makes sense to not store the trust level in the same
struct member as the key/signature status. While the presence of a
TRUST_ status code does imply that the signature is good (see the first
paragraph in the included snippet above), as far as I can tell, the
order of the status lines from GPG isn't well-defined; thus it would
seem plausible that the trust level could be overwritten with the
key/signature status if they were stored in the same member of the
signature_check structure.
This patch introduces a new configuration option: gpg.minTrustLevel. It
consolidates trust-level verification to gpg-interface.c and adds a new
`trust_level` member to the signature_check structure.
Backward-compatibility is maintained by introducing a special case in
verify_merge_signature() such that if no user-configurable
gpg.minTrustLevel is set, then the old behavior of rejecting
TRUST_UNDEFINED and TRUST_NEVER is enforced. If, on the other hand,
gpg.minTrustLevel is set, then that value overrides the old behavior.
Similarly, the %G? format specifier will continue show 'U' for
signatures made with a key that has a trust level of TRUST_UNDEFINED or
TRUST_NEVER, even though the 'U' character no longer exist in the
`result` member of the signature_check structure. A new format
specifier, %GT, is also introduced for users that want to show all
possible trust levels for a signature.
Another approach would have been to simply drop the trust-level
requirement in verify_merge_signature(). This would also have made the
behavior consistent with other parts of git that perform signature
verification. However, requiring a minimum trust level for signing keys
does seem to have a real-world use-case. For example, the build system
used by the Qubes OS project currently parses the raw output from
verify-tag in order to assert a minimum trust level for keys used to
sign git tags [2].
[1] https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/doc/DETAILS;h=bd00006e933ac56719b1edd2478ecd79273eae72;hb=refs/heads/master
[2] https://github.com/QubesOS/qubes-builder/blob/9674c1991deef45b1a1b1c71fddfab14ba50dccf/scripts/verify-git-tag#L43
Signed-off-by: Hans Jerry Illikainen <hji@dyntopia.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-27 13:55:57 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2023-12-07 07:26:31 +00:00
|
|
|
if (!strcmp(var, "gpg.ssh.defaultkeycommand"))
|
2021-09-10 20:07:37 +00:00
|
|
|
return git_config_string(&ssh_default_key_command, var, value);
|
|
|
|
|
2023-12-07 07:26:31 +00:00
|
|
|
if (!strcmp(var, "gpg.ssh.allowedsignersfile"))
|
2021-09-10 20:07:39 +00:00
|
|
|
return git_config_pathname(&ssh_allowed_signers, var, value);
|
|
|
|
|
2023-12-07 07:26:31 +00:00
|
|
|
if (!strcmp(var, "gpg.ssh.revocationfile"))
|
2021-09-10 20:07:39 +00:00
|
|
|
return git_config_pathname(&ssh_revocation_file, var, value);
|
|
|
|
|
2018-07-17 12:50:11 +00:00
|
|
|
if (!strcmp(var, "gpg.program") || !strcmp(var, "gpg.openpgp.program"))
|
2018-07-17 12:50:09 +00:00
|
|
|
fmtname = "openpgp";
|
|
|
|
|
2018-07-17 12:50:12 +00:00
|
|
|
if (!strcmp(var, "gpg.x509.program"))
|
|
|
|
fmtname = "x509";
|
|
|
|
|
2021-09-10 20:07:36 +00:00
|
|
|
if (!strcmp(var, "gpg.ssh.program"))
|
|
|
|
fmtname = "ssh";
|
|
|
|
|
2018-07-17 12:50:09 +00:00
|
|
|
if (fmtname) {
|
|
|
|
fmt = get_format_by_name(fmtname);
|
|
|
|
return git_config_string(&fmt->program, var, value);
|
2011-09-08 04:19:47 +00:00
|
|
|
}
|
2018-04-13 21:18:30 +00:00
|
|
|
|
2011-09-08 04:19:47 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-11-19 15:07:06 +00:00
|
|
|
/*
|
|
|
|
* Returns 1 if `string` contains a literal ssh key, 0 otherwise
|
|
|
|
* `key` will be set to the start of the actual key if a prefix is present.
|
|
|
|
*/
|
|
|
|
static int is_literal_ssh_key(const char *string, const char **key)
|
|
|
|
{
|
|
|
|
if (skip_prefix(string, "key::", key))
|
|
|
|
return 1;
|
|
|
|
if (starts_with(string, "ssh-")) {
|
|
|
|
*key = string;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-09-10 20:07:38 +00:00
|
|
|
static char *get_ssh_key_fingerprint(const char *signing_key)
|
|
|
|
{
|
|
|
|
struct child_process ssh_keygen = CHILD_PROCESS_INIT;
|
|
|
|
int ret = -1;
|
|
|
|
struct strbuf fingerprint_stdout = STRBUF_INIT;
|
|
|
|
struct strbuf **fingerprint;
|
2021-10-18 17:15:37 +00:00
|
|
|
char *fingerprint_ret;
|
2021-11-19 15:07:06 +00:00
|
|
|
const char *literal_key = NULL;
|
2021-09-10 20:07:38 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* With SSH Signing this can contain a filename or a public key
|
|
|
|
* For textual representation we usually want a fingerprint
|
|
|
|
*/
|
2021-11-19 15:07:06 +00:00
|
|
|
if (is_literal_ssh_key(signing_key, &literal_key)) {
|
2021-09-10 20:07:38 +00:00
|
|
|
strvec_pushl(&ssh_keygen.args, "ssh-keygen", "-lf", "-", NULL);
|
2021-11-19 15:07:06 +00:00
|
|
|
ret = pipe_command(&ssh_keygen, literal_key,
|
|
|
|
strlen(literal_key), &fingerprint_stdout, 0,
|
2021-09-10 20:07:38 +00:00
|
|
|
NULL, 0);
|
|
|
|
} else {
|
|
|
|
strvec_pushl(&ssh_keygen.args, "ssh-keygen", "-lf",
|
|
|
|
configured_signing_key, NULL);
|
|
|
|
ret = pipe_command(&ssh_keygen, NULL, 0, &fingerprint_stdout, 0,
|
|
|
|
NULL, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!!ret)
|
|
|
|
die_errno(_("failed to get the ssh fingerprint for key '%s'"),
|
|
|
|
signing_key);
|
|
|
|
|
|
|
|
fingerprint = strbuf_split_max(&fingerprint_stdout, ' ', 3);
|
|
|
|
if (!fingerprint[1])
|
|
|
|
die_errno(_("failed to get the ssh fingerprint for key '%s'"),
|
|
|
|
signing_key);
|
|
|
|
|
2021-10-18 17:15:37 +00:00
|
|
|
fingerprint_ret = strbuf_detach(fingerprint[1], NULL);
|
|
|
|
strbuf_list_free(fingerprint);
|
|
|
|
strbuf_release(&fingerprint_stdout);
|
|
|
|
return fingerprint_ret;
|
2021-09-10 20:07:38 +00:00
|
|
|
}
|
|
|
|
|
2021-09-10 20:07:37 +00:00
|
|
|
/* Returns the first public key from an ssh-agent to use for signing */
|
|
|
|
static const char *get_default_ssh_signing_key(void)
|
|
|
|
{
|
|
|
|
struct child_process ssh_default_key = CHILD_PROCESS_INIT;
|
|
|
|
int ret = -1;
|
|
|
|
struct strbuf key_stdout = STRBUF_INIT, key_stderr = STRBUF_INIT;
|
|
|
|
struct strbuf **keys;
|
|
|
|
char *key_command = NULL;
|
|
|
|
const char **argv;
|
|
|
|
int n;
|
|
|
|
char *default_key = NULL;
|
2021-11-19 15:07:06 +00:00
|
|
|
const char *literal_key = NULL;
|
2021-09-10 20:07:37 +00:00
|
|
|
|
|
|
|
if (!ssh_default_key_command)
|
|
|
|
die(_("either user.signingkey or gpg.ssh.defaultKeyCommand needs to be configured"));
|
|
|
|
|
|
|
|
key_command = xstrdup(ssh_default_key_command);
|
|
|
|
n = split_cmdline(key_command, &argv);
|
|
|
|
|
|
|
|
if (n < 0)
|
|
|
|
die("malformed build-time gpg.ssh.defaultKeyCommand: %s",
|
|
|
|
split_cmdline_strerror(n));
|
|
|
|
|
|
|
|
strvec_pushv(&ssh_default_key.args, argv);
|
|
|
|
ret = pipe_command(&ssh_default_key, NULL, 0, &key_stdout, 0,
|
|
|
|
&key_stderr, 0);
|
|
|
|
|
|
|
|
if (!ret) {
|
|
|
|
keys = strbuf_split_max(&key_stdout, '\n', 2);
|
2021-11-19 15:07:06 +00:00
|
|
|
if (keys[0] && is_literal_ssh_key(keys[0]->buf, &literal_key)) {
|
|
|
|
/*
|
|
|
|
* We only use `is_literal_ssh_key` here to check validity
|
|
|
|
* The prefix will be stripped when the key is used.
|
|
|
|
*/
|
2021-09-10 20:07:37 +00:00
|
|
|
default_key = strbuf_detach(keys[0], NULL);
|
|
|
|
} else {
|
2021-11-01 02:14:17 +00:00
|
|
|
warning(_("gpg.ssh.defaultKeyCommand succeeded but returned no keys: %s %s"),
|
2021-09-10 20:07:37 +00:00
|
|
|
key_stderr.buf, key_stdout.buf);
|
|
|
|
}
|
|
|
|
|
|
|
|
strbuf_list_free(keys);
|
|
|
|
} else {
|
|
|
|
warning(_("gpg.ssh.defaultKeyCommand failed: %s %s"),
|
|
|
|
key_stderr.buf, key_stdout.buf);
|
|
|
|
}
|
|
|
|
|
|
|
|
free(key_command);
|
|
|
|
free(argv);
|
|
|
|
strbuf_release(&key_stdout);
|
|
|
|
|
|
|
|
return default_key;
|
|
|
|
}
|
|
|
|
|
2021-09-10 20:07:38 +00:00
|
|
|
static const char *get_ssh_key_id(void) {
|
|
|
|
return get_ssh_key_fingerprint(get_signing_key());
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Returns a textual but unique representation of the signing key */
|
|
|
|
const char *get_signing_key_id(void)
|
|
|
|
{
|
2023-02-09 20:24:14 +00:00
|
|
|
gpg_interface_lazy_init();
|
|
|
|
|
2021-09-10 20:07:38 +00:00
|
|
|
if (use_format->get_key_id) {
|
|
|
|
return use_format->get_key_id();
|
|
|
|
}
|
|
|
|
|
|
|
|
/* GPG/GPGSM only store a key id on this variable */
|
|
|
|
return get_signing_key();
|
|
|
|
}
|
|
|
|
|
2011-09-08 04:19:47 +00:00
|
|
|
const char *get_signing_key(void)
|
|
|
|
{
|
2023-02-09 20:24:14 +00:00
|
|
|
gpg_interface_lazy_init();
|
|
|
|
|
2011-09-08 04:19:47 +00:00
|
|
|
if (configured_signing_key)
|
|
|
|
return configured_signing_key;
|
2021-09-10 20:07:37 +00:00
|
|
|
if (use_format->get_default_key) {
|
|
|
|
return use_format->get_default_key();
|
|
|
|
}
|
|
|
|
|
|
|
|
return git_committer_info(IDENT_STRICT | IDENT_NO_DATE);
|
2011-09-08 04:19:47 +00:00
|
|
|
}
|
|
|
|
|
2022-07-11 05:00:50 +00:00
|
|
|
const char *gpg_trust_level_to_str(enum signature_trust_level level)
|
|
|
|
{
|
|
|
|
struct sigcheck_gpg_trust_level *trust;
|
|
|
|
|
|
|
|
if (level < 0 || level >= ARRAY_SIZE(sigcheck_gpg_trust_level))
|
|
|
|
BUG("invalid trust level requested %d", level);
|
|
|
|
|
|
|
|
trust = &sigcheck_gpg_trust_level[level];
|
|
|
|
if (trust->value != level)
|
|
|
|
BUG("sigcheck_gpg_trust_level[] unsorted");
|
|
|
|
|
|
|
|
return sigcheck_gpg_trust_level[level].display_key;
|
|
|
|
}
|
|
|
|
|
2011-09-08 04:19:47 +00:00
|
|
|
int sign_buffer(struct strbuf *buffer, struct strbuf *signature, const char *signing_key)
|
2021-09-10 20:07:34 +00:00
|
|
|
{
|
2023-02-09 20:24:14 +00:00
|
|
|
gpg_interface_lazy_init();
|
|
|
|
|
2021-09-10 20:07:34 +00:00
|
|
|
return use_format->sign_buffer(buffer, signature, signing_key);
|
|
|
|
}
|
|
|
|
|
2021-09-10 20:07:36 +00:00
|
|
|
/*
|
|
|
|
* Strip CR from the line endings, in case we are on Windows.
|
|
|
|
* NEEDSWORK: make it trim only CRs before LFs and rename
|
|
|
|
*/
|
|
|
|
static void remove_cr_after(struct strbuf *buffer, size_t offset)
|
|
|
|
{
|
|
|
|
size_t i, j;
|
|
|
|
|
|
|
|
for (i = j = offset; i < buffer->len; i++) {
|
|
|
|
if (buffer->buf[i] != '\r') {
|
|
|
|
if (i != j)
|
|
|
|
buffer->buf[j] = buffer->buf[i];
|
|
|
|
j++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
strbuf_setlen(buffer, j);
|
|
|
|
}
|
|
|
|
|
2021-09-10 20:07:34 +00:00
|
|
|
static int sign_buffer_gpg(struct strbuf *buffer, struct strbuf *signature,
|
|
|
|
const char *signing_key)
|
2011-09-08 04:19:47 +00:00
|
|
|
{
|
2014-08-19 19:09:35 +00:00
|
|
|
struct child_process gpg = CHILD_PROCESS_INIT;
|
sign_buffer: use pipe_command
Similar to the prior commit for verify_signed_buffer, the
motivation here is both to make the code simpler, and to
avoid any possible deadlocks with gpg.
In this case we have the same "write to stdin, then read
from stdout" that the verify case had. This is unlikely to
be a problem in practice, since stdout has the detached
signature, which it cannot compute until it has read all of
stdin (if it were a non-detached signature, that would be a
problem, though).
We don't read from stderr at all currently. However, we will
want to in a future patch, so this also prepares us there
(and in that case gpg _does_ write before reading all of the
input, though again, it is unlikely that a key uid will fill
up a pipe buffer).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-17 23:38:55 +00:00
|
|
|
int ret;
|
2021-09-10 20:07:36 +00:00
|
|
|
size_t bottom;
|
2022-03-04 10:25:17 +00:00
|
|
|
const char *cp;
|
2016-06-17 23:38:59 +00:00
|
|
|
struct strbuf gpg_status = STRBUF_INIT;
|
2011-09-08 04:19:47 +00:00
|
|
|
|
2020-07-28 20:24:53 +00:00
|
|
|
strvec_pushl(&gpg.args,
|
strvec: fix indentation in renamed calls
Code which split an argv_array call across multiple lines, like:
argv_array_pushl(&args, "one argument",
"another argument", "and more",
NULL);
was recently mechanically renamed to use strvec, which results in
mis-matched indentation like:
strvec_pushl(&args, "one argument",
"another argument", "and more",
NULL);
Let's fix these up to align the arguments with the opening paren. I did
this manually by sifting through the results of:
git jump grep 'strvec_.*,$'
and liberally applying my editor's auto-format. Most of the changes are
of the form shown above, though I also normalized a few that had
originally used a single-tab indentation (rather than our usual style of
aligning with the open paren). I also rewrapped a couple of obvious
cases (e.g., where previously too-long lines became short enough to fit
on one), but I wasn't aggressive about it. In cases broken to three or
more lines, the grouping of arguments is sometimes meaningful, and it
wasn't worth my time or reviewer time to ponder each case individually.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-28 20:26:31 +00:00
|
|
|
use_format->program,
|
|
|
|
"--status-fd=2",
|
|
|
|
"-bsau", signing_key,
|
|
|
|
NULL);
|
2011-09-08 04:19:47 +00:00
|
|
|
|
sign_buffer: use pipe_command
Similar to the prior commit for verify_signed_buffer, the
motivation here is both to make the code simpler, and to
avoid any possible deadlocks with gpg.
In this case we have the same "write to stdin, then read
from stdout" that the verify case had. This is unlikely to
be a problem in practice, since stdout has the detached
signature, which it cannot compute until it has read all of
stdin (if it were a non-detached signature, that would be a
problem, though).
We don't read from stderr at all currently. However, we will
want to in a future patch, so this also prepares us there
(and in that case gpg _does_ write before reading all of the
input, though again, it is unlikely that a key uid will fill
up a pipe buffer).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-17 23:38:55 +00:00
|
|
|
bottom = signature->len;
|
2011-09-08 04:19:47 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* When the username signingkey is bad, program could be terminated
|
|
|
|
* because gpg exits without reading and then write gets SIGPIPE.
|
|
|
|
*/
|
|
|
|
sigchain_push(SIGPIPE, SIG_IGN);
|
sign_buffer: use pipe_command
Similar to the prior commit for verify_signed_buffer, the
motivation here is both to make the code simpler, and to
avoid any possible deadlocks with gpg.
In this case we have the same "write to stdin, then read
from stdout" that the verify case had. This is unlikely to
be a problem in practice, since stdout has the detached
signature, which it cannot compute until it has read all of
stdin (if it were a non-detached signature, that would be a
problem, though).
We don't read from stderr at all currently. However, we will
want to in a future patch, so this also prepares us there
(and in that case gpg _does_ write before reading all of the
input, though again, it is unlikely that a key uid will fill
up a pipe buffer).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-17 23:38:55 +00:00
|
|
|
ret = pipe_command(&gpg, buffer->buf, buffer->len,
|
2016-06-17 23:38:59 +00:00
|
|
|
signature, 1024, &gpg_status, 0);
|
2011-09-08 04:19:47 +00:00
|
|
|
sigchain_pop(SIGPIPE);
|
|
|
|
|
2022-03-04 10:25:17 +00:00
|
|
|
for (cp = gpg_status.buf;
|
|
|
|
cp && (cp = strstr(cp, "[GNUPG:] SIG_CREATED "));
|
|
|
|
cp++) {
|
|
|
|
if (cp == gpg_status.buf || cp[-1] == '\n')
|
|
|
|
break; /* found */
|
|
|
|
}
|
|
|
|
ret |= !cp;
|
2023-02-15 05:58:34 +00:00
|
|
|
if (ret) {
|
|
|
|
error(_("gpg failed to sign the data:\n%s"),
|
|
|
|
gpg_status.len ? gpg_status.buf : "(no gpg output)");
|
|
|
|
strbuf_release(&gpg_status);
|
|
|
|
return -1;
|
|
|
|
}
|
2016-06-17 23:38:59 +00:00
|
|
|
strbuf_release(&gpg_status);
|
2011-09-08 04:19:47 +00:00
|
|
|
|
|
|
|
/* Strip CR from the line endings, in case we are on Windows. */
|
2021-09-10 20:07:36 +00:00
|
|
|
remove_cr_after(signature, bottom);
|
2011-09-08 04:19:47 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2021-09-10 20:07:36 +00:00
|
|
|
|
|
|
|
static int sign_buffer_ssh(struct strbuf *buffer, struct strbuf *signature,
|
|
|
|
const char *signing_key)
|
|
|
|
{
|
|
|
|
struct child_process signer = CHILD_PROCESS_INIT;
|
|
|
|
int ret = -1;
|
|
|
|
size_t bottom, keylen;
|
|
|
|
struct strbuf signer_stderr = STRBUF_INIT;
|
|
|
|
struct tempfile *key_file = NULL, *buffer_file = NULL;
|
|
|
|
char *ssh_signing_key_file = NULL;
|
|
|
|
struct strbuf ssh_signature_filename = STRBUF_INIT;
|
2021-11-19 15:07:06 +00:00
|
|
|
const char *literal_key = NULL;
|
2023-01-25 12:40:50 +00:00
|
|
|
int literal_ssh_key = 0;
|
2021-09-10 20:07:36 +00:00
|
|
|
|
|
|
|
if (!signing_key || signing_key[0] == '\0')
|
|
|
|
return error(
|
2022-06-17 10:03:09 +00:00
|
|
|
_("user.signingKey needs to be set for ssh signing"));
|
2021-09-10 20:07:36 +00:00
|
|
|
|
2021-11-19 15:07:06 +00:00
|
|
|
if (is_literal_ssh_key(signing_key, &literal_key)) {
|
2021-09-10 20:07:36 +00:00
|
|
|
/* A literal ssh key */
|
2023-01-25 12:40:50 +00:00
|
|
|
literal_ssh_key = 1;
|
2021-09-10 20:07:36 +00:00
|
|
|
key_file = mks_tempfile_t(".git_signing_key_tmpXXXXXX");
|
|
|
|
if (!key_file)
|
|
|
|
return error_errno(
|
|
|
|
_("could not create temporary file"));
|
2021-11-19 15:07:06 +00:00
|
|
|
keylen = strlen(literal_key);
|
|
|
|
if (write_in_full(key_file->fd, literal_key, keylen) < 0 ||
|
2021-09-10 20:07:36 +00:00
|
|
|
close_tempfile_gently(key_file) < 0) {
|
|
|
|
error_errno(_("failed writing ssh signing key to '%s'"),
|
|
|
|
key_file->filename.buf);
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
ssh_signing_key_file = strbuf_detach(&key_file->filename, NULL);
|
|
|
|
} else {
|
|
|
|
/* We assume a file */
|
2023-03-21 06:25:59 +00:00
|
|
|
ssh_signing_key_file = interpolate_path(signing_key, 1);
|
2021-09-10 20:07:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
buffer_file = mks_tempfile_t(".git_signing_buffer_tmpXXXXXX");
|
|
|
|
if (!buffer_file) {
|
|
|
|
error_errno(_("could not create temporary file"));
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (write_in_full(buffer_file->fd, buffer->buf, buffer->len) < 0 ||
|
|
|
|
close_tempfile_gently(buffer_file) < 0) {
|
|
|
|
error_errno(_("failed writing ssh signing key buffer to '%s'"),
|
|
|
|
buffer_file->filename.buf);
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
strvec_pushl(&signer.args, use_format->program,
|
|
|
|
"-Y", "sign",
|
|
|
|
"-n", "git",
|
|
|
|
"-f", ssh_signing_key_file,
|
|
|
|
NULL);
|
2023-01-25 12:40:50 +00:00
|
|
|
if (literal_ssh_key)
|
|
|
|
strvec_push(&signer.args, "-U");
|
|
|
|
strvec_push(&signer.args, buffer_file->filename.buf);
|
2021-09-10 20:07:36 +00:00
|
|
|
|
|
|
|
sigchain_push(SIGPIPE, SIG_IGN);
|
|
|
|
ret = pipe_command(&signer, NULL, 0, NULL, 0, &signer_stderr, 0);
|
|
|
|
sigchain_pop(SIGPIPE);
|
|
|
|
|
|
|
|
if (ret) {
|
|
|
|
if (strstr(signer_stderr.buf, "usage:"))
|
|
|
|
error(_("ssh-keygen -Y sign is needed for ssh signing (available in openssh version 8.2p1+)"));
|
|
|
|
|
2024-02-08 05:29:00 +00:00
|
|
|
ret = error("%s", signer_stderr.buf);
|
2021-09-10 20:07:36 +00:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
bottom = signature->len;
|
|
|
|
|
|
|
|
strbuf_addbuf(&ssh_signature_filename, &buffer_file->filename);
|
|
|
|
strbuf_addstr(&ssh_signature_filename, ".sig");
|
|
|
|
if (strbuf_read_file(signature, ssh_signature_filename.buf, 0) < 0) {
|
2022-10-04 10:01:34 +00:00
|
|
|
ret = error_errno(
|
2021-09-10 20:07:36 +00:00
|
|
|
_("failed reading ssh signing data buffer from '%s'"),
|
|
|
|
ssh_signature_filename.buf);
|
2022-10-04 10:01:34 +00:00
|
|
|
goto out;
|
2021-09-10 20:07:36 +00:00
|
|
|
}
|
|
|
|
/* Strip CR from the line endings, in case we are on Windows. */
|
|
|
|
remove_cr_after(signature, bottom);
|
|
|
|
|
|
|
|
out:
|
|
|
|
if (key_file)
|
|
|
|
delete_tempfile(&key_file);
|
|
|
|
if (buffer_file)
|
|
|
|
delete_tempfile(&buffer_file);
|
2022-10-04 10:01:34 +00:00
|
|
|
if (ssh_signature_filename.len)
|
|
|
|
unlink_or_warn(ssh_signature_filename.buf);
|
2021-09-10 20:07:36 +00:00
|
|
|
strbuf_release(&signer_stderr);
|
|
|
|
strbuf_release(&ssh_signature_filename);
|
|
|
|
FREE_AND_NULL(ssh_signing_key_file);
|
|
|
|
return ret;
|
|
|
|
}
|