git/t/t7510-signed-commit.sh

391 строка
12 KiB
Bash
Исходник Обычный вид История

#!/bin/sh
test_description='signed commit tests'
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
tests: mark tests relying on the current default for `init.defaultBranch` In addition to the manual adjustment to let the `linux-gcc` CI job run the test suite with `master` and then with `main`, this patch makes sure that GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME is set in all test scripts that currently rely on the initial branch name being `master by default. To determine which test scripts to mark up, the first step was to force-set the default branch name to `master` in - all test scripts that contain the keyword `master`, - t4211, which expects `t/t4211/history.export` with a hard-coded ref to initialize the default branch, - t5560 because it sources `t/t556x_common` which uses `master`, - t8002 and t8012 because both source `t/annotate-tests.sh` which also uses `master`) This trick was performed by this command: $ sed -i '/^ *\. \.\/\(test-lib\|lib-\(bash\|cvs\|git-svn\)\|gitweb-lib\)\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' $(git grep -l master t/t[0-9]*.sh) \ t/t4211*.sh t/t5560*.sh t/t8002*.sh t/t8012*.sh After that, careful, manual inspection revealed that some of the test scripts containing the needle `master` do not actually rely on a specific default branch name: either they mention `master` only in a comment, or they initialize that branch specificially, or they do not actually refer to the current default branch. Therefore, the aforementioned modification was undone in those test scripts thusly: $ git checkout HEAD -- \ t/t0027-auto-crlf.sh t/t0060-path-utils.sh \ t/t1011-read-tree-sparse-checkout.sh \ t/t1305-config-include.sh t/t1309-early-config.sh \ t/t1402-check-ref-format.sh t/t1450-fsck.sh \ t/t2024-checkout-dwim.sh \ t/t2106-update-index-assume-unchanged.sh \ t/t3040-subprojects-basic.sh t/t3301-notes.sh \ t/t3308-notes-merge.sh t/t3423-rebase-reword.sh \ t/t3436-rebase-more-options.sh \ t/t4015-diff-whitespace.sh t/t4257-am-interactive.sh \ t/t5323-pack-redundant.sh t/t5401-update-hooks.sh \ t/t5511-refspec.sh t/t5526-fetch-submodules.sh \ t/t5529-push-errors.sh t/t5530-upload-pack-error.sh \ t/t5548-push-porcelain.sh \ t/t5552-skipping-fetch-negotiator.sh \ t/t5572-pull-submodule.sh t/t5608-clone-2gb.sh \ t/t5614-clone-submodules-shallow.sh \ t/t7508-status.sh t/t7606-merge-custom.sh \ t/t9302-fast-import-unpack-limit.sh We excluded one set of test scripts in these commands, though: the range of `git p4` tests. The reason? `git p4` stores the (foreign) remote branch in the branch called `p4/master`, which is obviously not the default branch. Manual analysis revealed that only five of these tests actually require a specific default branch name to pass; They were modified thusly: $ sed -i '/^ *\. \.\/lib-git-p4\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' t/t980[0167]*.sh t/t9811*.sh Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19 02:44:19 +03:00
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
. ./test-lib.sh
GNUPGHOME_NOT_USED=$GNUPGHOME
. "$TEST_DIRECTORY/lib-gpg.sh"
test_expect_success GPG 'create signed commits' '
test_oid_cache <<-\EOF &&
header sha1:gpgsig
header sha256:gpgsig-sha256
EOF
test_when_finished "test_unconfig commit.gpgsign" &&
echo 1 >file && git add file &&
test_tick && git commit -S -m initial &&
git tag initial &&
git branch side &&
echo 2 >file && test_tick && git commit -a -S -m second &&
git tag second &&
git checkout side &&
echo 3 >elif && git add elif &&
test_tick && git commit -m "third on side" &&
git checkout main &&
test_tick && git merge -S side &&
git tag merge &&
echo 4 >file && test_tick && git commit -a -m "fourth unsigned" &&
git tag fourth-unsigned &&
test_tick && git commit --amend -S -m "fourth signed" &&
git tag fourth-signed &&
git config commit.gpgsign true &&
echo 5 >file && test_tick && git commit -a -m "fifth signed" &&
git tag fifth-signed &&
git config commit.gpgsign false &&
echo 6 >file && test_tick && git commit -a -m "sixth" &&
git tag sixth-unsigned &&
git config commit.gpgsign true &&
echo 7 >file && test_tick && git commit -a -m "seventh" --no-gpg-sign &&
git tag seventh-unsigned &&
test_tick && git rebase -f HEAD^^ && git tag sixth-signed HEAD^ &&
git tag seventh-signed &&
echo 8 >file && test_tick && git commit -a -m eighth -SB7227189 &&
git tag eighth-signed-alt &&
# commit.gpgsign is still on but this must not be signed
echo 9 | git commit-tree HEAD^{tree} >oid &&
test_line_count = 1 oid &&
git tag ninth-unsigned $(cat oid) &&
# explicit -S of course must sign.
echo 10 | git commit-tree -S HEAD^{tree} >oid &&
test_line_count = 1 oid &&
git tag tenth-signed $(cat oid) &&
# --gpg-sign[=<key-id>] must sign.
echo 11 | git commit-tree --gpg-sign HEAD^{tree} >oid &&
test_line_count = 1 oid &&
git tag eleventh-signed $(cat oid) &&
echo 12 | git commit-tree --gpg-sign=B7227189 HEAD^{tree} >oid &&
test_line_count = 1 oid &&
git tag twelfth-signed-alt $(cat oid)
'
test_expect_success GPG 'verify and show signatures' '
(
for commit in initial second merge fourth-signed \
fifth-signed sixth-signed seventh-signed tenth-signed \
eleventh-signed
do
git verify-commit $commit &&
git show --pretty=short --show-signature $commit >actual &&
grep "Good signature from" actual &&
! grep "BAD signature from" actual &&
echo $commit OK || exit 1
done
) &&
(
for commit in merge^2 fourth-unsigned sixth-unsigned \
seventh-unsigned ninth-unsigned
do
test_must_fail git verify-commit $commit &&
git show --pretty=short --show-signature $commit >actual &&
! grep "Good signature from" actual &&
! grep "BAD signature from" actual &&
echo $commit OK || exit 1
done
) &&
(
for commit in eighth-signed-alt twelfth-signed-alt
do
git show --pretty=short --show-signature $commit >actual &&
grep "Good signature from" actual &&
! grep "BAD signature from" actual &&
grep "not certified" actual &&
echo $commit OK || exit 1
done
)
'
test_expect_success GPG 'verify-commit exits failure on unknown signature' '
test_must_fail env GNUPGHOME="$GNUPGHOME_NOT_USED" git verify-commit initial 2>actual &&
! grep "Good signature from" actual &&
! grep "BAD signature from" actual &&
grep -q -F -e "No public key" -e "public key not found" actual
'
test_expect_success GPG 'verify-commit exits success on untrusted signature' '
git verify-commit eighth-signed-alt 2>actual &&
grep "Good signature from" actual &&
! grep "BAD signature from" actual &&
grep "not certified" actual
'
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 16:55:57 +03:00
test_expect_success GPG 'verify-commit exits success with matching minTrustLevel' '
test_config gpg.minTrustLevel ultimate &&
git verify-commit sixth-signed
'
test_expect_success GPG 'verify-commit exits success with low minTrustLevel' '
test_config gpg.minTrustLevel fully &&
git verify-commit sixth-signed
'
test_expect_success GPG 'verify-commit exits failure with high minTrustLevel' '
test_config gpg.minTrustLevel ultimate &&
test_must_fail git verify-commit eighth-signed-alt
'
test_expect_success GPG 'verify signatures with --raw' '
(
for commit in initial second merge fourth-signed fifth-signed sixth-signed seventh-signed
do
git verify-commit --raw $commit 2>actual &&
grep "GOODSIG" actual &&
! grep "BADSIG" actual &&
echo $commit OK || exit 1
done
) &&
(
for commit in merge^2 fourth-unsigned sixth-unsigned seventh-unsigned
do
test_must_fail git verify-commit --raw $commit 2>actual &&
! grep "GOODSIG" actual &&
! grep "BADSIG" actual &&
echo $commit OK || exit 1
done
) &&
(
for commit in eighth-signed-alt
do
git verify-commit --raw $commit 2>actual &&
grep "GOODSIG" actual &&
! grep "BADSIG" actual &&
grep "TRUST_UNDEFINED" actual &&
echo $commit OK || exit 1
done
)
'
test_expect_success GPG 'proper header is used for hash algorithm' '
git cat-file commit fourth-signed >output &&
grep "^$(test_oid header) -----BEGIN PGP SIGNATURE-----" output
'
test_expect_success GPG 'show signed commit with signature' '
git show -s initial >commit &&
git show -s --show-signature initial >show &&
git verify-commit -v initial >verify.1 2>verify.2 &&
git cat-file commit initial >cat &&
grep -v -e "gpg: " -e "Warning: " show >show.commit &&
grep -e "gpg: " -e "Warning: " show >show.gpg &&
grep -v "^ " cat | grep -v "^gpgsig.* " >cat.commit &&
test_cmp show.commit commit &&
test_cmp show.gpg verify.2 &&
test_cmp cat.commit verify.1
'
test_expect_success GPG 'detect fudged signature' '
git cat-file commit seventh-signed >raw &&
tests: make forging GPG signed commits and tags more robust A couple of test scripts create forged GPG signed commits or tags to check that such forgery can't fool various git commands' signature verification. All but one of those test scripts are prone to occasional failures because the forgery creates a bogus GPG signature, and git commands error out with an unexpected error message, e.g. "Commit deadbeef does not have a GPG signature" instead of "... has a bad GPG signature". 't5573-pull-verify-signatures.sh', 't7510-signed-commit.sh' and 't7612-merge-verify-signatures.sh' create forged signed commits like this: git commit -S -m "bad on side" && git cat-file commit side-bad >raw && sed -e "s/bad/forged bad/" raw >forged && git hash-object -w -t commit forged >forged.commit On rare occasions the given pattern occurs not only in the commit message but in the GPG signature as well, and after it's replaced in the signature the resulting signature becomes invalid, GPG will report CRC error and that it couldn't find any signature, which will then ultimately cause the test failure. Since in all three cases the pattern to be replaced during the forgery is the first word of the commit message's subject line, and since the GPG signature in the commit object is indented by a space, let's just anchor those patterns to the beginning of the line to prevent this issue. The test script 't7030-verify-tag.sh' creates a forged signed tag object in a similar way by replacing the pattern "seventh", but the GPG signature in tag objects is not indented by a space, so the above solution is not applicable in this case. However, in the tag object in question the pattern "seventh" occurs not only in the tag message but in the 'tag' header as well. To create a forged tag object it's sufficient to replace only one of the two occurences, so modify the sed script to limit the pattern to the 'tag' header (i.e. a line beginning with "tag ", which, because of the space character, can never occur in the base64-encoded GPG signature). Note that the forgery in 't7004-tag.sh' is not affected by this issue: while 't7004' does create a forged signed tag kind of the same way, it replaces "signed-tag" in the tag object, which, because of the '-' character, can never occur in the base64-encoded GPG signarute. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-04 16:39:26 +03:00
sed -e "s/^seventh/7th forged/" raw >forged1 &&
git hash-object -w -t commit forged1 >forged1.commit &&
test_must_fail git verify-commit $(cat forged1.commit) &&
git show --pretty=short --show-signature $(cat forged1.commit) >actual1 &&
grep "BAD signature from" actual1 &&
! grep "Good signature from" actual1
'
test_expect_success GPG 'detect fudged signature with NUL' '
git cat-file commit seventh-signed >raw &&
cat raw >forged2 &&
echo Qwik | tr "Q" "\000" >>forged2 &&
git hash-object -w -t commit forged2 >forged2.commit &&
test_must_fail git verify-commit $(cat forged2.commit) &&
git show --pretty=short --show-signature $(cat forged2.commit) >actual2 &&
grep "BAD signature from" actual2 &&
! grep "Good signature from" actual2
'
test_expect_success GPG 'amending already signed commit' '
git checkout -f fourth-signed^0 &&
git commit --amend -S --no-edit &&
git verify-commit HEAD &&
git show -s --show-signature HEAD >actual &&
grep "Good signature from" actual &&
! grep "BAD signature from" actual
'
test_expect_success GPG 'show good signature with custom format' '
cat >expect <<-\EOF &&
G
13B6F51ECDDE430D
C O Mitter <committer@example.com>
73D758744BE721698EC54E8713B6F51ECDDE430D
73D758744BE721698EC54E8713B6F51ECDDE430D
EOF
git log -1 --format="%G?%n%GK%n%GS%n%GF%n%GP" sixth-signed >actual &&
test_cmp expect actual
'
test_expect_success GPG 'show bad signature with custom format' '
cat >expect <<-\EOF &&
B
13B6F51ECDDE430D
C O Mitter <committer@example.com>
EOF
git log -1 --format="%G?%n%GK%n%GS%n%GF%n%GP" $(cat forged1.commit) >actual &&
test_cmp expect actual
'
test_expect_success GPG 'show untrusted signature with custom format' '
cat >expect <<-\EOF &&
U
65A0EEA02E30CAD7
Eris Discordia <discord@example.net>
F8364A59E07FFE9F4D63005A65A0EEA02E30CAD7
D4BE22311AD3131E5EDA29A461092E85B7227189
EOF
git log -1 --format="%G?%n%GK%n%GS%n%GF%n%GP" eighth-signed-alt >actual &&
test_cmp expect actual
'
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 16:55:57 +03:00
test_expect_success GPG 'show untrusted signature with undefined trust level' '
cat >expect <<-\EOF &&
undefined
65A0EEA02E30CAD7
Eris Discordia <discord@example.net>
F8364A59E07FFE9F4D63005A65A0EEA02E30CAD7
D4BE22311AD3131E5EDA29A461092E85B7227189
EOF
git log -1 --format="%GT%n%GK%n%GS%n%GF%n%GP" eighth-signed-alt >actual &&
test_cmp expect actual
'
test_expect_success GPG 'show untrusted signature with ultimate trust level' '
cat >expect <<-\EOF &&
ultimate
13B6F51ECDDE430D
C O Mitter <committer@example.com>
73D758744BE721698EC54E8713B6F51ECDDE430D
73D758744BE721698EC54E8713B6F51ECDDE430D
EOF
git log -1 --format="%GT%n%GK%n%GS%n%GF%n%GP" sixth-signed >actual &&
test_cmp expect actual
'
test_expect_success GPG 'show unknown signature with custom format' '
cat >expect <<-\EOF &&
E
65A0EEA02E30CAD7
EOF
GNUPGHOME="$GNUPGHOME_NOT_USED" git log -1 --format="%G?%n%GK%n%GS%n%GF%n%GP" eighth-signed-alt >actual &&
test_cmp expect actual
'
test_expect_success GPG 'show lack of signature with custom format' '
cat >expect <<-\EOF &&
N
EOF
git log -1 --format="%G?%n%GK%n%GS%n%GF%n%GP" seventh-unsigned >actual &&
test_cmp expect actual
'
test_expect_success GPG 'log.showsignature behaves like --show-signature' '
test_config log.showsignature true &&
git show initial >actual &&
grep "gpg: Signature made" actual &&
grep "gpg: Good signature" actual
'
test_expect_success GPG 'check config gpg.format values' '
test_config gpg.format openpgp &&
git commit -S --amend -m "success" &&
test_config gpg.format OpEnPgP &&
test_must_fail git commit -S --amend -m "fail"
'
test_expect_success GPG 'detect fudged commit with double signature' '
sed -e "/gpgsig/,/END PGP/d" forged1 >double-base &&
sed -n -e "/gpgsig/,/END PGP/p" forged1 | \
sed -e "s/^$(test_oid header)//;s/^ //" | gpg --dearmor >double-sig1.sig &&
gpg -o double-sig2.sig -u 29472784 --detach-sign double-base &&
cat double-sig1.sig double-sig2.sig | gpg --enarmor >double-combined.asc &&
sed -e "s/^\(-.*\)ARMORED FILE/\1SIGNATURE/;1s/^/$(test_oid header) /;2,\$s/^/ /" \
double-combined.asc > double-gpgsig &&
sed -e "/committer/r double-gpgsig" double-base >double-commit &&
git hash-object -w -t commit double-commit >double-commit.commit &&
test_must_fail git verify-commit $(cat double-commit.commit) &&
git show --pretty=short --show-signature $(cat double-commit.commit) >double-actual &&
grep "BAD signature from" double-actual &&
grep "Good signature from" double-actual
'
test_expect_success GPG 'show double signature with custom format' '
cat >expect <<-\EOF &&
E
EOF
git log -1 --format="%G?%n%GK%n%GS%n%GF%n%GP" $(cat double-commit.commit) >actual &&
test_cmp expect actual
'
# NEEDSWORK: This test relies on the test_tick commit/author dates from the first
# 'create signed commits' test even though it creates its own
test_expect_success GPG 'verify-commit verifies multiply signed commits' '
git init multiply-signed &&
cd multiply-signed &&
test_commit first &&
echo 1 >second &&
git add second &&
tree=$(git write-tree) &&
parent=$(git rev-parse HEAD^{commit}) &&
git commit --gpg-sign -m second &&
git cat-file commit HEAD &&
# Avoid trailing whitespace.
sed -e "s/^Q//" -e "s/^Z/ /" >commit <<-EOF &&
Qtree $tree
Qparent $parent
Qauthor A U Thor <author@example.com> 1112912653 -0700
Qcommitter C O Mitter <committer@example.com> 1112912653 -0700
Qgpgsig -----BEGIN PGP SIGNATURE-----
QZ
Q iHQEABECADQWIQRz11h0S+chaY7FTocTtvUezd5DDQUCX/uBDRYcY29tbWl0dGVy
Q QGV4YW1wbGUuY29tAAoJEBO29R7N3kMNd+8AoK1I8mhLHviPH+q2I5fIVgPsEtYC
Q AKCTqBh+VabJceXcGIZuF0Ry+udbBQ==
Q =tQ0N
Q -----END PGP SIGNATURE-----
Qgpgsig-sha256 -----BEGIN PGP SIGNATURE-----
QZ
Q iHQEABECADQWIQRz11h0S+chaY7FTocTtvUezd5DDQUCX/uBIBYcY29tbWl0dGVy
Q QGV4YW1wbGUuY29tAAoJEBO29R7N3kMN/NEAn0XO9RYSBj2dFyozi0JKSbssYMtO
Q AJwKCQ1BQOtuwz//IjU8TiS+6S4iUw==
Q =pIwP
Q -----END PGP SIGNATURE-----
Q
Qsecond
EOF
head=$(git hash-object -t commit -w commit) &&
git reset --hard $head &&
git verify-commit $head 2>actual &&
grep "Good signature from" actual &&
! grep "BAD signature from" actual
'
test_done