Upgrading/changing from PGP to GnuPG for nl.*

[Adri Verhoef]

Hi, Julien invited me to join news.admin.hierarchies.

As administrator for nl.* I'm still using PGP-2 and that doesn't seem to
do its work anymore on a modern Fedora 40 system without 32-bit libraries.
$ file /usr/local/bin/pgp
/usr/local/bin/pgp: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, stripped
$ readelf -a /usr/local/bin/pgp | grep NEEDED
0x00000001 (NEEDED) Shared library: [libc.so.6]
$ rpm -qa | grep i686 | wc -l
0
$ dnf provides /lib/libc.so.6 | grep x86_64
glibc32-2.39-8.fc40.x86_64 : The GNU libc libraries (32-bit)

In the past I've compiled PGP-2.6.3is myself and configured 'signcontrol' for
the nl-hierarchy. It doesn't compile anymore, not necessarily a disaster, as
we will see.

Now I could go ahead and install the necessary compatible libraries for PGP,
but there's also the option of moving to a more modern approach and the use of
GnuPG:
$ rpm -q gnupg2
gnupg2-2.4.4-1.fc40.x86_64

Before I can use GPG in the Usenet-hierarchy 'nl' I need to register its key
and this is probably the first thing that I should do. Where do I do that?
Before registering I also need to generate the new key. How do I do that?

A step-by-step-approach works best for me as I don't want to make any fatal
mistakes.

The next thing to do is probably configuring a new 'signcontrol' (Perl) and
getting that new 'signcontrol' to work. Julien already pointed me to
https://ftp.isc.org/pub/pgpcontrol/signcontrol and there's much resemblance
to my version from 1998. I've made some local changes there to accommodate
a few particular needs for nl.* (in 2002). The version from 1998 is v1.6.

From 1.9: "# -- Fix error reporting around lock files with PGP." - was that
the error that I fixed in 2002? :-) [variable $lock vs. $pgplock]

Adri

[Julien ÉLIE]

Hi Adri,

Post by Adri Verhoef
Now I could go ahead and install the necessary compatible libraries for PGP,
but there's also the option of moving to a more modern approach and the use of
$ rpm -q gnupg2
gnupg2-2.4.4-1.fc40.x86_64

The last control article sent with your PGP-2 key dates back to 2017
(changing the description of nl.scientology).

I also reckon that moving to a more modern approach is the right thing
to do, in a long-term perspective.
It implies a change of key. As it seems that you won't be sending
control articles in double (signed with both the old PGP-2 key and the
new one), the drawback is that only the news servers that have imported
your new public key will honour your control articles from now on.
It's not critical as it may well happen that the current PGP-2 key is
already not recognized by some (not saying most) servers carrying nl.*!

Post by Adri Verhoef
Before I can use GPG in the Usenet-hierarchy 'nl' I need to register its key
and this is probably the first thing that I should do. Where do I do that?
Before registering I also need to generate the new key. How do I do that?
A step-by-step-approach works best for me as I don't want to make any fatal
mistakes.

About the registration of the new key in PGPKEYS at
<https://ftp.isc.org/pub/pgpcontrol/> so that the subsequent control
articles are taken into account in the ftp.isc.org active and newsgroups
file at <https://ftp.isc.org/pub/usenet/CONFIG/>, just advertising it
here will be enough. Russ will do the necessary stuff to integrate it
into the software which generates the ftp.isc.org files.

It is also time to ask for an update, if needed, of the control.ctl
information (contact, URL) related to your hierarchy:
http://usenet.trigofacile.com/hierarchies/nl.html


About the generation of the new key, I would suggest a 3072-bit or
4096-bit RSA key which *never expires*.
(RSA is widely supported by GnuPG versions in wild, contrary to ECDSA
which may not be recognized by a bit older versions.)

When asked by GnuPG during the generation of the key, put the e-mail
address from which you will send control articles in the key ID (the
real name field), and leave the other fields blank, for better
compatibility with Usenet software.

The command I used to generate the key for fr.* is "gpg
--full-generate-key --allow-freeform-uid", and then answer the questions
with the above recommendations in mind.

