InterNetNews / inn

INN (InterNetNews) Usenet server
https://www.isc.org/othersoftware/#INN
Other
68 stars 12 forks source link

Allow perl-nocem to use both gpgv1 and v2 #283

Closed nelgin closed 8 months ago

nelgin commented 9 months ago

While trying to deal with the spam issue, I came upon an issue. Since some pgp keys for checkgroups are old v1 keys, I had to use gpgv1 however this breaks modern gpgv2 keys. It seems both cannot exist at the same time.

It would be nice if perl-nocem and maybe other tools were modified to first check for a gpgv1 key and then check for gpgv2 key. Maybe allow creating of something like ncmring1.gpg and ncmring2.gpg for different versions.

Thanks,

Julien-Elie commented 9 months ago

For the time being, couldn't you just duplicate pgpverify, controlchan and perl-nocem to pgpverify2, controlchan2 and perl-nocem2? Force the path to GnuPG 1 binaries and pgpverify in the first ones, and GnuPG 2 binaries and pgpverify2 in the second ones. Then duplicate the newsfeeds entries for controlchan and perl-nocem. This way, all the messages will be processed once (assuming you only put the legacy PGP-2 keys in the GnuPG 1 ring). This method is worth trying, as the scripts currently do not handle 2 installations of GnuPG. The right move however should really be to generate new modern keys for still active senders...

nelgin commented 9 months ago

I could do. I don't like the idea of maintaining a separate version of the file that I'd have to keep in sync with any changes, and I'm sure I'm not the only person who is facing a similar challenge. I feel if I do a workaround, the core issue will never be addressed.

I totally agree with you, however, that new modern keys for active senders would be preferable, but how is that achieved?

Julien-Elie commented 9 months ago

The core issue is that GnuPG 1 should no longer be used, and is eventually being removed from distributions. Active senders should take the time to generate new keys.

nelgin commented 9 months ago

Maybe it's time to just bite the bullet and do away with gpgv1 then and deal with v2 only.

Julien-Elie commented 9 months ago

As far as I understand, the real issue only came up recently because of the unusual choice of an EDDSA key for the new usenet.ovh NoCeM issuer, not supported by libgcrypt shipped with some distributions. On Usenet, we previously had the possibility of just using GnuPG 1 which can deal with all RSA and DSA keys in the wild, either for signing control articles or NoCeM notices. This new EDDSA key is not widely supported by GnuPG implementations, which causes the current problem discussed in news.software.nntp.

Unfortunately, even enforcing GnuPG 2 in INN won't fix the problem as it is deeply inherent with libgcrypt like the one shipped with Ubuntu which even cannot decode it:

root@paganini:~# /usr/bin/gpg --version
gpg (GnuPG) 2.2.27
libgcrypt 1.9.4
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH

Ivo had to rebuild GnuPG from sources to add EDDSA support. It is not something we should recommend in INN so I propose to close this ticket as it wouldn't actually solve the problem.

I agree with you that the right move is to assume that GnuPG 1 is no longer a viable solution for the long-term, so current senders of control articles should generate a new RSA key. For the recall, I am speaking of belwue, de, ffm, fido7, hun, it, ka, linux, openwatcom, uk and z-netz(which sent control articles these last 10 years, and still have old PGP-2 keys no longer unsupported in current GnuPG 2 releases).

I unfortunately do not have a solution for a proper support of EDDSA keys (the original reason of this discussion). Ideally, RSA should have been preferred as more widely supported.

nelgin commented 9 months ago

My results for gpg --version are quite different from yours. But yes. let's close this then.

# gpg --version
gpg (GnuPG) 2.2.27
libgcrypt 1.9.4
Copyright (C) 2021 Free Software Foundation, Inc.
License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /root/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

Ubuntu 22.04.3 LTS

$ gpg --version
gpg (GnuPG) 2.2.35
libgcrypt 1.10.1
Copyright (C) 2022 g10 Code GmbH
License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /news/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
        CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

Ubuntu 22.10

Julien-Elie commented 9 months ago

I also have EDDSA in my Debian installation but apparently that's not the same for everybody. See Ivo Gandolfo's configuration in the "perl-nocem and GPG version" thread in news.software.nntp last month.