Someone sending me S/MIME email caused mutt+gpg to open an insane pair of
sequential dialogue window asking multiple questions about whether I trust
what looked like one of Comodo's CA certificates.

The second dialogue included a fingerprint of unspecified sort, that I was
supposed to check against something, but the GTK interface didn't support
copying and pasting.

The useful information would have been:

1. Is this certificate in Debian's ca-certificates package? If so, dont show
the dialogue, just accept the certificate.

2. If this certificate *isn't* in Debian's ca-certificates package, that is
the single most important thing to tell the user. It's still probably a
useless dialogue, but maybe one user in a thousand will want to do the
research on where the CA cert came from.

Hi Gregor, everyone--

I agree that this is not only tedious -- it's an impossible question for
users to answer, especially if the signature verification is done at
indexing time, when the user doesn't even have a smidgen of context.

See also https://bugs.debian.org/888025 for a mutt+gpgsm example of this
kind of frustration. (i'm cc'ing that bug report since it has seen no
decisive action; perhaps this discussion will help move things along
there)

The current behavior is:

   The user sees "do you ultimately trust XXX to correctly certify user
   certificates?", with "cancel" and "yes".

   If they answer "yes", they're asked "please verify that the
   certificate identified as XXX has the fingerprint YYYY", with
   "cancel", and "correct"

i can't imagine any situation where a user is equipped to answer the
first question -- even if they believe that it's being asked in good
faith.  and the second question is somehow even more impossible.  What
certificate?  How is the user supposed to know what to verify here?

I'm one of the debian maintainers for gnupg, and i admit that i haven't
put a lot of work into the gpgsm system integration.  I did a bit of
digging just now, and i've got some ideas, but be warned that i haven't
dug deeply into the tradeoffs here yet.  i welcome feedback!