After having generated the private and public keys, you should export
your PUBLIC key and make it available from the web site of your
hierarchy, and also announce it in news.admin.hierarchies.

Post by Adri Verhoef
The next thing to do is probably configuring a new 'signcontrol' (Perl) and
getting that new 'signcontrol' to work. Julien already pointed me to
https://ftp.isc.org/pub/pgpcontrol/signcontrol and there's much resemblance
to my version from 1998.

Sure, feel free to use this Perl version of signcontrol :)

[Julien ÉLIE]

Post by Julien ÉLIE
When asked by GnuPG during the generation of the key, put the e-mail
address from which you will send control articles in the key ID (the
real name field)

Hmm, as your current PGP-2 key uses "nl.newsgroups" as key ID, and it is
also your current control.ctl entry ("verify-nl.newsgroups"), just keep
that for your new key and do not use an e-mail adress.

I said that because some other control.ctl entries use an e-mail, but
that's not the case for nl.*.

[Adri Verhoef]

Post by Julien ÉLIE
After having generated the private and public keys, you should export
your PUBLIC key and make it available from the web site of your
hierarchy, and also announce it in news.admin.hierarchies.

There's a small problem, the website that we used (http://nl.news-admin.org/)
exists, but it is out of date and I think there is nobody who has the keys as
far as I can tell, also I don't know what happened to it, since I'm wondering
what "ausadmin" and a proposal for "aus.radio.amateur.dstar" is doing there,
and when you click that last proposal you'll get: "Software error:
Expected /home/ausadmin/vote/aus.radio.amateur.dstar/vote_start.cfg at
/home/ausadmin/perllib/Vote.pm line 125.
For help, please send mail to the webmaster ([no address given]), giving this
^^^^^^^^^^^^^^^^^^
error message and the time and date of the error."

To give you an idea why the list of newsgroups there is somewhat out of date:
"nl.actueel" is missing (created in 2015), nl.erotiek.* was removed in 2009.

At some point in time (2011) we decided to create e-mailaddresses at stack.nl
instead of nic.surfnet.nl, to administrate the nl-hierarchy, but they seem to
be revoked ("<nl-***@stack.nl>: Recipient address rejected: User unknown").

At this moment I guess we (the administrators of nl.*) don't have an official
e-mailaddress, that is what can be concluded. The administrative role, named
nl-admin, consisted of two persons since 2007, Adri Verhoef (=me) & Johan van
Selst; later on, a council was added called 'nl-raad', that consisted of five
persons, including nl-admin. This was reduced to four persons in early 2022,
when Bart Dinnissen stepped down for health reasons; he died later that year.
Johan has an e-mailaddress at stack.nl, obviously he was involved in creation
of the administrative e-mailaddresses at stack.nl, amongst them were nl-admin
and nl-raad, see http://lists.stack.nl/hyperkitty/ - deselect 'Hide inactive'
- they are archived.

UPDATE: Right now I am in contact with Johan again!

[Adri Verhoef]

Post by Adri Verhoef
At some point in time (2011) we decided to create e-mailaddresses at stack.nl
instead of nic.surfnet.nl, to administrate the nl-hierarchy, but they seem to

The official e-mailaddress has been reinstated, thanks to Johan van Selst (co-
nl-admin, the administrative role of nl.*).

Adri

PS
Sometimes it takes a few weeks before I can read news.admin.hierarchies again.

[Adri Verhoef]

Julien,

At the moment I'm testing my scripts; I've successfully configured GnuPG
(at least I think so).

I've added some small improvements in version 1.9 of 'signcontrol':

106c106
< # $use_or_add{'Oranization'} = 'YOUR_ORGANIZATION';
---

# $use_or_add{'Organization'} = 'YOUR_ORGANIZATION';

150c150
< # set to match only hierarchies you will use it on
---

# set to match only hierarchies you will use it on.

Apart from that, I used: my $id_host = `cat ~/mailname`; in my configuration.
Also, I've been playing around with signcontrol-1.9, configuring it some more,
then was unsuccessful getting it to work:

Most probably there was a need for me to add a variable "$pgphomedir" to point
to the correct directory with the secret key, else I would get:
gpg: skipped "nl.newsgroups": No secret key

