Thanks to you both anyway!
]]>All the more I think the best way for you to deal with these unwanted prompts is to just disable the user trustlist.
I had hoped that the gpgsm log provides some indication (some kind of user agent) of the calling application, but apparently it doesn't, so figuring out what makes (presumably) kmail try to mark CA certificates trusted every hour may be tedious. If disabling the user trust list works for you it just may not be worth the effort…
]]>https://dev.gnupg.org/rG6ba5b6b85451ef6 … 551e11b97b would have thrown a EPERM from gpg agent and this would indeed very much suggest that there has been a bug that got fixed by random chance while addressing a windows-specific problem…
You could try to build gnupg w/ that patch reverted, https://wiki.archlinux.org/title/Arch_Build_System
I've not looked in detail in the (very lenghty) expert-debug logs, but what jumps to my eye pretty much at the beginning is this difference:
2.2.40:
2023-03-13 11:33:38 gpgsm[46942] DBG: chan_7 -> MARKTRUSTED xxx S /CN=GlobalSign/OU=GlobalSign Root CA - R3/O=GlobalSign
2023-03-13 11:33:38 gpgsm[46942] DBG: chan_7 <- ERR 67141739 Die Operation ist nicht erlaubt <GPG Agent>
2023-03-13 11:33:38 gpgsm[46942] DBG: get_keygrip for public key
2.2.41:
2023-03-14 08:50:40 gpgsm[20858] DBG: chan_7 -> MARKTRUSTED xxx S /CN=GlobalSign/OU=GlobalSign Root CA - R3/O=GlobalSign
2023-03-14 08:50:40 gpgsm[20858] DBG: chan_7 <- INQUIRE PINENTRY_LAUNCHED 20861 qt 1.2.1 - - :0 - 1000/984 0
2023-03-14 08:50:40 gpgsm[20858] DBG: chan_7 -> END
2023-03-14 08:50:50 gpgsm[20858] DBG: chan_7 <- ERR 83886179 Verarbeitung wurde abgebrochen <Pinentry>
2023-03-14 08:50:50 gpgsm[20858] Interaktives vertrauenswürdig-Markieren ist in dieser Sitzung ausgeschaltet
2023-03-14 08:50:50 gpgsm[20858] DBG: get_keygrip for public key
at line 47. Before and after that it looks pretty identical on first glance.
I'll check the other points later when i have more time.
Also, try to set the following options in ~/.gnupg/gpgsm.conf:
log-file /home/Termy/gpgsm.log
debug-level expert
This should (I don't know if --logger-fd perhaps overrides --log-file) log a lot into the given log file; this will not point to the cause directly, but it should at least tell you what exactly gpgsm is doing.
]]>I'm sorry, but I just can't say. I neither use KMail nor regular GPG. Personally, I don't bother with encrypted mail, and my workplace uses S/MIME exclusively (and I only use gpgsm only for Git signing, not for mails). This is how a recent DHL notice with a valid S/MIME signature looks like in Evolution (which doesn't use GPG for S/MIME but has its own implementation): https://0x0.st/Hi3N.png Don't know if that helps though…
Looks at least somewhat how i would have expected it, don't know regular gpg with evolution though ^^
As for downgrading GPG: If I understand the past comments here correctly you're seeing the prompt roughly once an hour? And you tried downgrading gnupg for about three hours? Yet after the initial update it took two full days for the prompt to appear?
If that's correct, then I think it's a bit weird a timing: The update to GPG should cause prompts so frequent as to really annoy you, but only after waiting for two full days? This doesn't really fit; I think you should keep using a downgraded GPG for longer time, perhaps at least several days before you draw a final conclusion.
Not only roughly, but precisely after every 60min. Iirc i had gnupg downgraded overnight, so it also survived a reboot. The two days were the time period it took it for me to get annoyed enough to look deeper into it and ultimately post here
But i guess you are not wrong about making sure the downgrade really does help permanently.
And then, if you've really confirmed that a downgrade fixes the situation for a longer period, I think the first step for a proper bug report would be to try and reproduce the issue without kmail involved, just by feeding something to the gpgsm binary, so as to have a reliable and automated way to trigger the prompt. Once you have that you can start bisecting all changes between 2.2.40 and 2.2.41 (not that many) which should quickly isolate the broken commit.
Figuring out what exactly KMail is calling that triggers the prompt is what seth and me were trying to do i'd say. Sadly, i still have no idea what it could be/how to find a manual method to trigger it.
But first things first, i'll downgrade gnupg again and report back tomorrow or so if it really helped.
As for downgrading GPG: If I understand the past comments here correctly you're seeing the prompt roughly once an hour? And you tried downgrading gnupg for about three hours? Yet after the initial update it took two full days for the prompt to appear?
If that's correct, then I think it's a bit weird a timing: The update to GPG should cause prompts so frequent as to really annoy you, but only after waiting for two full days? This doesn't really fit; I think you should keep using a downgraded GPG for longer time, perhaps at least several days before you draw a final conclusion.
And then, if you've really confirmed that a downgrade fixes the situation for a longer period, I think the first step for a proper bug report would be to try and reproduce the issue without kmail involved, just by feeding something to the gpgsm binary, so as to have a reliable and automated way to trigger the prompt. Once you have that you can start bisecting all changes between 2.2.40 and 2.2.41 (not that many) which should quickly isolate the broken commit.
]]>I am not familiar with KMail, so unfortunately I can't help you with finding S/MIME signed mails.
Would it usually be displayed similar to 'regular' signed mails? If so, then i'm 99.9% sure i didn't receive any lately, as i haven't received a signed mail at all in a while now.
gpgsm doesn't have a --logger-file option here in fact; I think your change simply prevents the gpgsm server from starting ("chmod a-x gpgsm" would probably have the same effect), effectively disabling gpgsm and naturally stopping all prompts about S/MIME. According to "gpgsm --help" only "--log-file" exists; try to use that instead of "--logger-file", and I guess the prompts will appear again. And in either case, simply turning off the user trust list in "gpg-agent.conf" is a safer workaround.
Good catch - you are correct.
The log-file isn't very helpful unfortunately and only shows several lines with `2023-03-12 14:04:34 gpgsm[33649] Fingerprint=xxxx` and the second line is `2023-03-12 14:04:37 gpgsm[33649] Interaktives vertrauenswürdig-Markieren ist in dieser Sitzung ausgeschaltet` - i guess that is after the click on 'abort' on the first prompt.
kmail surely tries to talk to the gpgsm server, but that's not what I meant, sorry for not having been clear here. My point is that you do not actively use S/MIME, given that you don't even remember ever receiving an S/MIME signed mail. Consequently you probably don't care about validating S/MIME signatures either, and–coming back to what I just said–disabling the user trust list with "no-user-trustlist" in "~/.gnupg/gpg-agent.conf" is not only safe, but won't loose you anything you'd miss.
After seeing that `logger-file` probably really just prevented gpgsm from starting, my memory about what i did that prevented signing/encrypting from working must have been wrong - and of course you are right that the config file is the better place for a workaround compared to a 'shim' ^^
By the way, I just remembered that the dialog in your OP showed German text: Presuming you're living in Germany, you did recently sign up for DHL services, perchance? Perhaps even received a delivery notice from DHL via mail? Just asking because DHL is the only company I'm aware of which actually signs some of its customer-facing mails with S/MIME.
I've received countless delivery-notices, never saw anything pointing to S/MIME there - but i haven't received any in the time frame in question, no.
So it really seems the logger-fd trail was deceiving - still the question remains what cause the change in behaviour.
Going through the logs, kmail, kgpg and related kde framework was updated two days prior to the occurrence of the prompt (22.12.2 -> 22.12.3), but the fact that downgrading gnupg prevents the prompts still points towards that...and downgrading kde-stuff isn't as easy and quick as downgrading gnupg unfortunately ^^
On the one hand, i'm tempted to just go with the workaround and disable the trustlist in the configs, but on the other hand i'd like to do my part and report the bug, should it really be one...
]]>But having read what you did exactly, namely replace "logger-fd" with "logger-file", I'm even less convinced that it's a bug. Let's see:
$ gpgsm --version
gpgsm (GnuPG) 2.2.41
libgcrypt 1.10.1-unknown
libksba 1.6.3
Copyright (C) 2022 g10 Code GmbH
License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html>
[…]
$ gpgsm --logger-file /tmp/foo --server
invalid option "--logger-file"
gpgsm doesn't have a --logger-file option here in fact; I think your change simply prevents the gpgsm server from starting ("chmod a-x gpgsm" would probably have the same effect), effectively disabling gpgsm and naturally stopping all prompts about S/MIME. According to "gpgsm --help" only "--log-file" exists; try to use that instead of "--logger-file", and I guess the prompts will appear again. And in either case, simply turning off the user trust list in "gpg-agent.conf" is a safer workaround.
kmail surely tries to talk to the gpgsm server, but that's not what I meant, sorry for not having been clear here. My point is that you do not actively use S/MIME, given that you don't even remember ever receiving an S/MIME signed mail. Consequently you probably don't care about validating S/MIME signatures either, and–coming back to what I just said–disabling the user trust list with "no-user-trustlist" in "~/.gnupg/gpg-agent.conf" is not only safe, but won't loose you anything you'd miss.
By the way, I just remembered that the dialog in your OP showed German text: Presuming you're living in Germany, you did recently sign up for DHL services, perchance? Perhaps even received a delivery notice from DHL via mail? Just asking because DHL is the only company I'm aware of which actually signs some of its customer-facing mails with S/MIME.
]]>Do check.
How would i do that most reliably? Simply searching for 'S/MIME' doesn't bring any mail up. In the KMail settings, S/MIME is disabled for sending.
I tend to agree with Seth, but of course i want to do my due diligence before filing the bug.
I presume you're not actually using S/MIME with GPG or you'd know about trustlist.txt, and if you never use S/MIME those files never get created. In particular trustlist.txt only gets created when you actually change the trust of a CA certificate, i.e. by answering "Yes"/"no" in the above prompt, or by manually creating the file. The trustlist format is documented in the GPG Agent configuration.
To suppress these prompts you have a few options. You can manually add the root certificates to trustlist.txt, either as trusted or untrusted certificate. This gives you control about what you trust, but only makes sense if you actually use S/MIME. If you'd just like to get rid of these prompts for good, I think you can set "no-allow-mark-trusted" in ~/.gnupg/gpg-agent.conf, and perhaps also "no-user-trustlist", too. The former does not allow gpgsm clients to change trust of CAs, i.e. disables the prompt, and the latter disables the user trustlist entirely, and thus effectively distrusts all root certificates (unless you changed the global trustlist; the default shipped with Arch is empty as far as I know).
Thanks for the Explanation!
I don't know… the downgrade and the logger FD fiddling was done without having a reliable way to reproduce the prompt, so it could all just have been coincidence. After all, Termy also assumed for a short time that a systemd update had fixed the issue.
Well, it was a reliable test in a way that a reboot brought the prompts up again after every false hope
While i agree that it is not 100% conclusive, it seems to point pretty strongly towards our finds with logger-fd imho.
And since the Termy is apparently not using gpgsm, it's probably easier to just disable the user trustlist and call it a day
Well, it seems to be used for mail signing and encryption if i recall my tests correctly - when i had it crippled by a typo in the shim-script, this actions wouldn't work in KMail.
Intercepting and replacing logger-fd with logger-file works fine as a workaround for now, but as we have at least one other person encountering this, a bug report to solve this for good is the better way to go imho.
But in any case, relax, I'm not saying that it's not a bug.
I'm just saying that this prompt is entirely expected and normal behaviour when you received the first S/MIME mail with a pristine gpgsm configuration, i.e. no user or system trustlist, so it might just be gpgsm doing it's job, and there might be no point in reporting this or waiting for it to be fixed. And since the Termy is apparently not using gpgsm, it's probably easier to just disable the user trustlist and call it a day
As for the keyserver option, it's not about GPG keyservers. Technically you can set a GPG keyserver there, but to the best of my knowledge no one does this, simply because no public keyserver hosts S/MIME certificates. You'd put your organization's LDAP server into this option, to automatically look up certificates of other users in your organization. And there's likely no "other keyserver" to try, unless your organization actually has multiple distinct LDAP directories.
If you do have a keyserver set in this option, I don't think you'd ask about these prompts. Either, your organization would ship gpgsm preconfigured, i.e. including an approved trustlist and with user trustlists disabled (so no prompts), or you'd have configured gpgsm yourself with an LDAP server you obtained from the organization's administrator, and at this point you'd likely know about the trustlist and what these prompts mean (so you'd like just have put the affected CA certificates into your trustlist instead of asking on the forums).
]]>I'm not sure the evidence is conclusive. For instance, you asked whether "gpg --list-keys --logger-fd 1" would trigger the prompt, and recommended to try another keyserver. I think neither of these are relevant.
How do various behavioral tests relate to the conclusiveness of the behavior being down to an update and a specific command switch?
Afawk the behavior is related to the last version of gnupg and the presence of the --logger-fd switch, even if I asked the OP whether he sometimes wears lingerie, those facts would not change.
I doubt gpg would ever prompt about CA trust, "--logger-fd" or not, simply because the "gpg" command only works with GPG keys, i.e. no CAs involved. A prompt about a CA means S/MIME, and S/MIME means "gpgsm" only, but this in turn doesn't use any keyservers at all because gpg keyservers only store gpg keys, but not S/MIME certificates.
We're operating on the assumption that there's a bug and the code does not act as expected (for uncertain reasons), because
1. only the last gnupg release is affected, a downgrade prevented the dialog.
2. the OP can toggle the dialog by filtering the --logger-fd switch
What part of the code is buggy, whether it's some common base or tool specific - I've no idea (hence looking for other ways to trigger or avoid it)
If you've an informed guess about this, feel free to share it.
There's also https://bbs.archlinux.org/viewtopic.php … 7#p2088587 - so if anything, both users have an s/mime mail around, the feature *was* broken in gpgsm, got fixed, but the fix relies on logger-fd (or the behavior is non-deterministic and randomly coincided w/ those conditions …)
Ftr:
gpgconf --list-options gpgsm | grep server:
--list-external-keys pattern
List certificates matching pattern using an external server. This utilizes the
dirmngr service.
--keyserver string
This is a deprecated option. It was used to add an LDAP server to use for X.509
certificate and CRL lookup. The alias --ldapserver existed from version 2.2.28 to
2.2.33 but is now entirely ignored.LDAP servers must be given in the configuration for dirmngr.
But gpgsm does indeed not read ca-certificates (at least I found no way to make it), so that explains why the trust is requested and not accepted from there.
]]>The irritating part is that the CA /is/ in /usr/share/ca-certificates/trust-source/mozilla.trust.p11-kit
I don't think that's relevant; as far as I know gpg does not use the system CA certificates as trust-store, unless you explicitly imported those certificates with gpgsm.
and only the most recent version of gpgsm triggers the query and only if used along --logger-fd
Alltogether that's a bit too specific a condition to be triggered by some random S/MIME mail.
I'm not sure the evidence is conclusive. For instance, you asked whether "gpg --list-keys --logger-fd 1" would trigger the prompt, and recommended to try another keyserver. I think neither of these are relevant.
I doubt gpg would ever prompt about CA trust, "--logger-fd" or not, simply because the "gpg" command only works with GPG keys, i.e. no CAs involved. A prompt about a CA means S/MIME, and S/MIME means "gpgsm" only, but this in turn doesn't use any keyservers at all because gpg keyservers only store gpg keys, but not S/MIME certificates.
Few people ever get S/MIME mails outside work (where S/MIME is quite likely preconfigured), even fewer people use S/MIME with gpgsm (I only ever saw gpgsm used for Git signing, and am surprised to learn that kmail uses it too), and those who do definitely know about trustlist.txt and wouldn't have to ask about this prompt. I have probably 15 years of personal mail, but only a few handful of S/MIME messages, and all from a single company which for some reason signs some (but not all) of their transactional mails with S/MIME.
I don't think it's all so unlikely that a few days ago the OP received their first S/MIME signed mail ever, which woke up gpgsm for the first time since it was installed.
]]>You can manually add the root certificates to trustlist.txt, either as trusted or untrusted certificate.
The irritating part is that the CA /is/ in /usr/share/ca-certificates/trust-source/mozilla.trust.p11-kit and only the most recent version of gpgsm triggers the query and only if used along --logger-fd
Alltogether that's a bit too specific a condition to be triggered by some random S/MIME mail.
lunaryorn wrote:Did you recently receive a S/MIME signed email and configured your mail client to verify S/MIME signatures, perchance?
Not that i know of at least.
Do check. Typically you never see S/MIME messages outside enterprise/corporate environments but sometimes they "leak" into personal mail. If your mail client uses gpgsm for S/MIME a single message could trigger these prompts.
Also, in case you're doing software development, have some Git repositories around, and did configure git itself or your git client to verify signatures, check your Git repositories: A S/MIME signed tag would also trigger such prompts under certain circumstances, and depending on the projects you're working on you might indeed see S/MIME signed commits. Note that depending on how your git configuration looks like even the AUR repositories cloned with your favourite AUR helper could trigger these messages; while I doubt that anyone uses S/MIME to sign AUR commits, you never know…
TBH i haven't found much about CAs at all when i search for the trustlist and gpg/CA stuff now. Only references to files that don't exist here ^^
The ~/.gnupg/trustdb.gpg was last modified on 27.2., so a good time before if that has anything to do with it?
I don't really notice any missing functionality if no trustlist.txt is found (neither in /etc/gnupg/ nor in ~/.gnupg/) - what is it even needed for? My understanding was that the Keyserver would be the only needed server for WoT? CAs are more a thing i associate with browsers/HTTPS i must admit.
I presume you're not actually using S/MIME with GPG or you'd know about trustlist.txt, and if you never use S/MIME those files never get created. In particular trustlist.txt only gets created when you actually change the trust of a CA certificate, i.e. by answering "Yes"/"no" in the above prompt, or by manually creating the file. The trustlist format is documented in the GPG Agent configuration.
To suppress these prompts you have a few options. You can manually add the root certificates to trustlist.txt, either as trusted or untrusted certificate. This gives you control about what you trust, but only makes sense if you actually use S/MIME. If you'd just like to get rid of these prompts for good, I think you can set "no-allow-mark-trusted" in ~/.gnupg/gpg-agent.conf, and perhaps also "no-user-trustlist", too. The former does not allow gpgsm clients to change trust of CAs, i.e. disables the prompt, and the latter disables the user trustlist entirely, and thus effectively distrusts all root certificates (unless you changed the global trustlist; the default shipped with Arch is empty as far as I know).
]]>