Constant prompts about trusting Root CA after gnupg update

Termy · 2023-03-05 16:23:43

Hi there,

since yesterday, i'm constantly getting prompts by `pinentry-gtk-2` like these: prompt

When confirming with 'yes', another step pops up for confirming the fingerprint, then the entry is added to a newly generated file in ~/.gnupg.

There was an update of gnupg (2.2.40-1 -> 2.2.41-1) two days ago, so that probably is the cause?

Unfortunately, i can't find any mention about those prompts anywhere and am kind of at a loss on what to do. Although it seems like the cert authorities (globalsign, if that is accepted it continues with a different one...) seem to be valid, i'm hesitant to accept them without understanding the 'why now?'.

So...hopefully anybody has any idea on what the cause and reason of this is and maybe on how to get rid of the prompt if it's not really advisable to accept all the CAs?

Thanks in advance!

seth · 2023-03-05 17:39:28

pinentry* are some dialogs implementing the ASSUAN protocol:

echo GETPIN | pinentry-gtk-2

so don't try to obfuscate the source and context.
What's asking is (likely) gpg-agent or ssh-agent or pacman - or something entirely different.
You might also have lost the keyserver or changed from WOT to TOFU?

=> When does this actually pop up?

Termy · 2023-03-05 18:08:08

seth wrote:

pinentry* are some dialogs implementing the ASSUAN protocol:
echo GETPIN | pinentry-gtk-2
so don't try to obfuscate the source and context.

If you mean the blurring, that was [<some number i can't associate with anything>]@<hostname> in the window title, i maybe should have mentioned that, true.

seth wrote:

What's asking is (likely) gpg-agent or ssh-agent or pacman - or something entirely different.

Should probably be gpg-agent, no ssh-agent running and doesn't seem to have connection to me calling pacman. The creation of a file in ~/.gnupg also points to that i guess.

seth wrote:

You might also have lost the keyserver or changed from WOT to TOFU?

No, i didn't (manually) change anything, no .pacnew files merged or present for gnupg, keyserver is hkps://keys.mailvelope.com and that domain is reachable at least.

seth wrote:

=> When does this actually pop up?

Unfortunately, i didn't notice any pattern yet, seems to be random.

But thanks to your questions i looked at journalctl for gpg-agent (instead of pinentry) and found messages complaining about a missing /etc/gnupg/trustlist.txt - as that file is created in ~/.gnupg when accepting the prompts, that sounds like a probable cause.

The file wasn't there in the past either (at least i don't find it in my timeshift backups), so something must have changed with the gnupg-update?

Skimming over the first few results for that file makes it sound like that should have been there in the past, too?!

seth · 2023-03-05 21:00:10

Skimming over the first few results for that file makes it sound like that should have been there in the past, too?!

/usr/share/doc/gnupg/examples/trustlist.txt

Unfortunately, i didn't notice any pattern yet, seems to be random.

What if you check the process tree for the dialog, maybe you can track its invocation?

"Constant prompts" and no context, just "please sign off this cert" are kinda weird.
Conky script? Mail program?

Ftr:

doesn't seem to have connection to me calling pacman

It would also rather be some wrapper/daemon - the point was more to stress that this could be a specific gpg context.

Termy · 2023-03-06 08:47:37

seth wrote:

/usr/share/doc/gnupg/examples/trustlist.txt

Thank you - i found that, too, but not really that much more information about that anywhere. But i've checked older journals, too and gpg-agent complained about that file missing before the prompt stated to pop up, so i guess it was a false conclusion that the change was there...

seth wrote:

What if you check the process tree for the dialog, maybe you can track its invocation?

systemd─┬─(sd-pam)
        └─gpg-agent─┬─pinentry-gtk-2───3*[{pinentry-gtk-2}]
                    └─{gpg-agent}

Not really that enlightening (at least to me). I couldn't find any logs from gpg-agent, either - it seems you have to manually define a log directory in the gpg-agent.conf (which i haven't even created).

seth wrote:

"Constant prompts" and no context, just "please sign off this cert" are kinda weird.
Conky script? Mail program?