This is what I've added:

my $pgp = "/usr/bin/gpg";
# From the directory where signcontrol is called we need to find the secret key
# if that key isn't situated in the homedirectory of the caller.
my $pgphomedir = ".gnupg"; # absolute path or directory relative to current one


However, this wasn't enough. My 'gpg' on Fedora 40, gnupg2-2.4.4-1.fc40.x86_64,
doesn't accept the "--pgp2" parameter: gpg: invalid option "--pgp2"

Furthermore, I'm getting: gpg: signing failed: Inappropriate ioctl for device

So, this is what I have now in my version of the code of 'signcontrol':

} elsif ($pgpstyle eq 'GPG') {
if ($pgphomedir) {
# we need a way to add some extra arguments
@command = ($pgp, qw/--detach-sign --armor --textmode -u/, $keyid,
qw/--debug-level advanced/,
qw/--homedir/, $pgphomedir,
qw/--force-v3-sigs/);
} else {
@command = ($pgp, qw/--detach-sign --armor --textmode -u/, $keyid,
qw/--force-v3-sigs --pgp2/);
}
} else {


When I run "./checkgroups -t nl | head" I get:

Newsgroups: nl.newsgroups
Subject: cmsg checkgroups
Control: checkgroups

nl.actueel Discussie over nieuws met grote maatschappelijke impact.
(etc.)

This is fine for now, but when I run "./checkgroups -t nl | head |./signcontrol"
I get:

gpg: enabled debug flags: memstat trust extprog
gpg: enabled compatibility flags:
gpg: no running gpg-agent - starting '/usr/bin/gpg-agent'
gpg: waiting for the agent to come up ... (5s)
gpg: connection to the agent established
gpg: writing to stdout
gpg: pinentry launched (1480141 gnome3:curses 1.3.0-unknown - xterm-256color :0.0 - 9/13 0)
gpg: signing failed: Inappropriate ioctl for device
gpg: signing failed: Inappropriate ioctl for device
gpg: keydb: handles=1 locks=0 parse=1 get=1
gpg: build=0 update=0 insert=0 delete=0
gpg: reset=0 found=1 not=0 cache=0 not=0
gpg: kid_not_found_cache: count=0 peak=0 flushes=0
gpg: sig_cache: total=2 cached=0 good=0 bad=0
gpg: objcache: keys=2/2/0 chains=381,1..1 buckets=383/20 attic=254
gpg: objcache: uids=1/1/0 chains=106,1..1 buckets=107/20
gpg: random usage: poolsize=600 mixed=1 polls=0/3 added=18/720
outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: secmem usage: 1568/65536 bytes in 3 blocks
/usr/bin/gpg returned exit status 512

signcontrol: could not generate signature


According to https://github.com/keybase/keybase-issues/issues/2798 inserting
"export GPG_TTY=$(tty)" is the solution, but when I do that I get 'not a tty':

$ ./checkgroups -t nl | head | GPG_TTY=$(tty) ./signcontrol
gpg: enabled debug flags: memstat trust extprog
gpg: enabled compatibility flags:
gpg: writing to stdout
gpg: pinentry launched (1519899 gnome3:curses 1.3.0-unknown not a tty xterm-256color :0.0 ? 9/13 0)
gpg: signing failed: No such file or directory
gpg: signing failed: No such file or directory
gpg: keydb: handles=1 locks=0 parse=1 get=1
gpg: build=0 update=0 insert=0 delete=0
gpg: reset=0 found=1 not=0 cache=0 not=0
gpg: kid_not_found_cache: count=0 peak=0 flushes=0
gpg: sig_cache: total=2 cached=0 good=0 bad=0
gpg: objcache: keys=2/2/0 chains=381,1..1 buckets=383/20 attic=254
gpg: objcache: uids=1/1/0 chains=106,1..1 buckets=107/20
gpg: random usage: poolsize=600 mixed=1 polls=0/3 added=18/720
outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: secmem usage: 1568/65536 bytes in 3 blocks
/usr/bin/gpg returned exit status 512

signcontrol: could not generate signature


In my configuration, signcontrol needs to be run from crontab in the night,
I don't do that by hand.

Another solution from https://github.com/keybase/keybase-issues/issues/2798 is
pointing to https://d.sb/2016/11/gpg-inappropriate-ioctl-for-device-errors:

| To solve the problem, you need to enable loopback pinentry mode. Add this to ~/.gnupg/gpg.conf:
|
| use-agent
| pinentry-mode loopback
|
| And add this to ~/.gnupg/gpg-agent.conf, creating the file if it doesn't already exist:
|
| allow-loopback-pinentry
|
| Then restart the agent with echo RELOADAGENT | gpg-connect-agent and you should be good to go!

In my case I needed to restart the agent with:
echo RELOADAGENT | gpg-connect-agent --homedir [full_path_to_directory/.gnupg]

Now there is a little bit of a big success!

$ ./checkgroups -t nl | head | ./signcontrol
Use of uninitialized value $version in pattern match (m//) at ./signcontrol line 552.
Use of uninitialized value $version in concatenation (.) or string at ./signcontrol line 556.
Path: bounce-back
From: nl-***@stack.nl
Newsgroups: nl.newsgroups
Subject: cmsg checkgroups
Control: checkgroups
Approved: nl-***@stack.nl
Message-ID: <***@a3.nl.invalid>
Date: Sun, 28 Apr 2024 10:12:56 -0000
Lines: 6
X-Info: https://ftp.isc.org/pub/pgpcontrol/README.html
https://ftp.isc.org/pub/pgpcontrol/README
X-PGP-Sig: Subject,Control,Message-ID,Date,From,Sender
iQIzBAEBCAAdFiEEZvvoTIDjctRUf+kh0vJZXdpaxQQFAmYuISgACgkQ0vJZXdpa
xQT5mRAAlpYTP6ZUSqnojH/kJmhdc+9EGprF/D56XFQ/zB9IRyHvFPPCyso/TAhm
5RyeGlz/9JKyQLXEKeE+Qko5SXA03jcMBsTKqa6XpP5DFhy+1aqJIyhYpiLXklaf
SJc5wV75lQ4Aub6BRJJj4wh2ZjCF8EpaKWl1B4rkeV4A1ffIWDSP/q0uEExGiFkS
EXbP48Mi5nEqSn+pJryD+POHhe+GKvQ+B/oSS9d9bcMe8+/wy+VlMyVGVLnwgr3e
bvAHAtFADDjTiXiTSloM/uQYxyMabo0O2pCH11iG7Ggb7u1VHexMZhbL37CDn3or
Z/PUHcTBef6QMrMu6UY7Vosz7DAcjjSBtPHf2SsiBhaDTZG0kD2Z46NPeSBjS11/
FxtHJmCWsrXqabMYgxmNMAgiZbGTARJAPVCz/32dtQb9rm0jBVJSImKUXnhwgs76
JaFB9xZyF2C2RW6TMXEN1Eg44+BnBJrkzcNSneLiXX5WoaO/rVCbbB6Nzn3hnAhV
oji7+avuCloUi8nwVtL8o9a54usYF4Ej4omDovK5+RJM+/olpJdMfJCh6sZwYYwe
Of4yEsvqeTe6ArRlsR1eN29QacQoDGWuJgEQ0ANm/sapD6d8gr1tu7RuDVhwdgUZ
KyUaveIgyaoWntgL9fYVG/ODtNq/k+xKA+pIIx2MEIhTuKZ2sf0=
=u+UU

nl.actueel Discussie over nieuws met grote maatschappelijke impact.
nl.announce Aankondigingen conferenties, cursussen, enz. (Moderated)
nl.auto Aankondigingen, modellen, techniek, tips en discussie.
nl.burgerrechten Informatiemaatschappij en burgerbelangen.
nl.comp.3d-printen Alles over 3D-printen.
nl.comp.dvd-branden Over het maken en branden van dvd's.


In this part, $version doesn't get assigned with GnuPG's version:

while ($signature[0] ne "\n" && @signature) {
$version = $1 if ((shift @signature) =~ /^Version:\s+(.*?)\s*$/);
}


But 'gpg' does report its version. Here is some of my output if that helps:

$ gpg --version
gpg (GnuPG) 2.4.4
libgcrypt 1.10.3-unknown
Copyright (C) 2024 g10 Code GmbH


To get rid of the 'uninitialized value' I used a stub: my $version = "0.stub";
Unless someone has a (better) fix for this ...


In finishing, I've changed the part where $pgphomedir is studied, using #DEBUG#,
and also omitted --pgp2:

if ($pgphomedir) {
# we need a way to add some extra arguments
@command = ($pgp, qw/--detach-sign --armor --textmode -u/, $keyid,
##DEBUG## qw/--debug-level advanced/,
qw/--homedir/, $pgphomedir,
qw/--force-v3-sigs/);
} else {

About the registration of the new key in PGPKEYS at
<https://ftp.isc.org/pub/pgpcontrol/> so that the subsequent control
articles are taken into account in the ftp.isc.org active and newsgroups
file at <https://ftp.isc.org/pub/usenet/CONFIG/>, just advertising it
here will be enough. Russ will do the necessary stuff to integrate it
into the software which generates the ftp.isc.org files.

As I haven't advertised it yet, I'm gonna go ahead right now:

$ gpg --homedir .gnupg --dry-run --list-keys
.../news/.gnupg/pubring.kbx
------------------------------------
pub rsa4096 2024-04-27 [SC]
66FBE84C80E372D4547FE921D2F2595DDA5AC504
uid [ultimate] nl.newsgroups
sub rsa4096 2024-04-27 [E]

$ gpg --homedir .gnupg --dry-run --list-keys --fingerprint
.../news/.gnupg/pubring.kbx
------------------------------------
pub rsa4096 2024-04-27 [SC]
66FB E84C 80E3 72D4 547F E921 D2F2 595D DA5A C504
uid [ultimate] nl.newsgroups
sub rsa4096 2024-04-27 [E]

$ gpg --homedir .gnupg --dry-run --send-keys 66FBE84C80E372D4547FE921D2F2595DDA5AC504
gpg: sending key D2F2595DDA5AC504 to hkps://keyserver.ubuntu.com
$ gpg --homedir .gnupg --send-keys 66FBE84C80E372D4547FE921D2F2595DDA5AC504
gpg: sending key D2F2595DDA5AC504 to hkps://keyserver.ubuntu.com


Did I do this correctly?

It is also time to ask for an update, if needed, of the control.ctl
http://usenet.trigofacile.com/hierarchies/nl.html

The URL-part isn't correct yet; this is what I have now in my control.ctl:

## NL (Netherlands)
# Contact: nl-***@stack.nl
# URL: http://nl.news-admin.org/info/nladmin.html
# Admin group: nl.newsgroups
# Key fingerprint: 45 20 0B D5 A1 21 EA 7C EF B2 95 6C 25 75 4D 27
# *PGP* See comment at top of file.
newgroup:*:nl.*:drop
rmgroup:*:nl.*:drop
checkgroups:nl-***@stack.nl:nl.*:verify-nl.newsgroups
newgroup:nl-***@stack.nl:nl.*:verify-nl.newsgroups
rmgroup:nl-***@stack.nl:nl.*:verify-nl.newsgroups


BTW, I'm running C News. :-)

After having generated the private and public keys, you should export
your PUBLIC key and make it available from the web site of your
hierarchy, and also announce it in news.admin.hierarchies.

Hopefully I've done all this correctly.

Thank you very much for helping me out so far, Julien!

Adri
PS NOTE: the Contact address nl-***@stack.nl doesn't work yet.

[Julien ÉLIE]

Hi Adri,
That sounds gound. Hopefully it will be helpful to other news admins
who will set it up in the future.

Post by Adri Verhoef
} elsif ($pgpstyle eq 'GPG') {
if ($pgphomedir) {
# we need a way to add some extra arguments
@command = ($pgp, qw/--detach-sign --armor --textmode -u/, $keyid,
qw/--debug-level advanced/,
qw/--homedir/, $pgphomedir,
qw/--force-v3-sigs/);
} else {
@command = ($pgp, qw/--detach-sign --armor --textmode -u/, $keyid,
qw/--force-v3-sigs --pgp2/);
}
} else {

Looking at the flags used by signcontrol.py, it also has:
--emit-version --no-comments --no-escape-from-lines --no-throw-keyids

You may wish to also use them. At least the first one (--emit-version)
solves one of your subsequent question.

Post by Adri Verhoef
|
| use-agent
| pinentry-mode loopback
|
|
| allow-loopback-pinentry
|
| Then restart the agent with echo RELOADAGENT | gpg-connect-agent and you should be good to go!

Indeed, this is a necessary setup if you run the script non
interactively. Maybe you'll also need:
--no-tty --passphrase "xxx"

Matija Nalis, the former administrator of hr.* (Croatia), once asked for
these flags. I don't know whether they are still required by current
GnuPG versions.

Post by Adri Verhoef
X-Info: https://ftp.isc.org/pub/pgpcontrol/README.html
https://ftp.isc.org/pub/pgpcontrol/README

You may want to keep one, and replace the other one with the URL of the
website of the hierarchy.

Post by Adri Verhoef
Did I do this correctly?

I think so.

Post by Adri Verhoef
## NL (Netherlands)
# URL: http://nl.news-admin.org/info/nladmin.html
# Admin group: nl.newsgroups
# Key fingerprint: 45 20 0B D5 A1 21 EA 7C EF B2 95 6C 25 75 4D 27
# *PGP* See comment at top of file.
newgroup:*:nl.*:drop
rmgroup:*:nl.*:drop

The official control.ctl entry will then need being updated with these
new information (stack.nl instead of nic.surfnet.nl).
Also, the new key fingerprint is:
66FB E84C 80E3 72D4 547F E921 D2F2 595D DA5A C504

Post by Adri Verhoef
BTW, I'm running C News. :-)

For C News, from what I heard, it uses a file named controlperm. Does
it also handle the control.ctl syntax? Do you confirm a valid syntax
for controlperm would now be:

nl any n nq
nl any r nq

Post by Adri Verhoef
Hopefully I've done all this correctly.

The technical part is now done.
What will now takes (a long) time is the update of the configuration of
news servers carrying nl.*. It may be worthwhile contacting the news
admins of the most used servers for article postings in the nl.* hierarchy.
It is what we did for the fr.* hierarchy, after having done some stats
about that (from the Path header fields of posts in fr.*).

[Adri Verhoef]

Thanks for answering, Julien.
For now, things have to wait.
Last weekend was a busy one and I will be away for about a week or two.
See you later! Thanks again.
I have to catch my train. :-)

Adri

[Adri Verhoef]

Post by Julien ÉLIE
--emit-version --no-comments --no-escape-from-lines --no-throw-keyids
You may wish to also use them. At least the first one (--emit-version)
solves one of your subsequent question.

This works indeed, thanks. No "0.stub" needed anymore. :-)

Post by Julien ÉLIE

Post by Adri Verhoef
| To solve the problem, you need to enable loopback pinentry mode.

Indeed, this is a necessary setup if you run the script non
--no-tty --passphrase "xxx"
Matija Nalis, the former administrator of hr.* (Croatia), once asked for
these flags. I don't know whether they are still required by current
GnuPG versions.

Thanks, it worked without these flags. :-)

