Bug#1091868: debian-policy: Document Git-Tag-Tagger and Git-Tag-Info fields
- To: Sean Whitton <spwhitton@spwhitton.name>, 1091868@bugs.debian.org
- Cc: Stuart Prescott <stuart@debian.org>, Ian Jackson <ijackson@chiark.greenend.org.uk>
- Subject: Bug#1091868: debian-policy: Document Git-Tag-Tagger and Git-Tag-Info fields
- From: Guillem Jover <guillem@debian.org>
- Date: Sat, 4 Oct 2025 15:34:59 +0200
- Message-id: <[🔎] aOEigx0f5HbxWCer@thunder.hadrons.org>
- Reply-to: Guillem Jover <guillem@debian.org>, 1091868@bugs.debian.org
- In-reply-to: <877c1iqpid.fsf@zephyr.silentflame.com>
- References: <26550.63340.993340.572628@chiark.greenend.org.uk> <87wmfejqeu.fsf@zephyr.silentflame.com> <87cyfdylqi.fsf@melete.silentflame.com> <87wmfejqeu.fsf@zephyr.silentflame.com> <0824e4e3-f86f-4990-82a6-e58d0a788ea4@debian.org> <87ldtk1cld.fsf@melete.silentflame.com> <87wmfejqeu.fsf@zephyr.silentflame.com> <d2b7e906-a74b-4387-9239-f00d7e5d61fb@debian.org> <87wmfejqeu.fsf@zephyr.silentflame.com> <877c1iqpid.fsf@zephyr.silentflame.com> <87wmfejqeu.fsf@zephyr.silentflame.com>
Hi!
On Wed, 2025-06-11 at 16:14:34 +0100, Sean Whitton wrote:
> From 1dd537efa7bff1993273f24f85daf0468f73b302 Mon Sep 17 00:00:00 2001
> From: Sean Whitton <spwhitton@spwhitton.name>
> Date: Wed, 1 Jan 2025 19:14:06 +0000
> Subject: [PATCH v4] Document Git-Tag-Tagger and Git-Tag-Info fields
>
> ---
> policy/ch-controlfields.rst | 61 ++++++++++++++++++++++++++++++++++
> policy/upgrading-checklist.rst | 9 +++++
> 2 files changed, 70 insertions(+)
>
> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
> index 3151816..9769235 100644
> --- a/policy/ch-controlfields.rst
> +++ b/policy/ch-controlfields.rst
> @@ -237,6 +237,10 @@ is described above, in :ref:`s-controlsyntax`.
>
> - :ref:`Dgit <s-f-Dgit>`
>
> +- :ref:`Git-Tag-Tagger <s-f-Git-Tag-Tagger>`
> +
> +- :ref:`Git-Tag-Info <s-f-Git-Tag-Info>`
> +
I wonder why these use the generic «Git-» namespace instead of «Dgit-»
when they seem tied to the dgit/tag2upload implementation?
> +``Git-Tag-Info``
> +~~~~~~~~~~~~~~~~
> +
> +Other information about the Git tag from which this upload was generated (and
> +to which it corresponds) in accordance with the tagging protocol described in
> +the :manpage:`tag2upload(5)` manual page and `TAG2UPLOAD-DESIGN.txt
> +<https://salsa.debian.org/dgit-team/dgit/-/blob/master/TAG2UPLOAD-DESIGN.txt>`_.
> +
> +The value is of the form ``tag=TAGOBJID fp=FINGERPRINT`` where ``TAGOBJID`` is
> +the Git object ID of the Git annotated tag object, [#]_ and ``FINGERPRINT`` is the
> +fingerprint (in hexadecimal, without spaces) of the PGP key used to sign the
> +Git tag. Other space-separated ``keyword=value`` items may be introduced in
> +the future, and users of this field must ignore items with unknown keywords.
> +
> +``FINGERPRINT`` is taken from the first field of the ``VALIDSIG`` line emitted
> +by :manpage:`gpgv(1)`, as specified in ``/usr/share/doc/gnupg/DETAILS.gz``
> +from the ``gnupg`` package. This will generally be the fingerprint of the
> +signing subkey, if one was used, and the primary key's fingerprint otherwise.
> +
> +The Git annotated tag object is obtainable from the *dgit-repos* server, as
> +described under ``Dgit``, above.
> +
> +Uploads signed by an implemention of the tag2upload service must include this
> +field. Uploads not generated in accordance with the tag2upload protocol must
> +not include this field.
> +
Hmm, I don't feel comfortable with Debian Policy growing reliance on
GnuPG and its specific interfaces and formats, when IMO we should be
making a collective effort to remove reliance on it (due to the schism).
I'd feel more comfortable with references to something vendor generic
and on its track to be standardized through the OpenPGP Working Group,
such as SOPV. So I'm attaching an (untested) patch against dgit which
could make it possible to switch the above specification to use SOPV
details instead, and allow one of the several SOPV implementations
around to be used. If that seems fine, I can submit that to dgit
upstream.
Thanks,
Guillem
From 2a46cedff6203ea33470da861b34d672b82399d4 Mon Sep 17 00:00:00 2001
From: Guillem Jover <guillem@debian.org>
Date: Sat, 4 Oct 2025 15:19:34 +0200
Subject: [PATCH] Switch from gpgv to sopv
FIXME:
- untested.
- why is missing certificates a non-problem?
- sopv exit code handling could be improved, but the patch was done to
be minimal for now.
---
TAG2UPLOAD-DESIGN.txt | 4 ++--
debian/control | 2 +-
infra/dgit-repos-server | 43 +++++++++++++++--------------------------
3 files changed, 19 insertions(+), 30 deletions(-)
diff --git a/TAG2UPLOAD-DESIGN.txt b/TAG2UPLOAD-DESIGN.txt
index 095f990f..5243f8c1 100644
--- a/TAG2UPLOAD-DESIGN.txt
+++ b/TAG2UPLOAD-DESIGN.txt
@@ -202,8 +202,8 @@ The generated .dscs will contain additional fields
(if someone wants to obtain referenced git objects,
they can be found on the dgit-repos git server)
- <fingerprint> is the "fingerprint_in_hex" from the VALIDSIG line
- in the gpgv output.
+ <fingerprint> is the "fingerprint_in_hex" from the SOPV second
+ field in the VERIFICATIONS text stream.
This additional metadata is needed to be able to tell by looking at
the .dsc who the original uploader was (which might be different to
diff --git a/debian/control b/debian/control
index 02055c4f..0fdac222 100644
--- a/debian/control
+++ b/debian/control
@@ -58,7 +58,7 @@ Description: client script for git pushing to Debian-style archives
Debian-style archive on your behalf.
Package: dgit-infrastructure
-Depends: ${misc:Depends}, perl, git-core, gpgv, chiark-utils-bin,
+Depends: ${misc:Depends}, perl, git-core, sqopv | sopv, chiark-utils-bin,
libjson-perl, libdigest-sha-perl, libdbd-sqlite3-perl, sqlite3,
libdpkg-perl,
liburi-perl,
diff --git a/infra/dgit-repos-server b/infra/dgit-repos-server
index e00cd2b7..e56848c0 100755
--- a/infra/dgit-repos-server
+++ b/infra/dgit-repos-server
@@ -776,7 +776,7 @@ sub checksig_keyring ($$) {
# or dies on other errors
#
# Either way, some log info, including the keyring leafname,
- # and the gpgv stderr, is written to $log_fh.
+ # and the sopv stderr, is written to $log_fh.
my $ok = undef;
@@ -786,44 +786,33 @@ sub checksig_keyring ($$) {
print $log_fh "checking signature against keyring $1...\n";
flush $log_fh or die $!;
- our @cmd = (qw(gpgv --status-fd=1 --keyring),
- $keyringfile,
- qw(dgit-tmp/plaintext.asc dgit-tmp/plaintext));
+ our @cmd = (qw(sopv verify dgit-tmp/plaintext.asc), $keyringfile);
debugcmd '|',@cmd;
- my $gpg_child = open P, "-|" // die $!;
- if (!$gpg_child) {
+ my $sopv_child = open P, "-|" // die $!;
+ if (!$sopv_child) {
+ open STDIN, '<', qw(dgit-tmp/plaintext) or die $!;
open STDERR, ">&", $log_fh or die $!;
exec @cmd or die $!;
}
while (<P>) {
- next unless s/^\[GNUPG:\] //;
chomp or die;
printdebug " checksig| $_\n";
my @l = split / /, $_;
- if ($l[0] eq 'NO_PUBKEY') {
- last;
- } elsif ($l[0] eq 'VALIDSIG') {
- my $sigtype = $l[9];
- $sigtype eq '00' or reject "signature is not of type 00!";
- $ok = $l[10];
- $tagfp = $l[1];
- die unless defined $ok and defined $tagfp;
- last;
- } elsif ($l[0] eq 'BADSIG') {
- # This is not necessary for correctness, but it produces
- # a much better error message.
- reject "bad signature!";
- }
+ $ok = 1;
+ $tagfp = $l[1];
+ last;
}
- # Print a message if gnupg dies due to a signal other than SIGPIPE.
- # Ignore nonzero exit status: that's normal, eg for key not found.
- # If gnupg crashes with a nonzero exit status it ought to
- # print some messages of its own.
+ # Print a message if sopv dies due to a signal other than SIGPIPE.
+ # On error sopv only reports via its exit code.
$!=0; $?=0; close P or $?==13 or $? < 256
- or print $log_fh "gnupg failed ($keyringfile): $? $!\n";
+ or do {
+ print $log_fh "sopv failed ($keyringfile): $? $!\n";
+ my $ec = $? >> 8;
+ reject "bad signature! (reason $ec)";
+ };
printdebug sprintf " checksig ok=%d\n", !!$ok;
@@ -871,7 +860,7 @@ sub verifytag_start ($) {
# that signed the tag.
#
# If it rejects, also writes log info including keyring leafnames,
- # and gpgv stderr, to $fail_log_copy_fh.
+ # and sopv stderr, to $fail_log_copy_fh.
# Nothing is written there on success.
#
# Return values are
--
2.51.0
Reply to: