git/t/t7510-signed-commit.sh, branch jch

t7510: use $PWD instead of $(pwd) inside PATH

2025-07-29T15:07:42Z

On Windows, $(pwd) will give us a Windows-style path like "D:/foo". Putting that into $PATH confuses anybody parsing that variable, since colon is a separator character in $PATH. Instead, we should use the Unix-style value we get from $PWD ("/d/foo"). This is similar to the cases fixed by 71dd50472d (t0021, t5615: use $PWD instead of $(pwd) in PATH-like shell variables, 2016-11-11). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

t7510: add test cases for non-absolute gpg program

2025-07-22T20:28:58Z

These cases cover scenarios where `gpg.program` is set as a program in `$PATH` or as a path relative to the user's home directory. Signed-off-by: Jonas Brandstötter Signed-off-by: Junio C Hamano

builtin/verify-commit: stop using `the_repository`

2025-03-08T00:52:01Z

Remove the_repository global variable in favor of the repository argument that gets passed in "builtin/verify-commit.c". When `-h` is passed to the command outside a Git repository, the `run_builtin()` will call the `cmd_verify_commit()` function with `repo` set to NULL and then early in the function, `parse_options()` call will give the options help and exit. Pass the repository available in the calling context to `verify_commit()` to remove it's dependency on the global `the_repository` variable. Mentored-by: Christian Couder Signed-off-by: Usman Akinyemi Signed-off-by: Junio C Hamano

t: remove TEST_PASSES_SANITIZE_LEAK annotations

2024-11-20T23:23:48Z

Now that the default value for TEST_PASSES_SANITIZE_LEAK is `true` there is no longer a need to have that variable declared in all of our tests. Drop it. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

pretty: clear signature check

2024-11-05T06:37:53Z

The signature check in the formatting context is never getting released. Fix this to plug the resulting memory leak. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

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