Post by Julien ÉLIE

Post by Adri Verhoef
X-Info: https://ftp.isc.org/pub/pgpcontrol/README.html
https://ftp.isc.org/pub/pgpcontrol/README

You may want to keep one, and replace the other one with the URL of the
website of the hierarchy.

Once 'our' website is reinstated, of course. :-)

Post by Julien ÉLIE

Post by Adri Verhoef
## NL (Netherlands)
# URL: http://nl.news-admin.org/info/nladmin.html
# Admin group: nl.newsgroups
# Key fingerprint: 45 20 0B D5 A1 21 EA 7C EF B2 95 6C 25 75 4D 27
# *PGP* See comment at top of file.
newgroup:*:nl.*:drop
rmgroup:*:nl.*:drop

The official control.ctl entry will then need being updated with these
new information (stack.nl instead of nic.surfnet.nl).
66FB E84C 80E3 72D4 547F E921 D2F2 595D DA5A C504

I have updated this new key fingerprint in my local control.ctl.

Post by Julien ÉLIE

Post by Adri Verhoef
BTW, I'm running C News. :-)

For C News, from what I heard, it uses a file named controlperm. Does
it also handle the control.ctl syntax? Do you confirm a valid syntax
nl any n nq
nl any r nq

It is correct that it uses a file named controlperm.

