2011-09-08 06:19:47 +02:00
|
|
|
#include "cache.h"
|
2021-02-11 03:08:06 +01:00
|
|
|
#include "commit.h"
|
2017-06-14 20:07:36 +02:00
|
|
|
#include "config.h"
|
2011-09-08 06:19:47 +02:00
|
|
|
#include "run-command.h"
|
|
|
|
#include "strbuf.h"
|
|
|
|
#include "gpg-interface.h"
|
|
|
|
#include "sigchain.h"
|
2016-06-18 01:38:43 +02:00
|
|
|
#include "tempfile.h"
|
2011-09-08 06:19:47 +02:00
|
|
|
|
|
|
|
static char *configured_signing_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 14:55:57 +01:00
|
|
|
static enum signature_trust_level configured_min_trust_level = TRUST_UNDEFINED;
|
|
|
|
|
2018-07-17 14:50:09 +02:00
|
|
|
struct gpg_format {
|
|
|
|
const char *name;
|
|
|
|
const char *program;
|
|
|
|
const char **verify_args;
|
|
|
|
const char **sigs;
|
|
|
|
};
|
|
|
|
|
|
|
|
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 14:50:12 +02:00
|
|
|
static const char *x509_verify_args[] = {
|
|
|
|
NULL
|
|
|
|
};
|
|
|
|
static const char *x509_sigs[] = {
|
|
|
|
"-----BEGIN SIGNED MESSAGE-----",
|
|
|
|
NULL
|
|
|
|
};
|
|
|
|
|
2018-07-17 14:50:09 +02:00
|
|
|
static struct gpg_format gpg_format[] = {
|
|
|
|
{ .name = "openpgp", .program = "gpg",
|
|
|
|
.verify_args = openpgp_verify_args,
|
|
|
|
.sigs = openpgp_sigs
|
|
|
|
},
|
2018-07-17 14:50:12 +02:00
|
|
|
{ .name = "x509", .program = "gpgsm",
|
|
|
|
.verify_args = x509_verify_args,
|
|
|
|
.sigs = x509_sigs
|
|
|
|
},
|
2018-07-17 14:50:09 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
static struct gpg_format *use_format = &gpg_format[0];
|
2011-09-08 06:19:47 +02:00
|
|
|
|
2018-07-17 14:50:09 +02: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 22:18:07 +02:00
|
|
|
|
2014-06-23 09:05:47 +02:00
|
|
|
void signature_check_clear(struct signature_check *sigc)
|
|
|
|
{
|
2017-06-16 01:15:49 +02:00
|
|
|
FREE_AND_NULL(sigc->payload);
|
|
|
|
FREE_AND_NULL(sigc->gpg_output);
|
|
|
|
FREE_AND_NULL(sigc->gpg_status);
|
|
|
|
FREE_AND_NULL(sigc->signer);
|
|
|
|
FREE_AND_NULL(sigc->key);
|
2018-10-22 18:38:20 +02:00
|
|
|
FREE_AND_NULL(sigc->fingerprint);
|
2018-10-22 18:38:21 +02:00
|
|
|
FREE_AND_NULL(sigc->primary_key_fingerprint);
|
2014-06-23 09:05:47 +02:00
|
|
|
}
|
|
|
|
|
2018-10-20 21:30:20 +02:00
|
|
|
/* An exclusive status -- only one of them can appear in output */
|
|
|
|
#define GPG_STATUS_EXCLUSIVE (1<<0)
|
2018-10-22 18:38:19 +02: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 18:38:20 +02: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 14:55:57 +01:00
|
|
|
/* The status includes trust level */
|
|
|
|
#define GPG_STATUS_TRUST_LEVEL (1<<4)
|
2018-10-22 18:38:19 +02: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 21:30:20 +02:00
|
|
|
|
2014-08-15 00:31:13 +02:00
|
|
|
static struct {
|
|
|
|
char result;
|
|
|
|
const char *check;
|
2018-10-20 21:30:20 +02:00
|
|
|
unsigned int flags;
|
2014-08-15 00:31:13 +02:00
|
|
|
} sigcheck_gpg_status[] = {
|
2018-10-22 18:38:19 +02: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 18:38:20 +02: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 14:55:57 +01:00
|
|
|
{ 0, "TRUST_", GPG_STATUS_TRUST_LEVEL },
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct {
|
|
|
|
const char *key;
|
|
|
|
enum signature_trust_level value;
|
|
|
|
} sigcheck_gpg_trust_level[] = {
|
|
|
|
{ "UNDEFINED", TRUST_UNDEFINED },
|
|
|
|
{ "NEVER", TRUST_NEVER },
|
|
|
|
{ "MARGINAL", TRUST_MARGINAL },
|
|
|
|
{ "FULLY", TRUST_FULLY },
|
|
|
|
{ "ULTIMATE", TRUST_ULTIMATE },
|
2014-08-15 00:31:13 +02:00
|
|
|
};
|
|
|
|
|
2019-11-22 00:43:35 +01: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 14:55:57 +01: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 10:38:25 +02:00
|
|
|
static void parse_gpg_output(struct signature_check *sigc)
|
2014-08-15 00:31:13 +02:00
|
|
|
{
|
|
|
|
const char *buf = sigc->gpg_status;
|
2018-10-20 21:30:20 +02:00
|
|
|
const char *line, *next;
|
2018-10-22 18:38:21 +02:00
|
|
|
int i, j;
|
2018-10-20 21:30:20 +02: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 20:47:37 +02:00
|
|
|
if (!*line)
|
|
|
|
break;
|
|
|
|
|
2018-10-20 21:30:20 +02: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 14:55:57 +01: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 21:30:20 +02:00
|
|
|
if (sigcheck_gpg_status[i].flags & GPG_STATUS_EXCLUSIVE) {
|
2018-11-02 16:53:57 +01: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 14:55:57 +01:00
|
|
|
goto error;
|
2018-10-20 21:30:20 +02:00
|
|
|
}
|
|
|
|
|
2018-10-22 18:38:20 +02:00
|
|
|
if (sigcheck_gpg_status[i].result)
|
|
|
|
sigc->result = sigcheck_gpg_status[i].result;
|
2018-10-22 18:38:19 +02:00
|
|
|
/* Do we have key information? */
|
|
|
|
if (sigcheck_gpg_status[i].flags & GPG_STATUS_KEYID) {
|
2018-10-20 21:30:20 +02:00
|
|
|
next = strchrnul(line, ' ');
|
2019-11-22 00:43:35 +01:00
|
|
|
replace_cstring(&sigc->key, line, next);
|
2018-10-22 18:38:19 +02:00
|
|
|
/* Do we have signer information? */
|
|
|
|
if (*next && (sigcheck_gpg_status[i].flags & GPG_STATUS_UID)) {
|
2018-10-20 21:30:20 +02:00
|
|
|
line = next + 1;
|
|
|
|
next = strchrnul(line, '\n');
|
2019-11-22 00:43:35 +01:00
|
|
|
replace_cstring(&sigc->signer, line, next);
|
2018-10-20 21:30:20 +02: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 14:55:57 +01: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 18:38:20 +02:00
|
|
|
/* Do we have fingerprint? */
|
|
|
|
if (sigcheck_gpg_status[i].flags & GPG_STATUS_FINGERPRINT) {
|
2019-11-22 21:23:12 +01:00
|
|
|
const char *limit;
|
|
|
|
char **field;
|
|
|
|
|
2018-10-22 18:38:20 +02:00
|
|
|
next = strchrnul(line, ' ');
|
2019-11-22 00:43:35 +01:00
|
|
|
replace_cstring(&sigc->fingerprint, line, next);
|
2018-10-22 18:38:21 +02:00
|
|
|
|
2019-11-22 21:23:12 +01: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 18:38:21 +02:00
|
|
|
for (j = 9; j > 0; j--) {
|
2019-11-22 21:23:12 +01:00
|
|
|
if (!*next || limit <= next)
|
2018-10-22 18:38:21 +02:00
|
|
|
break;
|
|
|
|
line = next + 1;
|
|
|
|
next = strchrnul(line, ' ');
|
|
|
|
}
|
|
|
|
|
2019-11-22 21:23:12 +01: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 18:38:20 +02:00
|
|
|
}
|
2018-10-20 21:30:20 +02: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 15:04:15 +02:00
|
|
|
}
|
2014-08-15 00:31:13 +02:00
|
|
|
}
|
|
|
|
}
|
2018-10-20 21:30:20 +02: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 14:55:57 +01:00
|
|
|
error:
|
2018-10-20 21:30:20 +02:00
|
|
|
sigc->result = 'E';
|
|
|
|
/* Clear partial data to avoid confusion */
|
2018-10-22 18:38:21 +02:00
|
|
|
FREE_AND_NULL(sigc->primary_key_fingerprint);
|
2018-10-22 18:38:20 +02:00
|
|
|
FREE_AND_NULL(sigc->fingerprint);
|
2018-10-20 21:30:20 +02:00
|
|
|
FREE_AND_NULL(sigc->signer);
|
|
|
|
FREE_AND_NULL(sigc->key);
|
2014-08-15 00:31:13 +02:00
|
|
|
}
|
|
|
|
|
2020-03-04 12:48:04 +01:00
|
|
|
static int verify_signed_buffer(const char *payload, size_t payload_size,
|
|
|
|
const char *signature, size_t signature_size,
|
|
|
|
struct strbuf *gpg_output,
|
|
|
|
struct strbuf *gpg_status)
|
|
|
|
{
|
|
|
|
struct child_process gpg = CHILD_PROCESS_INIT;
|
|
|
|
struct gpg_format *fmt;
|
|
|
|
struct tempfile *temp;
|
|
|
|
int ret;
|
|
|
|
struct strbuf buf = STRBUF_INIT;
|
|
|
|
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
|
|
|
fmt = get_format_by_sig(signature);
|
|
|
|
if (!fmt)
|
|
|
|
BUG("bad signature '%s'", signature);
|
|
|
|
|
2020-07-28 22:24:53 +02: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 22:26:31 +02:00
|
|
|
"--status-fd=1",
|
|
|
|
"--verify", temp->filename.buf, "-",
|
|
|
|
NULL);
|
2020-03-04 12:48:04 +01:00
|
|
|
|
|
|
|
if (!gpg_status)
|
|
|
|
gpg_status = &buf;
|
|
|
|
|
|
|
|
sigchain_push(SIGPIPE, SIG_IGN);
|
|
|
|
ret = pipe_command(&gpg, payload, payload_size,
|
|
|
|
gpg_status, 0, gpg_output, 0);
|
|
|
|
sigchain_pop(SIGPIPE);
|
|
|
|
|
|
|
|
delete_tempfile(&temp);
|
|
|
|
|
|
|
|
ret |= !strstr(gpg_status->buf, "\n[GNUPG:] GOODSIG ");
|
|
|
|
strbuf_release(&buf); /* no matter it was used or not */
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2015-06-22 01:14:40 +02:00
|
|
|
int check_signature(const char *payload, size_t plen, const char *signature,
|
2015-06-22 01:14:38 +02:00
|
|
|
size_t slen, struct signature_check *sigc)
|
|
|
|
{
|
|
|
|
struct strbuf gpg_output = STRBUF_INIT;
|
|
|
|
struct strbuf gpg_status = STRBUF_INIT;
|
|
|
|
int status;
|
|
|
|
|
|
|
|
sigc->result = 'N';
|
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 14:55:57 +01:00
|
|
|
sigc->trust_level = -1;
|
2015-06-22 01:14:38 +02:00
|
|
|
|
|
|
|
status = verify_signed_buffer(payload, plen, signature, slen,
|
|
|
|
&gpg_output, &gpg_status);
|
|
|
|
if (status && !gpg_output.len)
|
|
|
|
goto out;
|
|
|
|
sigc->payload = xmemdupz(payload, plen);
|
|
|
|
sigc->gpg_output = strbuf_detach(&gpg_output, NULL);
|
|
|
|
sigc->gpg_status = strbuf_detach(&gpg_status, NULL);
|
|
|
|
parse_gpg_output(sigc);
|
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 14:55:57 +01:00
|
|
|
status |= sigc->result != 'G';
|
|
|
|
status |= sigc->trust_level < configured_min_trust_level;
|
2015-06-22 01:14:38 +02:00
|
|
|
|
|
|
|
out:
|
|
|
|
strbuf_release(&gpg_status);
|
|
|
|
strbuf_release(&gpg_output);
|
2015-06-22 01:14:40 +02:00
|
|
|
|
2018-08-09 20:40:27 +02:00
|
|
|
return !!status;
|
2015-06-22 01:14:38 +02:00
|
|
|
}
|
|
|
|
|
2015-06-22 01:14:41 +02:00
|
|
|
void print_signature_buffer(const struct signature_check *sigc, unsigned flags)
|
|
|
|
{
|
2015-06-22 01:14:42 +02:00
|
|
|
const char *output = flags & GPG_VERIFY_RAW ?
|
|
|
|
sigc->gpg_status : sigc->gpg_output;
|
|
|
|
|
2015-06-22 01:14:41 +02:00
|
|
|
if (flags & GPG_VERIFY_VERBOSE && sigc->payload)
|
|
|
|
fputs(sigc->payload, stdout);
|
|
|
|
|
2015-06-22 01:14:42 +02:00
|
|
|
if (output)
|
|
|
|
fputs(output, stderr);
|
2015-06-22 01:14:41 +02:00
|
|
|
}
|
|
|
|
|
2021-02-11 03:08:03 +01:00
|
|
|
size_t parse_signed_buffer(const char *buf, size_t size)
|
2014-08-19 22:18:07 +02:00
|
|
|
{
|
|
|
|
size_t len = 0;
|
2018-04-13 23:18:35 +02:00
|
|
|
size_t match = size;
|
|
|
|
while (len < size) {
|
|
|
|
const char *eol;
|
|
|
|
|
2018-07-17 14:50:09 +02:00
|
|
|
if (get_format_by_sig(buf + len))
|
2018-04-13 23:18:35 +02:00
|
|
|
match = len;
|
|
|
|
|
|
|
|
eol = memchr(buf + len, '\n', size - len);
|
2014-08-19 22:18:07 +02:00
|
|
|
len += eol ? eol - (buf + len) + 1 : size - len;
|
|
|
|
}
|
2018-04-13 23:18:35 +02:00
|
|
|
return match;
|
2014-08-19 22:18:07 +02:00
|
|
|
}
|
|
|
|
|
2021-02-11 03:08:03 +01: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 03:08:06 +01:00
|
|
|
remove_signature(payload);
|
2021-02-11 03:08:03 +01:00
|
|
|
strbuf_add(signature, buf + match, size - match);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-09-08 06:19:47 +02:00
|
|
|
void set_signing_key(const char *key)
|
|
|
|
{
|
|
|
|
free(configured_signing_key);
|
|
|
|
configured_signing_key = xstrdup(key);
|
|
|
|
}
|
|
|
|
|
|
|
|
int git_gpg_config(const char *var, const char *value, void *cb)
|
|
|
|
{
|
2018-07-17 14:50:09 +02: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 14:55:57 +01:00
|
|
|
char *trust;
|
|
|
|
int ret;
|
2018-07-17 14:50:09 +02:00
|
|
|
|
2011-09-08 06:19:47 +02:00
|
|
|
if (!strcmp(var, "user.signingkey")) {
|
2018-04-13 23:18:30 +02:00
|
|
|
if (!value)
|
|
|
|
return config_error_nonbool(var);
|
2011-11-29 21:29:48 +01:00
|
|
|
set_signing_key(value);
|
2018-04-13 23:18:30 +02:00
|
|
|
return 0;
|
2011-11-29 21:29:48 +01:00
|
|
|
}
|
2018-04-13 23:18:30 +02:00
|
|
|
|
2018-07-17 14:50:07 +02:00
|
|
|
if (!strcmp(var, "gpg.format")) {
|
|
|
|
if (!value)
|
|
|
|
return config_error_nonbool(var);
|
2018-07-17 14:50:09 +02:00
|
|
|
fmt = get_format_by_name(value);
|
|
|
|
if (!fmt)
|
2018-07-17 14:50:07 +02:00
|
|
|
return error("unsupported value for %s: %s",
|
|
|
|
var, value);
|
2018-07-17 14:50:09 +02:00
|
|
|
use_format = fmt;
|
|
|
|
return 0;
|
2018-07-17 14:50:07 +02: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 14:55:57 +01: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)
|
|
|
|
return error("unsupported value for %s: %s", var,
|
|
|
|
value);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-07-17 14:50:11 +02:00
|
|
|
if (!strcmp(var, "gpg.program") || !strcmp(var, "gpg.openpgp.program"))
|
2018-07-17 14:50:09 +02:00
|
|
|
fmtname = "openpgp";
|
|
|
|
|
2018-07-17 14:50:12 +02:00
|
|
|
if (!strcmp(var, "gpg.x509.program"))
|
|
|
|
fmtname = "x509";
|
|
|
|
|
2018-07-17 14:50:09 +02:00
|
|
|
if (fmtname) {
|
|
|
|
fmt = get_format_by_name(fmtname);
|
|
|
|
return git_config_string(&fmt->program, var, value);
|
2011-09-08 06:19:47 +02:00
|
|
|
}
|
2018-04-13 23:18:30 +02:00
|
|
|
|
2011-09-08 06:19:47 +02:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
const char *get_signing_key(void)
|
|
|
|
{
|
|
|
|
if (configured_signing_key)
|
|
|
|
return configured_signing_key;
|
2012-05-25 01:28:40 +02:00
|
|
|
return git_committer_info(IDENT_STRICT|IDENT_NO_DATE);
|
2011-09-08 06:19:47 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
int sign_buffer(struct strbuf *buffer, struct strbuf *signature, const char *signing_key)
|
|
|
|
{
|
2014-08-19 21:09:35 +02: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-18 01:38:55 +02:00
|
|
|
int ret;
|
2011-09-08 06:19:47 +02:00
|
|
|
size_t i, j, bottom;
|
2016-06-18 01:38:59 +02:00
|
|
|
struct strbuf gpg_status = STRBUF_INIT;
|
2011-09-08 06:19:47 +02:00
|
|
|
|
2020-07-28 22:24:53 +02: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 22:26:31 +02:00
|
|
|
use_format->program,
|
|
|
|
"--status-fd=2",
|
|
|
|
"-bsau", signing_key,
|
|
|
|
NULL);
|
2011-09-08 06:19:47 +02: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-18 01:38:55 +02:00
|
|
|
bottom = signature->len;
|
2011-09-08 06:19:47 +02: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-18 01:38:55 +02:00
|
|
|
ret = pipe_command(&gpg, buffer->buf, buffer->len,
|
2016-06-18 01:38:59 +02:00
|
|
|
signature, 1024, &gpg_status, 0);
|
2011-09-08 06:19:47 +02:00
|
|
|
sigchain_pop(SIGPIPE);
|
|
|
|
|
2016-06-18 01:38:59 +02:00
|
|
|
ret |= !strstr(gpg_status.buf, "\n[GNUPG:] SIG_CREATED ");
|
|
|
|
strbuf_release(&gpg_status);
|
|
|
|
if (ret)
|
2011-09-08 06:19:47 +02:00
|
|
|
return error(_("gpg failed to sign the data"));
|
|
|
|
|
|
|
|
/* Strip CR from the line endings, in case we are on Windows. */
|
|
|
|
for (i = j = bottom; i < signature->len; i++)
|
|
|
|
if (signature->buf[i] != '\r') {
|
|
|
|
if (i != j)
|
|
|
|
signature->buf[j] = signature->buf[i];
|
|
|
|
j++;
|
|
|
|
}
|
|
|
|
strbuf_setlen(signature, j);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|