Yay: Hang at gpg import step

[skypher]

Affected Version

yay v9.2.1 - libalpm v11.0.3

Issue

==> PGP keys need importing:
 -> ABAF11C65A2970B130ABE3C479BE3E4300411886, required by: linux-lqx
==> Import? [Y/n] 
:: Importing keys with gpg......

... and then nothing happens, it's stuck.

If I send SIGINT with Ctrl-C:

gpg: signal Interrupt caught ... exiting

Is there a way to print yay's invocation of gpg?

Steps to reproduce

yay -S linux-lqx

Output

{
        "aururl": "https://aur.archlinux.org",
        "buildDir": "/home/sky/.cache/yay",
        "editor": "",
        "editorflags": "",
        "makepkgbin": "makepkg",
        "makepkgconf": "",
        "pacmanbin": "pacman",
        "pacmanconf": "/etc/pacman.conf",
        "tarbin": "bsdtar",
        "redownload": "no",
        "rebuild": "no",
        "answerclean": "",
        "answerdiff": "",
        "answeredit": "",
        "answerupgrade": "",
        "gitbin": "git",
        "gpgbin": "gpg",
        "gpgflags": "",
        "mflags": "",
        "sortby": "votes",
        "gitflags": "",
        "removemake": "ask",
        "requestsplitn": 150,
        "sortmode": 0,
        "completionrefreshtime": 7,
        "sudoloop": false,
        "timeupdate": false,
        "devel": false,
        "cleanAfter": false,
        "gitclone": true,
        "provides": true,
        "pgpfetch": true,
        "upgrademenu": true,
        "cleanmenu": true,
        "diffmenu": true,
        "editmenu": false,
        "combinedupgrade": false,
        "useask": false
}

[Jguer]

Yay passes these commands to GPG, therefore, normally I attribute this to system setup. Are you using a wm by chance?

Can you try:

gpg --search-keys ABAF11C65A2970B130ABE3C479BE3E4300411886

To see if you can find it on a keyserver

gpg --recv-keys ABAF11C65A2970B130ABE3C479BE3E4300411886

To try and import it just as yay does

Further reading: https://wiki.archlinux.org/index.php/GnuPG

[skypher]

It looks like a bug in GnuPG that is triggered with the default keyserver.

This Tails report looks very similar: https://redmine.tails.boum.org/code/issues/12689

In particular, using keys.openpgp.org as keyserver works for me now.

The default keyserver would cause gnupg to go into an endless loop of brk() calls with 100% cpu.

[soloturn]

@skypher where do you configure this keyserver to make it work?

[skypher]

IIRC I imported the keys manually through the Gpg command line, using the --keyserver option.

On Sat, Oct 5, 2019, at 8:50 PM, soloturn wrote:

@skypher https://github.com/skypher where do you configure this keyserver to make it work?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/Jguer/yay/issues/1022?email_source=notifications&email_token=AAAE5WCJ6L2RKHI5XMJGMBLQNFN65A5CNFSM4IV46J62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAOA2HY#issuecomment-538709279, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAE5WAJAZISOPUE7ER3E6TQNFN65ANCNFSM4IV46J6Q.

[soloturn]

ok, thanks, doing this as normal user worked now:

$ gpg --auto-key-locate nodefault,wkd --locate-keys [email protected]
$ yay -S tor-browser

mentioned:

• here: https://support.torproject.org/#how-to-verify-signature
• and here: https://aur.archlinux.org/packages/tor-browser

this did not:

$ gpg --keyserver hkp://keys.openpgp.org --recv-keys EF6E286DDA85EA2A4BA7DE684E2C6E8793298290
$ yay -S tor-browser

[Jguer]

If you find the gpg arguments suitable to fix the issue you can set yay to use them with yay -Y --gpgflags "<flags that work>" --save

[skypher]

I didn't know that! It would be great if a hint could be added to the GPG step in yay as to that effect. The default keyservers seem to be unreliable.

On Sun, Oct 6, 2019, at 10:26 AM, J Guerreiro wrote:

If you find the gpg arguments suitable to fix the issue you can set yay to use them with yay -Y --gpgflags "<flags that work>" --save

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/Jguer/yay/issues/1022?email_source=notifications&email_token=AAAE5WHCOEZYMKQCPYKPMJDQNINVLA5CNFSM4IV46J62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAOPJ7A#issuecomment-538768636, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAE5WACXL4LHXR7XJDME6LQNINVLANCNFSM4IV46J6Q.

[skypher]

Reopening to see if that sounds like a good idea or not.

[Jguer]

Hum, but normally the hang is really a hang, we won't get a return, also a timeout may do more harm than good, so how do we detect that it hanged and just not processing?

[skypher]

Oh, I was just suggesting to add a little informative hint before GnuPG gets called. Something like "Downloading Gpg key for Xxx. If this process doesn't finish, read http://url-to-hints-etc/"

On Fri, Oct 11, 2019, at 5:07 PM, J Guerreiro wrote:

Hum, but normally the hang is really a hang, we won't get a return, also a timeout may do more harm than good, so how do we detect that it hanged and just not processing?

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub https://github.com/Jguer/yay/issues/1022?email_source=notifications&email_token=AAAE5WCI6QGYWQQVSK6EJLLQOBF6PA5CNFSM4IV46J62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEA7Q5IY#issuecomment-541003427, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAE5WBQ55KMIPVQFABYVLTQOBF6PANCNFSM4IV46J6Q.

[Jguer]

I don't see why not, An entry to the FAQs and the extra message should be added then.
Accepting volunteers.