The user manual and admin manual are missing directions on how to 
deploy/use PGP encrypted emails.

The user manual should include how to set the public key. Setup
on the client side to PGP sign the email should not be included.

Admin manual should discuss settings and what needs to be set up
in the config.ini file to sign/encrypt emails.

From what I just scanned it looks like the key needs to be on the 
filesystem??? I would expect pgp pub keys to be uploadable via the
web interface.

Yes, the system account running roundup needs to have the keys available in
the default keyring, so you need to use "gpg --import" to import keys of
users, and you need to generate a secret key for the tracker on the command
line, too.

Allowing key updates via the web interface would need very good verification
so that keys only contain email addresses that are valid for this user.

And if a key (or encryption subkey) expires, you can't add new messages to
issues where the corresponding user is in the nosy list, so I have created
https://hg.intevation.de/adminton/file/default/shebang/gpg-keyring-check-expire
to check for keys that will expire in the near future.
I run this once per week via crontab.

Initial attempt at docs added in changeset:   8478:ed4ef394d5d6

Note that importing pgp keys can cause issues like DOS/resource consumption
ref: https://nvd.nist.gov/vuln/detail/CVE-2022-3219.

This makes supporting user driven addition of a key (via public key file upload on the
user object) or setting KEYID for import from a keyserver untenable.

In the docs I added suggestion to load into a throwaway keystore so they can be analyzed
for excessive sigs or the import can be aborted without accessing the production keystore.

AFAICT, there is no way to have a public key in a file and use --list-signs. It has to be
--import (ed) for --list-sigs to work.

Thomas:

You said:

> And if a key (or encryption subkey) expires, you can't add new messages to
> issues where the corresponding user is in the nosy list

Does this block anybody from adding a message to the issue (via email or http)?
Or is only the user with the expired key blocked?

Mi initial interpretation made me think all message addition fails when 
Roundup is unable to create an encrypted nosy email to the user with the expired key.
But I don't see how that would happen as email is sent in a reactor after the message
has been added. I also would have expected the user to be able to add a message via HTTP
since I see the PGP machinery invoked only via the email gateway.

I would like to add this case to the admin_guide. Also I don't have access to the
script https://hg.intevation.de/adminton/file/default/shebang/gpg-keyring-check-expire.
hg.intevation.de is taking too long to respond.

Thanks.

-- rouilj

* John Rouillard <issues@roundup-tracker.org> [20251207 23:29]:
> Thomas:
> 
> You said:
> 
> > And if a key (or encryption subkey) expires, you can't add new messages to
> > issues where the corresponding user is in the nosy list
> 
> Does this block anybody from adding a message to the issue (via email or http)?
> Or is only the user with the expired key blocked?

It blocks anyone from adding messages.

> Mi initial interpretation made me think all message addition fails when 
> Roundup is unable to create an encrypted nosy email to the user with the expired key.
> But I don't see how that would happen as email is sent in a reactor after the message
> has been added. I also would have expected the user to be able to add a message via HTTP
> since I see the PGP machinery invoked only via the email gateway.

It fails via http as well, users get an internal server error.
(but I haven't tested expired keys in a long time, this was with
Roundup 1.6)

> I would like to add this case to the admin_guide. Also I don't have access to the
> script https://hg.intevation.de/adminton/file/default/shebang/gpg-keyring-check-expire.
> hg.intevation.de is taking too long to respond.

AI training bots :(

They scan all repsitories with all changesets in all possible ways
to vie them just to train their language models. We tried blocking
their IPs or even whole networks, but new ones keep appearing every
other week, so we gave up for now and just configured an automatic
restart of the server every other hour. Just try again, it should
work often enough ... 

But for easier access:

#!/bin/sh
#
# Copyright (C) 2019 by Intevation GmbH
# Authors:
# Thomas Arendsen Hein <thomas@intevation.de>
#
# check if OpenPGP keys in a specific keyring are about to expire

# run check this number of days in the future:
DAYS=60

# regexp of long keyids to ignore:
SOME_KEY="exampleabcd1234" # no encryption subkey
IGNORE="^($SOME_KEY)$"

KEYRING="$HOME/.gnupg/pubring.gpg"

GPG="gpg --no-options --trust-model always --no-default-keyring --keyring $KEYRING"

$GPG --with-colons --list-public-keys \
| awk -F: -v IGNORE="$IGNORE" '$1 == "pub" && $5 !~ IGNORE { print $5 }' \
| while read recipient; do
    echo test | faketime -f +"$DAYS"d $GPG -q -er "$recipient" >/dev/null 2>&1 \
    || $GPG --list-public-keys "$recipient"
done