From: "Eric W. Biederman" <ebiederm@xmission.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Todd Zullinger <tmz@pobox.com>,
git@vger.kernel.org, Kousik Sanagavarapu <five231003@gmail.com>,
brian m. carlson <sandals@crustytoothpaste.net>
Subject: [PATCH] t1016-compatObjectFormat: Really freeze time for reproduciblity
Date: Tue, 28 Oct 2025 11:01:45 -0500 [thread overview]
Message-ID: <87frb310d2.fsf_-_@email.froward.int.ebiederm.org> (raw)
In-Reply-To: <xmqqms5chyr8.fsf@gitster.g> (Junio C. Hamano's message of "Mon, 27 Oct 2025 13:32:11 -0700")
The strategy in t1016-compatObjectFormat is to build two trees with
identical commits, one tree encoded in sha1 the other tree encoded
in sha256 and to use the compatibility code to test and see if
the two trees are identical.
GPG signatures include the current time as part of the signature.
To make gpg deterministic I forced the use of gpg --faked-system-time.
Unfortunately I did not look closely enough.
By default gpg still allows time to move forward with --faked-system-time.
So in those rare instances when the system is heavily loaded an gpg runs
slower than other times, signatures over the exact same data differ
due to timestamps with a minuscule difference.
Reading through the gpg documentation with a close eye, time can be
frozen by including an exclamation point at the end of the argument to
--faked-system-time.
Add the exclamation point so gpg really runs with a fixed notion of time,
resulting in the exact same data having identical gpg signatures.
That is enough that I can run "t1016-compatObjectFormat.sh --stress"
and I don't see any failures.
It is possible a future change to gpg will make replay protection more
robust and not provide a way to allow two separate runs of gpg to
produce exactly the same signature for exactly the same data. If that
happens a deeper comparison of the two repositories will need to be
performed. A comparison that simply verifies the signatures and
compares the data for equality. For now that is a lot of work
for no gain so I am just documenting the possibility.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
---
t/t1016-compatObjectFormat.sh | 6 ++++++
t/t1016/gpg | 2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/t/t1016-compatObjectFormat.sh b/t/t1016-compatObjectFormat.sh
index a9af8b239626..0efce53f3aad 100755
--- a/t/t1016-compatObjectFormat.sh
+++ b/t/t1016-compatObjectFormat.sh
@@ -21,6 +21,12 @@ test_description='Test how well compatObjectFormat works'
# different hash functions result in the same content in the commits.
# This means that when the commit is translated between hash functions
# the commit is identical to the commit in the other repository.
+#
+# Similarly this test relies on:
+# gpg --faked-system-time '20230918T154812!
+# freezing the system time from gpg perspective so that two different
+# runs of gpg applied to the same data result in identical signatures.
+#
compat_hash () {
case "$1" in
diff --git a/t/t1016/gpg b/t/t1016/gpg
index 2601cb18a5b3..34d6e055fc9e 100755
--- a/t/t1016/gpg
+++ b/t/t1016/gpg
@@ -1,2 +1,2 @@
#!/bin/sh
-exec gpg --faked-system-time "20230918T154812" "$@"
+exec gpg --faked-system-time '20230918T154812!' "$@"
--
2.41.0
next prev parent reply other threads:[~2025-10-28 16:01 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-03 15:37 [PATCH 0/2] t/lib-gpg: ensure GNUPGHOME is created as needed Todd Zullinger
2024-07-03 15:37 ` [PATCH 1/2] t/lib-gpg: add prepare_gnupghome() to create GNUPGHOME dir Todd Zullinger
2024-07-03 15:37 ` [PATCH 2/2] t/lib-gpg: call prepare_gnupghome() in GPG2 prereq Todd Zullinger
2024-07-03 16:29 ` [PATCH 0/2] t/lib-gpg: ensure GNUPGHOME is created as needed Todd Zullinger
2025-02-28 15:26 ` Todd Zullinger
2025-10-26 1:25 ` Junio C Hamano
2025-10-27 16:16 ` Eric W. Biederman
2025-10-27 17:38 ` Junio C Hamano
2025-10-27 19:03 ` Eric W. Biederman
2025-10-27 19:32 ` Eric W. Biederman
2025-10-27 20:32 ` Junio C Hamano
2025-10-28 16:01 ` Eric W. Biederman [this message]
2025-10-28 17:15 ` [PATCH] t1016-compatObjectFormat: Really freeze time for reproduciblity Junio C Hamano
2025-10-29 3:05 ` Todd Zullinger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87frb310d2.fsf_-_@email.froward.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=five231003@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=sandals@crustytoothpaste.net \
--cc=tmz@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).