Constant prompts about trusting Root CA after gnupg update

Termy · 2023-03-09 08:47:54

I'm kind of confused now...

i replaced the invocation in the gpgsm-shim-script with:

exec /usr/bin/gpgsm.bin --logger-file /home/termy/.gnupg/gpgsm.log --server "$@"

Now, no prompt shows up when it should (it still gets recorded by the echo before, so it's still happening) and nothing is written into gpgsm.log.

Contrary to the last time i 'butchered' something, mail en- and decrypting still works though....

seth · 2023-03-09 09:02:39

Seems to be the logger-fd then??
Though "$@" would be extra here.
What if you just use "exec /usr/bin/gpgsm.bin "$@"" and what if you don't shadow it at all (possibly restarting kmail did the trick…)?

Termy · 2023-03-09 09:19:17

seth wrote:

Seems to be the logger-fd then??
Though "$@" would be extra here.

--logger-fd just changes the file descriptor from what i can find - not sure where the output lands then though tbh.
Wasn't sure about the passing of the original arguments, i no deleted that, lets see what happens.

seth wrote:

What if you just use "exec /usr/bin/gpgsm.bin "$@"" and what if you don't shadow it at all (possibly restarting kmail did the trick…)?

That's what i had yesterday, worked 'normal' with that and still brought up the prompts exactly one hour after kmail was started. But i can test it again next hour after we see the result of the above, just to be sure. ^^

Termy · 2023-03-09 10:35:46

seth wrote:

What if you just use "exec /usr/bin/gpgsm.bin "$@""

As expected, with that the prompt pops up again.

seth · 2023-03-09 11:25:11

A file descriptor is a more abstract concept of a file and doesn't require an actual file, kmail probably seeks to redirect the log into some fifo.

There may be a bug in kmail (the fd being invalid) but using --logger-fd causing a failure to find the ca trust is a rather freakish bug.
Might be related to https://dev.gnupg.org/T5849 - do you configure log-file in your gpg.conf ?

Termy · 2023-03-09 11:30:16

seth wrote:

A file descriptor is a more abstract concept of a file and doesn't require an actual file, kmail probably seeks to redirect the log into some fifo.
There may be a bug in kmail (the fd being invalid) but using --logger-fd causing a failure to find the ca trust is a rather freakish bug.

I see. I didn't find any bugreports over at KDE that point in that direction, but of course that's no evidence.

seth wrote:

Might be related to https://dev.gnupg.org/T5849 - do you configure log-file in your gpg.conf ?

I have now, didn't have it when the prompts started. As this report is a year old, i doubt it would only now materialize, would it?

seth · 2023-03-09 21:03:31

The specific bug rather not, but external reliance on the log destination.
Does

gpg --list-keys --logger-fd 1

trigger the trust request as well?

Termy · 2023-03-10 09:54:38

Yesterday on a quick test it didn't, no.

Wanted to test more today, but now the prompts don't seem to appear anymore

When i compare the update yesterday night with the update that introduced the issue it seems that systemd/systemd-libs/systemd-sysvcompat 253.1-2 was the issue and 253.1-3 seems to have solved it.
I hope it's not just a fluke but really 'solved' ^^

Thanks for your efforts and help in any case!

seth · 2023-03-10 13:48:54

The systemd update exclusively dealt w/ https://bbs.archlinux.org/viewtopic.php … 3#p2088483
Do you have a TPM2?
But even iff, that would be a rather weird consequence…

Termy · 2023-03-11 10:30:26

No TPM, but unfortunately, it was a fluke anyway, today the prompt appears again
It would be interesting to know why it didn't appear yesterday, but i have not the slightest idea on the how...

In the log of the intercepts of gpgsm calls there are other entries that i haven't seen the last days from yesterday early morning (so probably right as i shut down the pc after the updates) and today:
After the updates (including systemd):

/usr/bin/gpgsm --version :: /usr/lib/systemd/systemd--system--deserialize73

And today:

/usr/bin/gpgsm --version :: /usr/lib/systemd/systemd--switched-root--system--deserialize32

I found this explanation which doesn't really explain the first one (for me at least), but the second one makes it sound that after the systemd update, gpgsm is called earlier now?
But those probably have nothing to do with my problem i guess...

seth · 2023-03-11 13:22:44

it was a fluke anyway

Suspected as much.

there are other entries that i haven't seen the last days from yesterday early morning

Likely from the TPM2 patches, I guess the dates of the invocation do not co-incide w/ the dialog popping up?

The relevance of the logger-fd switch probably remains and is a strong indication that there's a weird bug in a probably fringe feature of gpg that gets triggered by kmail.
Report a bug upstream to get to the bottom of that and that might also explain the rather rare occasion.

And test another keyserver, just for fun.

Termy · 2023-03-11 13:53:48

seth wrote:

I guess the dates of the invocation do not co-incide w/ the dialog popping up?

Correct, they don't. Only occured once for each to date, too.

seth wrote:

The relevance of the logger-fd switch probably remains and is a strong indication that there's a weird bug in a probably fringe feature of gpg that gets triggered by kmail.
Report a bug upstream to get to the bottom of that and that might also explain the rather rare occasion.

Probably the next best way. Replacing logger-fd with logger-file in the shim at least is a "workaround" that doesn't seem to impede functionality as far as i can see ^^

Do you reckon it's worthwhile to also file a bug for kmail? I'd wait with that until a response in the gpg report would indicate as much.

seth wrote:

And test another keyserver, just for fun.

Worth a try at least - will do that before the bug report

seth · 2023-03-11 14:02:11

I'd wait with that until a response in the gpg report would indicate as much.

This. There's no point in reporting a bug against kmail if it simply exposes a bug in gpg.
Only if it turns out that the bug in gpg was triggered by buggy behavior in kmail.

3beb6e7c46a615a · 2023-03-11 15:22:56

I believe this message comes from the S/MIME subsystem of GnuPG.

Did you recently receive a S/MIME signed email and configured your mail client to verify S/MIME signatures, perchance?

If you did the certificate perhaps comes from a CA you didn't see before? Gpgsm keeps a separate trust store and will ask about every new CA it comes across.

Last edited by 3beb6e7c46a615a (2023-03-11 15:25:54)

Termy · 2023-03-11 18:18:51

lunaryorn wrote:

I believe this message comes from the S/MIME subsystem of GnuPG.
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.
Pretty sure that i didn't mess around with any encrypted mail or settings around +/- 1 day of the first occurance.

lunaryorn wrote:

If you did the certificate perhaps comes from a CA you didn't see before? Gpgsm keeps a separate trust store and will ask about every new CA it comes across.

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.

Like i said, i can't really find too much information at all about GPG and CAs/the Trustlist (other than a mailing list discussion that the Trustlist should be better documented ^^) - maybe you have some ressources?

3beb6e7c46a615a · 2023-03-11 19:58:52

Termy wrote:

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…

Termy wrote:

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).

