We need to get this working in some form for 2.5.0 release.

See:

https://github.com/roundup-tracker/roundup/actions/runs/11767117283/job/32775443731

for the error.

Hmm, this appears to be broken on all CI builds. Even when gpgme is correctly installed.
I am stumped.

Debian no longer ships gpgme-config and 'pip download gpg' fails.

Do we need to move to another package for pgp/gpg support?

Maybe we can use:

  https://pypi.org/project/gpg-lite/?? It supports python 3.7+ but last update was 2022. 

  https://pypi.org/project/gpyg/ was updated in 2024 but support starts at 3.12.

I emailed the roundup-users list over the weekend to see about dropping pgp support.

Email:

Hello everybody:

I am looking at the future of support for PGP encrypted email.

Does anybody (still) use PGP encrypted email?

For those that don't know, you can sign/verify email sent to Roundup
by enrolling user's public keys. I think the intent was to validate
commands and changes sent on the subject line of an email.  It can
also encrypt outgoing PGP emails, but it has issues (issue2550943,
issue2550942).

As far as I can tell it was never well documented. After much struggle
a while ago I managed to get it to work, but I still wasn't able to
document a working process. Also sending PGP encrypted email was not
exactly straightforward.

Before Roundup 1.5, tracker auditors did not even know the source of
the transaction. tx_Source was added to support "email" and
"email-sig-openpgp". Before then, you had to use PGP for all email
from a user. PGP had to be used even if they weren't doing something
that required authentication/authorization. Otherwise you were
vulnerable to forged email.

With 1.5, your auditor can check the source of the transaction. If it
was not pgp signed, you can reject the transaction if certain
operations (e.g. status changes etc.) arrive via email.

Also articles such as:

  https://www.latacora.com/blog/2019/07/16/the-pgp-problem/

  https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/

make me reconsider PGP support. Some of the problems discussed above
don't apply to Roundup's use of PGP. But the overall impression is not
favorable.

Wgat bring this to the front is that I can't build a working PGP
toolchain in Python for our continuous integration platform. See:
https://issues.roundup-tracker.org/issue2551368. This means PGP code

won't be tested unless done locally by a developer.

My thoughts are that PGP was useful in earlier days (2000-2010) when
internet connectivity wasn't as easy, but is not so useful today.

My plan at this point is:

  * announce that PGP support will be included but not tested for
    Roundup 2.5.

  * if a tracker has pgp support enabled, 2.5 will print a warning
    when starting up.

  * remove the PGP code in release 2.6.

Does anybody currently use PGP for tracker emails? If so are you
willing to handle maintenance/documentation of this subsystem and
resolve issues?

More generally, does a method for:

  * verifying the sender and contents of email
  * encrypting sent emails

still have value? If so
https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/ lists a
couple of ideas (e.g. encrypted/signed attachment).

> I am looking at the future of support for PGP encrypted email.

I've answered there. I think there is a good future.

And I'll see if we can look into the GnuPG python module.
There is an officially supported one from the GnuPG team,
the question is just how to build it.

Hi Bern,

Any update on this? All my CI instances are by default 24.04 now.
So testing for 3.10, 3.12 and 3.13 are all missing gpg testing.

> Any update on this? 

Hi John, not yet, 
the end of the year business is very time consuming right now.
It is on my list, thought.