That's what i find confusing, too. No conky scripts, kmail is running - but there haven't been any updates to the KDE-components that coincide with the beginning of the prompts. Issuing a manual fetching of new mails doesn't trigger the prompt, so that's not it at least.
And i don't recall any manual changes i made to anything that seems remotely related in that timeframe.

Mail (and i guess archlinux-keyring) is also the only thing i'm (at least consciously) using gpg for.

seth wrote:

It would also rather be some wrapper/daemon - the point was more to stress that this could be a specific gpg context.

The only thing in that regard that i'm aware of would be reflector - but that should run only once per day.

I'm tempted to downgrade gnupg to see if the update of that one really caused it. Or could a change on the side of the keyserver trigger the adding of keys to the trustlist? But i doubt i'm the only one using mailvelop, so i'd still be confused why i'm seemingly the only one affected ^^

Edit: I found `watchgnupg` and am currently letting it it sit here to hopefully catch something useful on the next occurrence of the prompt.

Last edited by Termy (2023-03-06 08:52:39)

seth · 2023-03-06 09:51:46

alternatively invoke "gpg-agent --no-allow-mark-trusted" and see what fails in return…
Also, as a sanity check

grep -C8 GlobalSign /usr/share/ca-certificates/trust-source/mozilla.trust.p11-kit | grep -C8 R3

Termy · 2023-03-06 10:08:30

seth wrote:

alternatively invoke "gpg-agent --no-allow-mark-trusted" and see what fails in return…

➜ ~ gpg-agent --no-allow-mark-trusted                                                                                                                                                                                                                        [130]
gpg-agent[40593]: gpg-agent running and available

watchgnupg didn't record anything when the prompt appeared unfortunately...

But now that i look at the journalctl output it seems that the prompt comes up every hour. Just re-checked, but no cronjobs and systemd-timers for user or system that match that though

seth wrote:

Also, as a sanity check

grep -C8 GlobalSign /usr/share/ca-certificates/trust-source/mozilla.trust.p11-kit | grep -C8 R3

seems fine to me

Edit: so i've downgraded gnupg to 2.2.40-1 again and it's been almost three hours with no prompt. So it definitely is cause by a change in 2.2.41 - the changelog has nothing that jumps out to me though...

Last edited by Termy (2023-03-06 13:53:54)

seth · 2023-03-06 14:08:59

There's no change to the build,
https://github.com/archlinux/svntogit-p … 5b1df6b6f2

You could file an upstream bug, but I guess it would be helpful to know what triggers the request that results in the bogus certificate approval request.
And "comes up every hour" is a bit too un-random.
Is it "once per hour" or "on the hour"?

Termy · 2023-03-06 14:22:26

seth wrote:

There's no change to the build,
https://github.com/archlinux/svntogit-p … 5b1df6b6f2
You could file an upstream bug, but I guess it would be helpful to know what triggers the request that results in the bogus certificate approval request.
And "comes up every hour" is a bit too un-random.
Is it "once per hour" or "on the hour"?

Yeah without that i guess it'd be pretty useless for the devs. I'm just confused that no one else encounters that so i'm still also trying to find out what is unusual or strange with my setup. But other than the changed keyserver, i can't think of anything tbh...and mailvelope isn't that unusual i'd think?

It seems to be 'once per hour', first time one hour after boot. Do you by chance know of any other timer-based things outside of systemd timers and cron?

seth · 2023-03-06 14:40:39

atd, but that's less likely
Anything can run stuff periodically (eg. conky would, prominently)

My gut feeling is that this is some script calling gpg, so if you'd move /usr/bin/gpg[2] to /usr/bin/gpg[2].bin and replace them w/ scripts like

#!/bin/bash
date >> /tmp/gpg.log
echo "$0 $* :: $( < /proc/$PPID/cmdline )" >> /tmp/gpg.log
exec /usr/bin/gpg.bin "$@"

you might be able to log the invocation

Termy · 2023-03-06 14:45:10

That sounds like a nice idea!

I've now created a gpg-agent.conf with a log-file option, so maybe that will yield some more info - if not, i'll try your suggestion

lod · 2023-03-07 12:55:04

Have you had any results yet? I get the same prompts since yesterday.

Last edited by lod (2023-03-07 12:55:28)

Termy · 2023-03-07 12:57:06

