Re: [PATCH 0/2] t/lib-gpg: ensure GNUPGHOME is created as needed

["Eric W. Biederman" <ebiederm@xmission.com>]

Junio C Hamano <gitster@pobox.com> writes:

> Todd Zullinger <tmz@pobox.com> writes:
>
>> I've intended to dig into it further over the past few
>> months but have not managed to spend enough time to work out
>> the root of the problem.
>>
>> I hope that someone more familiar with these tests (or
>> perhaps someone with fresh eyes) will spot the problem.
>>> 
>>> A number of these fail, e.g.:
>>> 
>>> https://github.com/tmzullinger/git/actions/runs/9780387020/job/27001952643#step:4:1871
>>> 
>>>     Error: failed: t1016.173 Verify commit signedcommit4's sha1 oid
>>>     failure: t1016.173 Verify commit signedcommit4's sha1 oid 
>>> 	    git --git-dir=repo-sha256/.git rev-parse --output-object-format=sha1 ${sha256_oid} > ${name}_sha1 &&
>>> 	    test_cmp ${name}_sha1 ${name}_sha1_expected
>>>       
>>>       + git --git-dir=repo-sha256/.git rev-parse --output-object-format=sha1 5d70155cc40e4c16515c89ad0b11d8c691436fc4a4d3ca246669a4c21f07e454
>>>       + test_cmp signedcommit4_sha1 signedcommit4_sha1_expected
>>>       + test 2 -ne 2
>>>       + eval diff -u "$@"
>>>       + diff -u signedcommit4_sha1 signedcommit4_sha1_expected
>>>       --- signedcommit4_sha1	2024-07-03 15:11:05.597537579 +0000
>>>       +++ signedcommit4_sha1_expected	2024-07-03 15:11:05.553537766 +0000
>>>       @@ -1 +1 @@
>>>       -9179ccc5b15588bc3a45c5cc75bdec380f8ccb86
>>>       +c6c46f92bc2cfda57ad6bf7981fa654825376b24
>>>       error: last command exited with $?=1
>>>       not ok 173 - Verify commit signedcommit4's sha1 oid
>>>       #	
>>>       #		git --git-dir=repo-sha256/.git rev-parse --output-object-format=sha1 ${sha256_oid} > ${name}_sha1 &&
>>>       #		test_cmp ${name}_sha1 ${name}_sha1_expected
>>>       #	
>>> 
>>> This seems like it's just exposing a pre-existing failure,
>>> as I can't imagine how creating GNUPGHOME would cause the
>>> actual and expected SHA's to differ. :)

Hmm. Let me see.

The test goes through and creates 2 repositories, one sha1 and the other
sha256.

In those repositories a gpg signed commit is created.
That gpg signed commit should contain both the signed sha1
and the signed sha256 gpg signatures.  As both object-format
and compat-object-format are set in the config.

Then the commit is extracted and one of the signatures removed.

Then the oid of the signed commit with only a single signed gpg
signature is computed.

In the sha256 repository the sha256 oid is given to get the sha1 oid.

That sha1 oid is of the signed gpg commit is compared with the
previously computed sha1 oid.

So I think a messed up GNUPGHOME could result in the wrong signing
key being used.  Though how that signing key could be inconsistent
from one part of the test to the other I don't know.

Not seeing t/t1016/gpg as the gpg program does look like a more
likely cause of the error there.

>>> 
>>> Perhaps the intended gpg wrapper script which sets
>>> `--faked-system-time` isn't being used?
>>> 
>>> I'm not sure why that would differ in the Github actions
>>> from my local builds, but I don't know what else differs in
>>> the Ubuntu images and/or environment used by the actions.
>>
>> I have run a good number of builds with the patches applied
>> and t1016-compatObjectFormat regularly fails for all of the
>> tests which use the GPG2 prereq.  A recent Github CI run is
>> here:
>>
>>     https://github.com/tmzullinger/git/actions/runs/13570544425
>>
>> I think this test flakiness should be fixed so that we can
>> apply the patch to fix the GPG2 prereq.  As it is, we're
>> skipping _all_ of the tests which require GPG2.
>
> Any progress or responses?  All of these tests, that nobody seemed
> to have caught breakage of because they weren't being run anyway,
> seem to be flakey with the new GNUPGHOME set-up.
>
> I am tempted to do this in the meantime, but I'd really prefer not
> to have to do so, assuming that these tests, when fixed, would be
> materially contributing to the health of our codebase.

I just dug into this a little and hopefully I have paged enough
state back to understand this.

In my testing a missing GNUPGHOME appears enough to prevent the
prerequisite from succeeding. So let's fix that. Todd Zullinger's sent
some nice patches to do that (up-thread), or you can take use my minimal
version.

The only possible source of flakiness in the tests I can see is the
possibility of t/t1016/gpg not getting called (which uses a fixed
timestamp).  It appears you just fixed that problem in commit
516bf45749bb ("t1016: make sure to use specified GPG").

With that commit reverted I can reproduce the flakiness locally
by just running the test manually a few times.

I believe I used the GPG2 prereq because I don't have the older version
of GPG to test with.  So I don't know if t1016 would work on the older
version of GPG or not.


diff --git a/t/lib-gpg.sh b/t/lib-gpg.sh
index 937b876bd052..c4bbedfe081e 100644
--- a/t/lib-gpg.sh
+++ b/t/lib-gpg.sh
@@ -62,6 +62,8 @@ test_lazy_prereq GPG2 '
 		exit 1
 		;;
 	*)
+		mkdir "$GNUPGHOME" &&
+		chmod 0700 "$GNUPGHOME" &&
 		(gpgconf --kill all || : ) &&
 		gpg --homedir "${GNUPGHOME}" --import \
 			"$TEST_DIRECTORY"/lib-gpg/keyring.gpg &&


Eric