I have only one line in controlperm:

nl nl-***@stack.nl nrc p nl.newsgroups

Regarding this,
this is what I found in /var/news/bin/ctl/{checkgroups,{new,rm}group}:

# subject to $NEWSCTL/controlperm: four fields per line, first
# a newsgroup pattern, second an author name (or "any"), third a set of
# operations ("n" newgroup, "r" rmgroup, "c" checkgroups), and fourth a set of
# flags ("p" do it iff poster's identity is pgpverified,
# "y" do it, "n" don't, "q" don't report at all, "v" include
# entire control message in report) (default "yv"); the "p" and "n" flags may
# be followed by the ID of the person permitted to pgpverify;
# the pgpverify program (not supplied) is presumed to be in $NEWSBIN

In the meantime, I've downloaded the latest version of pgpverify (1.30) from
https://ftp.isc.org/pub/pgpcontrol/pgpverify, but the version that goes with
my operating system (Fedora 40), /usr/libexec/news/pgpverify from INN-2.7.1,
says it is version 1.31. So what is going on here?

They are dated:
# Version 1.30, 2018-01-21
# Version 1.31, 2022-06-12

# Changes from 1.30 -> 1.31
# -- Add a $gpg_has_allow_weak_digest_algos_flag variable to specify whether
# gpg supports the --allow-weak-digest-algos flag. This variable will
# be overriden by INN::Config, if used. GnuPG 1.4.20 and 2.0.23 introduced
# this flag, necessary to verify the signatures of old PGP keys still in
# use for some hierarchies.
# -- Using at least GnuPG 1.4.20 or 2.1.0 is no longer required; this version
# of pgpverify will still work with previous versions of GnuPG. However,
# only GnuPG 1.x and 2.0.x will be able to validate signatures made with
# old PGP keys.