lod wrote:

Have you had any results yet? I get the same prompts since yesterday.

Only partly, just noticed i had a permission issue with the log file 30min ago.
14:23 should be the next time the prompt comes up, so hopefully i'll get some insight then ^^

Last edited by Termy (2023-03-07 12:57:26)

seth · 2023-03-07 13:00:44

You could diff "ps aux" for possible sources.

Termy · 2023-03-07 13:39:08

Well the test on 14:23 wasn't enlightening because i wanted to test if the prompts ceased if a trustlist.txt was present and forgot about that

We'll have to wait till 15:23 then.

The 'progress' so far:

- The log-file defined in gpg-agent.conf only provides the same output that is already present in the journal, nothing new there.

- When trying seth's suggestion with gpg, nothing happend - at first i thought gpg isn't even called. So i switched it over to pinentry-qt (had the gpg-agent.conf set to that), nothing changed, still no logs
When manually calling pinentry-qt, the log entries were created, so the script itself seems to be fine (or so i thought - i was still running sudo...).

- Then, i modified the pinentry script (that by default is just checking if X11 is running and starts pinentry-gtk-2 if so, otherwise pinentry-curses) to include your two lines and removed the pinentry-qt line in gpg-agent.conf.

- That broke pinentry, so neither the prompts came up nor email signing or crypting worked. That was when i noticed that the logfile was owned by root and 700...so at least we can now be sure that whatever calls pinentry does so as user

So now i've changed that, removed the trustlist again and hopefully we will se something userful in an hour ^^

Edit: even after renaming the created trustlist.txt, i don't get any more prompts right now - we'll see if that stays that way after reboot

Last edited by Termy (2023-03-07 14:52:52)

Termy · 2023-03-08 10:51:36

So after a reboot, it occurs again (...sigh...)

The script just records

/usr/bin/pinentry --display :0 :: /usr/bin/gpg-agent--supervised

though, so nothing really new there

seth wrote:

You could diff "ps aux" for possible sources.

You mean right before and during the prompt? Might be worth a try, i'll set a timer to hopefully catch the right time!

seth · 2023-03-08 12:42:25

What I meant is that the two of you compare which processes are running.
If it's mostly standard and <tool that almost nobody uses but shows up for both of you>, the latter is more likely to be the cause.

Termy · 2023-03-08 13:16:57

That might be worth a try. In that regard it might also be interesting what setup @Iod uses.
My only (conscious) user of gpg is kmail/kgpg, the only 'obvious' change to the configs i did was using `keyserver hkps://keys.mailvelope.com`.

It's of course not very neat and clear what would be 'unusual'...anyhow, i've cleared out all the firefox and steam(flatpak) processes to make it at least a little bit less cluttered: https://bin.disroot.org/?7675fb7a96e0aa … KdQxSVibTN
Maybe you can share yours, too @Iod?

Also, i still did a diff of `ps -e -o command` before and during the prompt, the only additional processes with the prompt are:

gpgsm --logger-fd 105 --server
/usr/bin/pinentry-gtk-2 --display :0

Nothing enlightening for me

Just for the sake of it i've now quit kgpg to see if that triggers it, even if that hasn't had an update in the timeframe in question.

seth · 2023-03-08 13:28:49

the only additional processes with the prompt are

Good idea, actually.
https://man.archlinux.org/man/core/gnupg/gpgsm.1.en

=> try to shadow and log ghe gpgsm invocation.

Edit: https://bin.disroot.org/?7675fb7a96e0aa … KdQxSVibTN yells p11-kit-remote at me …

Last edited by seth (2023-03-08 13:32:37)

Termy · 2023-03-08 13:36:07

seth wrote:

=> try to shadow and log ghe gpgsm invocation.

Could you give me some more hint/direction? I can't really find anything useful about logging the invocation of a program with 'shadow'?

Auditctl seems to be another way to go in that direction?

seth · 2023-03-08 13:43:15

This principle approach: https://bbs.archlinux.org/viewtopic.php … 5#p2088385

audits might get you the PPID but you run the risk for short terms processes to not be able to resolve that.
But if we can intercept the invocation, we can log the shit out of it

Termy · 2023-03-08 15:07:08

