Hi Gioele--
On Thu 2023-12-21 11:02:06 +0100, Gioele Barabucci wrote:
> On 21/12/23 04:16, Daniel Kahn Gillmor wrote:
> As the Uploader of rust-sequoia-openpgp, what do you think of the
> related sequoia-chameleon-gnupg project [1] (drop-in replacement for gpg
> that uses sequoia internally)?
>
> Would it work as a stop-gap measure while the Debian infrastructure
> moves from GnuPG to something else (to `sop`, for instance)?
>
> [1] https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg not yet in
> Debian AFAIK
Thanks for pointing this out! It looks interesting, but i've never used
it (or even tested it) myself. I don't think it can be a completely
perfect, feature-for-feature replacement for GnuPG, given the
overwhelming complexity and peculiarity of the GnuPG interface, but I
imagine it would work for some people, for some purposes.
I certainly wouldn't object to anyone packaging it for debian as long as
it ships its binary interface someplace other than /usr/bin/gpg. Modulo
dealing with the rust dependencies, that seems like an obviously
reasonable and straightforward thing to try to do.
I don't know how the "chameleon" would compare with GnuPG itself in
terms of performance or some of the scaling concerns i mentioned in my
earlier e-mail, but such a straightforward deployment should make it
easy to test.
If you're asking about using /etc/alternatives or something like that to
provide some sort of generic swapping capability, or a dpkg Provides:,
such that /usr/bin/gpg on some systems would point toward the
"chameleon", i would want to see some significant archive-wide testing
done before we even consider inflicting that on our normal users. This
would be the kind of thing that the experimental archive is designed
for.
One of the ongoing challenges with GnuPG development is the fear of
dropping or mis-handling some feature or flag or option or configuration
that someone has stuffed into some script somewhere and completely
forgotten about. GnuPG itself deals with this kind of problem
regularly, and sometimes things like this do break during an upgrade.
Clawing the way back from such a break actually ends up making the
interface even more complex and surprising to those people who haven't
seen how it accreted in the first place :/ It was scary enough to change
/usr/bin/gpg to move from the 1.4 branch to the 2.x branch many years
ago (we shipped the 2.0 branch as /usr/bin/gpg2, and only finally made
/usr/bin/gpg update when the 2.1.x branch was sufficiently mature). And
even thenm we dealt with the fallout from that change for years
(e.g. see /usr/bin/migrate-pubring-from-classic-gpg in the gnupg-utils
package). The differences were enough that I resisted using
/etc/alternatives to let each installation decide which package offered
/usr/bin/gpg1, because of the dangerous side effects of switching back
and forth (see #806904 for example, and the conversations at DebConf14).
I can only imagine that trying to ship the "chameleon" as /usr/bin/gpg
would face some of the same challenges, probably even more severely.
At best, something like this would be a stop-gap, as you say. i
wouldn't want the long-term health of *PGP functionality in debian to
depend specifically on the command-line interface for /usr/bin/gpg,
regardless of who is implementing it. Even GnuPG upstream appears to
agree with this sentiment, as they encourage programmatic users of GnuPG
to use libgpgme, which is supposed to hide some of the command-line
complexity.
--dkg
Attachment:
signature.asc
Description: PGP signature