Hi Andreas-- On Wed 2025-03-12 18:13:49 +0100, Andreas Metzler wrote: > On 2025-02-27 Daniel Kahn Gillmor <d...@fifthhorseman.net> wrote: >> Package: php-crypt-gpg
> I think this is a bit worrying.
I agree that it's worrying.
> php-crypt-gpg 1.6.9-3 can be built against gnupg 2.2.46-1 but fails
> against gnupg 2.2.46-3 and later. And vice versa the patched testsuite
> of php-crypt-gpg 1.6.9-4 only works with gnupg 2.2.46-3 (or similarily
> patched versions of 2.4).
yes, i think that's correct. If you'd prefer, i can offer a patch to
php-crypt-gpg's test suite that accepts whether there's a trailing
newline or not. That kind of flexible patch could be upstreamable, and
would work with a patched or non-patched GnuPG.
> So this cannot be applied upstream. Afaiui this is nowadays niche,
> non-recommended usage of gnupg so I wonder whether the cost/benefit
> ratio for applying this patch to our gnupg packages (or including it
> in FreePG) is good enough.
if we want GnuPG to interoperate with standard-following OpenPGP tools,
then we need GnuPG to sign the material that is actually passed in, and
emit the material that is actually signed. While i agree that the CSF
is deprecated, it is still widely used (e.g. debian's InRelease uses
it), and any interoperability test that tries to round-trip data through
two different implementations will flag this as a problem.
I see the goal of my debian GnuPG work as being that we should provide a
tool to debian users that will interoperate with any OpenPGP
implementation as best as we can.
Would you be ok if i offer a more flexible (upstreamable) patch for
php-crypt-gpg? Or do you think we should address this concern some
other way?
Thanks for your close review and consideration here! I'm very grateful
to be doing this work with your active engagement.
--dkg
signature.asc
Description: PGP signature