looking at the documentation for trustlist.txt in gpg-agent(1) (it seems
odd to have it documented there, since i thought gpg-agent was for
secret key material only, weird!), it looks like trustlist.txt has an
`include-default` option, which maybe defaults to
`/etc/gnupg/trustlist.txt` on debian (i haven't done much testing!)

Of course, gpgsm has to learn about these root certificates somehow as
well, and i think doesn't have an easy way to make use of a separate
keybox (perhaps Werner or another GnuPG dev can correct me on this).

Read gpgsm(1), i see that /usr/share/gnupg/com-certs.pem could be set up
as a symlink to /etc/ssl/certs/ca-certificates.crt.  But this only works
to import those root certificates at the initial creation of
pubring.kbx, so it won't work in an ongoing way (e.g. when
ca-certificates gets updated, they won't be updated.

So, what can Debian do to improve this integration?  here is a series of
suggestions of changes to the gnupg2 source package in debian (i have no
code to back them up yet, commentary and patches welcome):

 * make sure gpgsm Recommends: ca-certificates

 * add /etc/ca-certificates/update.d/gnupg to the gpgsm package (see
   update-ca-certificates(8) for a description of this hook), which
   should maintain /var/lib/gnupg/trustlist.txt and
   /var/lib/gnupg/ca-certificates.kbx .  (Maybe add a postinst script to
   invoke this as well?)

 * consider adding a symlink (a conffile, yuck):

   - /etc/gnupg/trustlist.txt → /var/lib/gnupg/trustlist.txt

 * add a symlink to the gpgsm package:

   - /usr/share/gnupg/com-certs.pem → /etc/ssl/certs/ca-certificates.crt

 * (maybe) change the default of gpg-agent's allow-mark-trusted to be
   false, rather than true.  This is both a safety precaution, and a
   usability improvement, since i can't think of a context in which the
   user is well-prepared to actually answer these questions in the way
   that they're presented.

This is still imperfect (the client has no way to learn of certiifcates
added via ca-certificates after they've first populated their
pubring.kbx), but it strikes me that it would be a strict improvement
over the status quo.

What do you think?

After doing a brief review, i have a bunch more questions for GnuPG
upstream too:

 * Could i convince you to search for trustlist.txt in
   /var/lib/gnupg/trustlist.txt as the system default, if
   /etc/gnupg/trustlist.txt is not found?

   That is, if no trustlist.txt is present in $GNUPGHOME, or if
   $GNUPGHOME/trustlist.txt has the include-default directive, it looks
   first for /etc/gnupg/trustlist.txt.  if it is found, it uses it.  if
   it is not found, it looks in /var/lib/gnupg/trustlist.txt.

   That would relieve me of needing to maintain a conffile in the debian
   package, which i would strongly prefer.

 * if i have an auto-generated /var/lib/gnupg/ca-certificates.kbx that
   is kept in sync with the system trustlist, is there a way that i can
   coax gpgsm to use it as a secondary (read-only) keyring by default?
   (i'm not asking for presence in this keyring to be used to infer
   trust; just that these certificates are always known, and can
   therefore be referenced (or deliberately ignored or marked
   untrustworthy) in the user's trustlist.txt.  Is such an option
   available already?  the gpgsm(1) manpage doesn't even mention
   --keyring, but it seems to support --keyring anyway.  so maybe there
   are other options i'm not aware of that could do this already, like
   some sort of --system-keyring ?

 * can i convince you to disable "allow-mark-trusted" in gpg-agent by
   default?  What is the use case where this seems like a sensible thing
   to offer?

 * can we improve the documentation of trustlist.txt?  From the comments
   auto-written to this file, it looks like it's intended to be part of
   the GnuPG family's "API" -- users are told how to deal with this file
   when editing it directly.  If that's the case, we really need to know
   what it is supposed to do, in a concise and easily findable way.

   gpgsm(1) refers to it, but doesn't direct the user toward any other
   documentation.  The comments written into the file when it is
   auto-generated are unclear.  what does the 'S' and 'P' and '*' flag
   mean?  (in the codebase, i see that they mean "S/MIME" and "PGP" and
   either, but that's still unclear.  what is the fingerprint *of* -- is
   it the X.509 certificate?  if so, what could 'P' possibly mean? Is it
   the OpenPGP v4 fingerprint?  if so, what could 'S' possibly mean?
   What would this fingerprint mean for '*'?  if it's 'P', does that
   mean it has an effect on gpg and not just gpgsm?)

   doc/debugging.texi claims:

      You may use the @code{relax} flag in @file{trustlist.txt} to
      accept the certificate anyway.  Note that the fingerprint and this
      flag may only be added manually to @file{trustlist.txt}.

   And yet, when i use:

      gpg-connect-agent "$DIGEST S whatever" /bye

   it seems to add the "relax" keyword.

   The header auto-written into trustlist.txt is not only bulky -- it's
   prone to falling out of date.  If this were better documented, and
   that documentation were placed someplace stable by the installed
   package, then when writing out a trustlist.txt, you could just have a
   one-line header pointing to the documentation.



To be clear, my goals here are similar to my goals for gpg:

 * default user configuration should be as close as possible to no
    configuration at all

 * the default system configuration should also be as close to no
   configuration as possible.

 * the package should ship with good documentation in a stable,
   easily-findable place.

 * the defaults should be well integrated into the host operationg
   system.

 * it should be possible for the user to have their user account diverge
   from the system defaults as narrowly as possible, while still
   receiving updates to the system defaults during package upgrades that
   retain their divergences.

 * it should be possible for the system administrator to have the system
   defaults diverge as narrowly as possible from the package defaults,
   without doing a lot of work at package upgrade to retain that
   divergence.

Happy to hear any feedback about these suggestions and questions!

Looking at the manual [1] it seems like a potentially more clean way to do
this might be to synchronize or symlink the trusted ca-certificates with the
directory /etc/gnupg/trusted-certs/; maybe that's what the option refers to:

Another drawback to the before proposed solution, which would work only on
keyring creation, may be when a CA gets deleted from ca-certificates, but
sticks around as trusted for a user. Irregardless either would be an
improvement over blindly choosing "Correct."
Off-topic, but is the Bash completion support from upstream or downstream?
gpgsm doesn't support it, which makes mixing up gpg/gpgsm arguments more
cumbersome.

[1] https://www.gnupg.org/documentation/manuals/gnupg/Dirmngr-Configuration.html

Just a note that this seems to have gotten much worse at least for some users
in the bookworm testing cycle running kmail. I and at least one other user I
know about get popups every few hours about some random certificates, probably
because someone at some point sent me an email with S/MIME.

A proper fix which doesn't involve manually copying down a long fingerprint
into a configuration file would be much appreciated.

Dear maintainer,

I've recently started to re-experience that bug (#888025), probably because
someone is sending me emails using some "certificate".

It is in the form of a popups when Kmail is opened in the background. Those
popups come randomly without user action.

I understand it would be useless to answer yes to the popup. Additionally, it
doesn't seem legit/safe at all, for someone who doesn't have the necessary
knowledge, to answer yes to "do you ultimately trust XXX to correctly certify
user certificates?"

I've read the explanations/comments in the bug, but I didn't understand
anything, sorry.

The certificate in the popup is the same as this one:

```
$ awk -v cmd='openssl x509 -noout -subject' '/BEGIN/{close(cmd)};{print |
cmd}' < /etc/ssl/certs/ca-certificates.crt | grep 'Manchester.*AAA'
subject=C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited,
CN = AAA Certificate Services
```

I've been told to try: `sudo dpkg-reconfigure ca-certificates`, but that didn't
change anything.

It won't crash the system, but it's very very annoying/disruptive for the
user.

Thanks,
Chris

Dear maintainer,

I've recently started to re-experience that bug (#888025), probably because
someone is sending me emails using some "certificate".

It is in the form of a popups when Kmail is opened in the background. Those
popups come randomly without user action.

I understand it would be useless to answer yes to the popup. Additionally, it
doesn't seem legit/safe at all, for someone who doesn't have the necessary
knowledge, to answer yes to "do you ultimately trust XXX to correctly certify
user certificates?"

I've read the explanations/comments in the bug, but I didn't understand
anything, sorry.

The certificate in the popup is the same as this one:

```
$ awk -v cmd='openssl x509 -noout -subject' '/BEGIN/{close(cmd)};{print |
cmd}' < /etc/ssl/certs/ca-certificates.crt | grep 'Manchester.*AAA'
subject=C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited,
CN = AAA Certificate Services
```

I've been told to try: `sudo dpkg-reconfigure ca-certificates`, but that didn't
change anything.

It won't crash the system, but it's very very annoying/disruptive for the
user.

Thanks,
Chris

I'm using kmail and am getting hit by this. It seems to be someone has sent me
an email signed with some weird (internal?) certificate. What can I as a user
even do if I *don't* trust the certificate? There is no "No, and please stop
asking" option...

Best,
Brendon

Also noticed a modal messagebox popping up regularly when having kmail running.
Below is a workaround that simply always answers the question with no instead of asking.

--- gnupg2-2.2.43.orig/agent/trustlist.c
+++ gnupg2-2.2.43/agent/trustlist.c
@@ -687,6 +687,9 @@ agent_marktrusted (ctrl_t ctrl, const ch
   if (!nameformatted)
     return gpg_error_from_syserror ();

+  // We do not trust this. Do not show that dialog.
+  return gpg_error (GPG_ERR_NOT_TRUSTED);
+
   /* First a general question whether this is trusted.  */
   desc = xtryasprintf (
                 /* TRANSLATORS: This prompt is shown by the Pinentry

I've attached a screenshot of the way this dialog appears on my screen after
updating my workstation to Unstable (on Bookworm it didn't appear).

The first issue is that it doesn't say that program it is the titlebar has the
PID and I had to run ps and grep for that number to find out that it was the
command "gpgsm --logger-fd 110 --server".  When a window appears unexpectedly
it should clearly say what program it is, in this case "gpgsm".

The next issue is that it doesn't say why it appeared.  Some comments on this
bug report suggest that kmail is responsible and I am running kmail.  It
should say what called it.

The issue of the question being unanswerable is the third issue about this.
Even if the question was answerable with complete information it probably
wouldn't be if the user doesn't know what program is asking and what program
made it ask.