seth wrote:

This principle approach: https://bbs.archlinux.org/viewtopic.php … 5#p2088385

too obvious i guess ^^

seth wrote:

audits might get you the PPID but you run the risk for short terms processes to not be able to resolve that.
But if we can intercept the invocation, we can log the shit out of it

I'm not too sure about that, as gpgsm seems to be invoked by systemd:

/usr/bin/gpgsm --logger-fd 83 --server :: /usr/lib/systemd/systemd--user

any idea on how to proceed from there?

seth · 2023-03-08 15:31:53

It's going to be kmail/akonadi/p11-kit-remote

man gpgsm wrote:

gpgsm is a tool similar to gpg to provide digital encryption and signing services on X.509
certificates and the CMS protocol. It is mainly used as a backend for S/MIME mail pro‐
cessing. gpgsm includes a full featured certificate management and complies with all
rules defined for the German Sphinx project

and KDE increasingly activates stuff via system units.

Stop kmail/akonadi, see what processes remain and whether the system asks you again.

Termy · 2023-03-08 17:55:52

Yeah it seems Kmail triggers it.
At least it wasn't triggered an hour ago when i had kmail shutdown.

So then the question remains why an update of gnupg would cause that change in behaviour and where to report it - and maybe even more important: why doesn't it affect more people?

seth · 2023-03-08 20:13:23

"--logger-fd 105" means that kmail is redirecting the gpgsm log, that might reveal the cause for the unknown trust.
If not, you could intercept gpgsm but instead of handing the original parameters, use "--logger-file /tmp/gpgsm.log --server"

Does the script btw. work transparently? (Because gpgsm probably wants to read from stdin)

Arch Linux

#1 2023-03-05 16:23:43

Constant prompts about trusting Root CA after gnupg update

#2 2023-03-05 17:39:28

Re: Constant prompts about trusting Root CA after gnupg update

#3 2023-03-05 18:08:08

Re: Constant prompts about trusting Root CA after gnupg update

#4 2023-03-05 21:00:10

Re: Constant prompts about trusting Root CA after gnupg update

#5 2023-03-06 08:47:37

Re: Constant prompts about trusting Root CA after gnupg update

#6 2023-03-06 09:51:46

Re: Constant prompts about trusting Root CA after gnupg update

#7 2023-03-06 10:08:30

Re: Constant prompts about trusting Root CA after gnupg update

#8 2023-03-06 14:08:59

Re: Constant prompts about trusting Root CA after gnupg update

#9 2023-03-06 14:22:26

Re: Constant prompts about trusting Root CA after gnupg update

#10 2023-03-06 14:40:39

Re: Constant prompts about trusting Root CA after gnupg update

#11 2023-03-06 14:45:10

Re: Constant prompts about trusting Root CA after gnupg update

#12 2023-03-07 12:55:04

Re: Constant prompts about trusting Root CA after gnupg update

#13 2023-03-07 12:57:06

Re: Constant prompts about trusting Root CA after gnupg update

#14 2023-03-07 13:00:44

Re: Constant prompts about trusting Root CA after gnupg update

#15 2023-03-07 13:39:08

Re: Constant prompts about trusting Root CA after gnupg update

#16 2023-03-08 10:51:36

Re: Constant prompts about trusting Root CA after gnupg update

#17 2023-03-08 12:42:25

Re: Constant prompts about trusting Root CA after gnupg update

#18 2023-03-08 13:16:57

Re: Constant prompts about trusting Root CA after gnupg update

#19 2023-03-08 13:28:49

Re: Constant prompts about trusting Root CA after gnupg update

#20 2023-03-08 13:36:07

Re: Constant prompts about trusting Root CA after gnupg update

#21 2023-03-08 13:43:15

Re: Constant prompts about trusting Root CA after gnupg update

#22 2023-03-08 15:07:08

Re: Constant prompts about trusting Root CA after gnupg update

#23 2023-03-08 15:31:53

Re: Constant prompts about trusting Root CA after gnupg update

#24 2023-03-08 17:55:52

Re: Constant prompts about trusting Root CA after gnupg update

#25 2023-03-08 20:13:23

Re: Constant prompts about trusting Root CA after gnupg update

Board footer