git/t/t7510-signed-commit.sh, branch v2.45.2

t/lib-gpg: introduce new prereq GPG2

2023-06-06T00:32:12Z

GnuPG v2.0.0 released in 2006, which according to its release notes https://gnupg.org/download/release_notes.html is the "First stable version of GnuPG integrating OpenPGP and S/MIME". Use this version or its successors for tests that will fail for versions less than v2.0.0 because of the difference in the output on stderr between the versions (v2.* vs v0.* or v2.* vs v1.*). Skip if the GPG version detected is less than v2.0.0. Do not, however, remove the existing prereq GPG yet since a lot of tests still work with the prereq GPG (that is even with versions v0.* or v1.*) and some systems still use these versions. Mentored-by: Christian Couder Mentored-by: Hariom Verma Signed-off-by: Kousik Sanagavarapu Signed-off-by: Junio C Hamano

gpg-interface: set trust level of missing key to "undefined"

2023-04-19T15:30:54Z

In check_signature(), we initialize the trust_level field to "-1", with the idea that if gpg does not return a trust level at all (if there is no signature, or if the signature is made by an unknown key), we'll use that value. But this has two problems: 1. Since the field is an enum, it's up to the compiler to decide what underlying storage to use, and it only has to fit the values we've declared. So we may not be able to store "-1" at all. And indeed, on my system (linux with gcc), the resulting enum is an unsigned 32-bit value, and -1 becomes 4294967295. The difference may seem academic (and you even get "-1" if you pass it to printf("%d")), but it means that code like this: status |= sigc->trust_level < configured_min_trust_level; does not necessarily behave as expected. This turns out not to be a bug in practice, though, because we keep the "-1" only when gpg did not report a signature from a known key, in which case the line above: status |= sigc->result != 'G'; would always set status to non-zero anyway. So only a 'G' signature with no parsed trust level would cause a problem, which doesn't seem likely to trigger (outside of unexpected gpg behavior). 2. When using the "%GT" format placeholder, we pass the value to gpg_trust_level_to_str(), which complains that the value is out of range with a BUG(). This behavior was introduced by 803978da49 (gpg-interface: add function for converting trust level to string, 2022-07-11). Before that, we just did a switch() on the enum, and anything that wasn't matched would end up as the empty string. Curiously, solving this by naively doing: if (level < 0) return ""; in that function isn't sufficient. Because of (1) above, the compiler can (and does in my case) actually remove that conditional as dead code! We can solve both by representing this state as an enum value. We could do this by adding a new "unknown" value. But this really seems to match the existing "undefined" level well. GPG describes this as "Not enough information for calculation". We have tests in t7510 that trigger this case (verifying a signature from a key that we don't have, and then checking various %G placeholders), but they didn't notice the BUG() because we didn't look at %GT for that case! Let's make sure we check all %G placeholders for each case in the formatting tests. The interesting ones here are "show unknown signature with custom format" and "show lack of signature with custom format", both of which would BUG() before, and now turn %GT into "undefined". Prior to 803978da49 they would have turned it into the empty string, but I think saying "undefined" consistently is a reasonable outcome, and probably makes life easier for anyone parsing the output (and any such parser had to be ready to see "undefined" already). The other modified tests produce the same output before and after this patch, but now we're consistently checking both %G? and %GT in all of them. Signed-off-by: Jeff King Reported-by: Rolf Eike Beer Signed-off-by: Junio C Hamano

Merge branch 'js/gpg-errors'

2023-02-24T19:32:29Z

Error messages given upon a signature verification failure used to discard the errors from underlying gpg program, which has been corrected. * js/gpg-errors: gpg: do show gpg's error message upon failure t7510: add a test case that does not need gpg

gpg: do show gpg's error message upon failure

2023-02-15T16:55:24Z

There are few things more frustrating when signing a commit fails than reading a terse "error: gpg failed to sign the data" message followed by the unsurprising "fatal: failed to write commit object" message. In many cases where signing a commit or tag fails, `gpg` actually said something helpful, on its stderr, and Git even consumed that, but then keeps mum about it. Teach Git to stop withholding that rather important information. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

t7510: add a test case that does not need gpg

2023-02-15T16:55:22Z

This test case not only increases test coverage in setups without working gpg, but also prepares for verifying that the error message of `gpg.program` is shown upon failure. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

t: use hash-object --literally when created malformed objects

2023-01-18T20:59:44Z

Many test scripts use hash-object to create malformed objects to see how we handle the results in various commands. In some cases we already have to use "hash-object --literally", because it does some rudimentary quality checks. But let's use "--literally" more consistently to future-proof these tests against hash-object learning to be more careful. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'fs/gpg-unknown-key-test-fix'

2022-01-12T23:11:42Z

Test simplification. * fs/gpg-unknown-key-test-fix: t/gpg: simplify test for unknown key

t/gpg: simplify test for unknown key

2022-01-12T19:21:22Z

To test for a key that is completely unknown to the keyring we need one to sign the commit with. This was done by generating a new key and not add it into the keyring. To avoid the key generation overhead and problems where GPG did hang in CI during it, switch GNUPGHOME to the empty $GNUPGHOME_NOT_USED instead, therefore making all used keys unknown for this single `verify-commit` call. Reported-by: Ævar Arnfjörð Bjarmason Signed-off-by: Fabian Stelzer Reviewed-by: Taylor Blau Signed-off-by: Junio C Hamano

ssh signing: make sign/amend test more resilient

2021-11-19T17:05:27Z

The test `amending already signed commit` is using git checkout to select a specific commit to amend. In case an earlier test fails and leaves behind a dirty index/worktree this test would fail as well. Using `checkout -f` will avoid interference by most other tests. Signed-off-by: Fabian Stelzer Signed-off-by: Junio C Hamano

ssh signing: test that gpg fails for unknown keys

2021-09-10T21:15:53Z

Test that verify-commit/tag will fail when a gpg key is completely unknown. To do this we have to generate a key, use it for a signature and delete it from our keyring aferwards completely. Signed-off-by: Fabian Stelzer Signed-off-by: Junio C Hamano