Since version 2.9.19, APT swutched from gpgv to sqv as its GPG dependency. It would be desirable for devscripts to do the same, if possible.

Cheers!
Martin-Éric
--- /etc/devscripts.conf ---
Empty.

--- ~/.devscripts ---
export DEBSIGN_KEYID=C89002C77A8BEC6A4E6D7390AE1F8277C4B4D7B6

control: tags -1 + moreinfo

hi Martin-Éric,

there have been a lot of related changes recently in devscripts,
just have a look at the last two months:

$ git checkout v2.24.8
$ head -214 debian/changelog | egrep -i '(sop|pgp|gpg|gnupg|9580|uscan)'
  * debsign: Ensure future GnuPG interop by forcing OpenPGP compliant behavior.
  * Devscripts::Uscan::Keyring: Handle and warn on concatenated ASCII Armor
  * Uscan/Keyring.pm:
    - gpgv can use /dev/null for homedir.
    - add helper functions for OpenPGP ASCII Armor.
    - remove dependency on /usr/bin/gpg.
    - add OpenPGP verification support for sop. Closes: #1010955.
    - clean up references to RFC 9580.
    - rely on sopv instead of sop, except for "sop armor".
  * d/control and README, documented uscan depends:
    - remove gnupg from dependency annotations, encourage sop.
    - use the sopv alternatives, rather than enumerate sopv's implementations.
  * debsign: Remove compatibility code for ancient GnuPG. Closes: #1066875
  * uscan: bash-completion: Add support for --vcs-export-uncompressed option.

So I'm wondering what else in devscripts should be changed? As it is, this bug
report is not really actionable.

ke 25.12.2024 klo 15.03 Holger Levsen (holger@layer-acht.org) kirjoitti:

Depends:  gnupg | gnupg2, sopv | gpgv

i.e. how do the dependencies reflect the transition from these tools to sq,sqv?

Martin-Éric

thanks, that's indeed something to address. (however we want to transition
to sop/sopv, not sq/sqv.)

ke 25.12.2024 klo 16.00 Holger Levsen (holger@layer-acht.org) kirjoitti:

Fair enough. Just as long as GPG dependencies remains consistent
between apt, dpkg and devtools.

FWIW, the only reason I found out about 'sq' in the first place is a
uscan warning that suggests concatenating ASCII Armor blocks in
signing-key.asc using 'sq'. Conversely, recent APT uploads show that
it has migrated to 'sqv'. Both of these really point to a migration to
sq/sqv, not sop/sopv.

Martin-Éric

Martin-Éric, i think you mean "PGP dependencies", not "GPG
dependencies", right?

The main issue going forward is that we want interoperable OpenPGP data
formats to be produced and consumed by the various tools.

apt has a very specific set of OpenPGP needs -- primarily signature
verification, and various forms of OpenPGP signature and certificate
debugging/linting to be able to provide warnings to users about upcoming
cryptographic policy tightening before they happen.

In addition to these needs, devscripts is actually *creating*
signatures, and potentially doing other forms of OpenPGP data
manipulation, etc.

sq (and its verification-only sibling, sqv) is a particular OpenPGP
implementation, the Sequoia project.

sop (and its verification-only subset, sopv) is a generic standard of
which we have several distinct implementations in debian today
(including sqop/sqopv from the Sequoia project).

Attaching devscripts (a Debian Developer-focused package) to sq and sqv
rather than the more generic standard seems to constrain developer tool
choice more significantly than we need to, and binds the Debian
ecosystem more tightly to a specific OpenPGP implementation.  While
there are some narrow advantages to debian to requiring all Debian
developers to use a single OpenPGP implementation, i think there are
more advantages to the ecosystem generally to supporting the use of
several interoperable implementations, as Debian developers are more
likely to be able to help ensure that the various implementations
converge as needed.

anyway, that's my 2¢ on it!

pe 3.1.2025 klo 20.12 Daniel Kahn Gillmor (dkg@debian.org) kirjoitti:

I really don't have any opinion on which GPG implementation should get
selected. My key point is to pick one and apply it across the board
for dpkg, apt and devscripts. Until recently, it meant gpg/gpgv across
the board. I also don't mind if software includes support for various
implementations. My goal here is to avoid dependencies being all over
the place. If the consensus if for sop/sopv, I'm fine with it. If it's
for sq/sqv, I'm fine with it. I simply want to avoid an outcome where
each of those key packages has a hard Depends on an entirely different
GPG implementation.

Martin-Éric

I think i understand your goal, but i also think you're confusing the
data formats exchanged -- OpenPGP objects -- with the implementation
used to generate and process those objects.  Full disclosure: i'm a
co-chair of the OpenPGP working group within the IETF, so i'm perhaps
more tuned in to the distinction between data format and implementation
than most people.

Unlike in the past, we have more OpenPGP implementations available today
than GnuPG, and each implementation offers different affordances and
capabilities.  For interoperability testing, most implementations do
support a minimalist common interface, the so-called "stateless openpgp
CLI", or "sop", which i've been stewarding.  To the extent that those
implementations implement sop, they are effectively interchangeable.

Apt has a set of very specific goals for its handling of OpenPGP
material, so it selected a specific tool that it wants to use for those
features.

dpkg and devscripts have a different set of needs, and they accordingly
might select different tools.  We don't say that our developer tooling
must all use OpenSSL for TLS connections, and we don't say that our
developers must all use vim for text editing, perl for data parsing, or
write their code in C++.  If we allow for diversity in those areas, why
should developer tooling be obliged to pick an OpenPGP implementation on
the basis of what any other tooling picks?

Having a diverse and active set of OpenPGP implementations is a healthy
thing for the free software ecosystem.  Forcing consolidation into one
implementation puts the data format itself at risk (as we have seen from
GnuPG upstream's recent move away from supporting the OpenPGP standard),
and, more importantly, it puts Debian at risk should that implementation
become unsupported or unsupportable.