On 2025-02-27 Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:

Package: php-crypt-gpg
Version: 1.6.9-3
Severity: normal
Tags: patch
Control: affects -1 + src:gnupg2

GnuPG has traditionally disregarded the OpenPGP standard about Cleartext Signature Framework (CSF) messages.

Going back to RFC 2440 (in 1998!) the OpenPGP specification has always
said:

The line ending (i.e. the <CR><LF>) before the '-----BEGIN PGP SIGNATURE-----' line that terminates the signed text is not
considered part of the signed text.

However, the Crypt_GPG test suite expects this CSF message:

```
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello, Bob! Goodbye, Alice!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFI0vkCwJfZ7JTAY2MRAgzTAKCRecYZsCS+PE46Fa2QLTEP8XGLwwCfQEAL qO+KlKcldtYdMZH9AA+KOLQ=
=EO2G
-----END PGP SIGNATURE-----
```

to declare its content *with* the trailing newline:

"Hello, Bob! Goodbye, Alice!\n"

Upstream GnuPG has ignored this specfication
(https://dev.gnupg.org/T7106), but GnuPG in debian is now in alignment
with the specification.

The attached patch should let php-crypt-gpg complete its test suite correctly.

I've also opened https://salsa.debian.org/php-team/pear/php-crypt-gpg/-/merge_requests/1
with this same patch.

[...]

Hello Daniel,

I think this is a bit 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).

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.

cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Andreas--

On Wed 2025-03-12 18:13:49 +0100, Andreas Metzler wrote:

On 2025-02-27 Daniel Kahn Gillmor <dkg@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


-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRjrBGOWy5dZsiKhad4C4VO2cK0lgUCZ9HcvwAKCRB4C4VO2cK0 lroTAQC6lJSnebzjaTJ8HSJXyCjV8ZFlgA6pGKlhR6J0R21m6wEA093gm70p3eP3 186avDAraLv7+0ythRvhtL7qOHJxrwg=
=uL+p
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-03-12 Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:

On Wed 2025-03-12 18:13:49 +0100, Andreas Metzler wrote:

[...]

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.

Hello Daniel,
having this properly fixed upstream would be great or even a must. (I
suspect sequoia chameleon would trigger the same or a similar error as gnupg-patched does.) I also think it is important to not start precedent
in having Debian packages patched to work with (only) "our 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.

[...]

I suspect keeping/putting gnupg in-line with OpenPGP is not going to
simple, we (well, you ;-) ) will need to choose our battles,
concentrating on the most important use-cases or the ones with hard
breakage. Also imho every deviation from upstream gnupg behavior has a
cost of its own, especially possibly breaking compatibility with
unpatched gnupg. That is where my talk about "cost/benefit ratio" came
from. I am just not sure whether the patch is worth the pain.

I hope that helps you in making a good decision. (*Either* way, keeping
or removing the patch.)

thanks, cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On Wed, 12 Mar 2025 at 15:13:03 -0400, Daniel Kahn Gillmor wrote:

On Wed 2025-03-12 18:13:49 +0100, Andreas Metzler wrote:

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.

FWIW, as a current php-crypt-gpg uploader I don't mind having to
maintain such trivial patch to the test suite in order to fix FTBFS with Debian's gpg. Wouldn't mind a more complex upstreamable patch of
course, but I don't consider this to be a blocker.

I intend watch the transitions to make sure the behavior is consistent
for Trixie anyway.

Thanks for the patch!
--
Guilhem.

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEERpy6p3b9sfzUdbME05pJnDwhpVIFAmfTIvkACgkQ05pJnDwh pVI4XA//ev6ST1hnQEGUcemr+fU0le7K6iPav9KFUkE6KdV9LbfV2cGff0G28t+D INZZMaibZ0Qb26rP+9BHmSFfYaB9AMThrnzYQyvYAhAfsjT4z7Kq8tqhB5pNTkTc 5MbcdA/ahEw3j5wU7ju2hd8sI+7NiBWfgyQS3pZBtAG/Ub9spdK7pmNVZHcv+qHW 2xkH5w6xyTAKhSdCbuLMDYQiCH8c0+9UR39cOCC5AnMHnsibsGn/z52/i4Y8Ygj5 LuLB7YZ+47SFcriycoOYNcdg3ksUT2XBhnK0F1Jcl8QalNYcbueww7aeqMYQKAm6 RLNbZRs6LcE8AivTHq71OI8wMacSq0VQLXklCEHjF2IAHqcnr7CJO18cm7Eg/lU4 DCLxi4BQSSnfghdJB+A3yAYaYXo3oqVis7gp2M4mWe1VH5Z3NbLflx6iqeShf84R +hvw7q3UZU2BDx517Q9y6YEQg2Xffy5tIZCQXJtMwTEuOreCodf54EZNnQzii6Nj tsSu67qYGutrIApNFH78WUnXRS3Ajq6Sd841JxY8BlIMuf3jByUNdlpU2kfhv0PZ vKnd7qLK0vpgXBPGohSOoJtGFrHUQpcB+r+2zHdrbVD1P8hEK3Cp3vojtPOPhWhE BDSeb0wxf7C20dgzR+cowISNF633sAw8gseC2hBHGcCoX5cFF3w=
=fBoZ
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu 2025-03-13 19:24:59 +0100, Guilhem Moulin wrote:

On Wed, 12 Mar 2025 at 15:13:03 -0400, Daniel Kahn Gillmor wrote:

On Wed 2025-03-12 18:13:49 +0100, Andreas Metzler wrote:

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.

FWIW, as a current php-crypt-gpg uploader I don't mind having to
maintain such trivial patch to the test suite in order to fix FTBFS with Debian's gpg. Wouldn't mind a more complex upstreamable patch of
course, but I don't consider this to be a blocker.

I've just written a more flexible patch and submitted it upstream as
well:

https://github.com/pear/Crypt_GPG/pull/40

I'm going to push this as php-crypt-gpg 1.6.9-5 -- hopefully this will
help the packages transition smoothly without requiring us to keep a non-compliant GnuPG in debian.

--dkg

-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQRjrBGOWy5dZsiKhad4C4VO2cK0lgUCZ9OHRgAKCRB4C4VO2cK0 lt4YAQDmYgk6kbTfYzG05nm9psIJe1ueYsjh4ZtfLM4CCszgyAEA6WezBAvluhmc yqbwjXL0xqDUgcjSPRXUTgCz9V5tPgo=
=yHxj
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)