Adri

[Julien ÉLIE]

Hi Adri,

Post by Adri Verhoef

Post by Julien ÉLIE
For C News, from what I heard, it uses a file named controlperm.

Regarding this,
# subject to $NEWSCTL/controlperm: four fields per line, first
# a newsgroup pattern, second an author name (or "any"), third a set of
# operations ("n" newgroup, "r" rmgroup, "c" checkgroups), and fourth a set of
# flags ("p" do it iff poster's identity is pgpverified,
# "y" do it, "n" don't, "q" don't report at all, "v" include
# entire control message in report) (default "yv"); the "p" and "n" flags may
# be followed by the ID of the person permitted to pgpverify;
# the pgpverify program (not supplied) is presumed to be in $NEWSBIN

Thanks for this valuable information.

Post by Adri Verhoef
In the meantime, I've downloaded the latest version of pgpverify (1.30) from
https://ftp.isc.org/pub/pgpcontrol/pgpverify, but the version that goes with
my operating system (Fedora 40), /usr/libexec/news/pgpverify from INN-2.7.1,
says it is version 1.31. So what is going on here?
# Version 1.30, 2018-01-21
# Version 1.31, 2022-06-12
# Changes from 1.30 -> 1.31
# -- Add a $gpg_has_allow_weak_digest_algos_flag variable to specify whether
# gpg supports the --allow-weak-digest-algos flag. This variable will
# be overriden by INN::Config, if used. GnuPG 1.4.20 and 2.0.23 introduced
# this flag, necessary to verify the signatures of old PGP keys still in
# use for some hierarchies.
# -- Using at least GnuPG 1.4.20 or 2.1.0 is no longer required; this version
# of pgpverify will still work with previous versions of GnuPG. However,
# only GnuPG 1.x and 2.0.x will be able to validate signatures made with
# old PGP keys.

Version 1.31 included in INN 2.7.0 and 2.7.1 is the latest one. It just
had not been reflected upstream yet. It will probably be done along
with the next update of ftp.isc.org stuff with your new key for nl.* :)