seth · 2023-03-11 20:53:48

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.

3beb6e7c46a615a · 2023-03-11 22:28:04

seth wrote:

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.

seth · 2023-03-11 23:26:03

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:

man gpgsm wrote:

--list-external-keys pattern
List certificates matching pattern using an external server. This utilizes the
dirmngr service.

man gpgsm wrote:

--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.

3beb6e7c46a615a · 2023-03-12 08:08:20

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.

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).

Last edited by 3beb6e7c46a615a (2023-03-12 08:09:09)

Termy · 2023-03-12 10:47:45

So, changing the keyserver didn't change anything in that regard, unfortunately - or rather as expected i guess ^^

lunaryorn wrote:

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.

lunaryorn wrote:

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!

lunaryorn wrote:

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.

lunaryorn wrote:

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.

3beb6e7c46a615a · 2023-03-12 11:36:55

I am not familiar with KMail, so unfortunately I can't help you with finding S/MIME signed mails.

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.

Last edited by 3beb6e7c46a615a (2023-03-12 11:37:57)

Termy · 2023-03-12 13:20:13

lunaryorn wrote:

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.

lunaryorn wrote:

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.

lunaryorn wrote:

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' ^^

lunaryorn wrote:

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...

3beb6e7c46a615a · 2023-03-12 14:28:45

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…

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.

Last edited by 3beb6e7c46a615a (2023-03-12 14:31:19)

Termy · 2023-03-12 14:59:19

lunaryorn wrote:

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 ^^

lunaryorn wrote:

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.

lunaryorn wrote:

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.

Arch Linux

#26 2023-03-09 08:47:54

Re: Constant prompts about trusting Root CA after gnupg update

#27 2023-03-09 09:02:39

Re: Constant prompts about trusting Root CA after gnupg update

#28 2023-03-09 09:19:17

Re: Constant prompts about trusting Root CA after gnupg update

#29 2023-03-09 10:35:46

Re: Constant prompts about trusting Root CA after gnupg update

#30 2023-03-09 11:25:11

Re: Constant prompts about trusting Root CA after gnupg update

#31 2023-03-09 11:30:16

Re: Constant prompts about trusting Root CA after gnupg update

#32 2023-03-09 21:03:31

Re: Constant prompts about trusting Root CA after gnupg update

#33 2023-03-10 09:54:38

Re: Constant prompts about trusting Root CA after gnupg update

#34 2023-03-10 13:48:54

Re: Constant prompts about trusting Root CA after gnupg update

#35 2023-03-11 10:30:26

Re: Constant prompts about trusting Root CA after gnupg update

#36 2023-03-11 13:22:44

Re: Constant prompts about trusting Root CA after gnupg update

#37 2023-03-11 13:53:48

Re: Constant prompts about trusting Root CA after gnupg update

#38 2023-03-11 14:02:11

Re: Constant prompts about trusting Root CA after gnupg update

#39 2023-03-11 15:22:56

Re: Constant prompts about trusting Root CA after gnupg update

#40 2023-03-11 18:18:51

Re: Constant prompts about trusting Root CA after gnupg update

#41 2023-03-11 19:58:52

Re: Constant prompts about trusting Root CA after gnupg update

#42 2023-03-11 20:53:48

Re: Constant prompts about trusting Root CA after gnupg update

#43 2023-03-11 22:28:04

Re: Constant prompts about trusting Root CA after gnupg update

#44 2023-03-11 23:26:03

Re: Constant prompts about trusting Root CA after gnupg update

#45 2023-03-12 08:08:20

Re: Constant prompts about trusting Root CA after gnupg update

#46 2023-03-12 10:47:45

Re: Constant prompts about trusting Root CA after gnupg update

#47 2023-03-12 11:36:55

Re: Constant prompts about trusting Root CA after gnupg update

#48 2023-03-12 13:20:13

Re: Constant prompts about trusting Root CA after gnupg update

#49 2023-03-12 14:28:45

Re: Constant prompts about trusting Root CA after gnupg update

#50 2023-03-12 14:59:19

Re: Constant prompts about trusting Root CA after gnupg update

Board footer