snapcraft validate (and possibly other operations requiring gpg passphrases) fail on remote/headless systems
Metadata
Current evaluation
GPG-backed assertion signing can fail on headless systems because no terminal is passed to gpg-agent; exporting GPG_TTY=$(tty) is reported to fix it
Suggested action: keep open
Reason: The report provides a reproducible SSH scenario, exact GPG failure, and a workaround; a later maintainer comment confirms the problem on non-desktop systems and identifies `export GPG_TTY=$(tty)` as resolving it. The current signing service invokes `snap sign` without managing `GPG_TTY`, and repository history contains no matching fix, so the valid signing failure remains open.
Evaluated by: mr-cal-bot
Impact:
58
Quick Win:
26
Complexity:
42
Confidence:
86
Actionability:
76
Issue body
A customer reported (and I was able to reproduce) getting an error when using snapcraft validate.
The key to reproducing (for me at least - still awaiting confirmation from customer) was doing this on a remote headless system. Sounds like gpg is trying to invoke something that isn't present on the system to get the passphrase and then fails. But it seems to happen only when gpg is invoked by snapcraft - so perhaps gpg is detecting something about its running environment or stdin/out redirection when running under snapcraft, and trying to ask for the password differently, and one thing to do would be forcing gpg to ask for the password a different way or something.
To reproduce:
1- ssh into a system that has snapcraft. I used a VM installed from an ubuntu server cloud image.
snapcraft validate allyoursnaparebelongtous1 allyoursnaparebelongtous2=2 --key-name an-example-three
Getting details for allyoursnaparebelongtous2
Signing validations assertion for allyoursnaparebelongtous2=2
Error signing validations assertion for allyoursnaparebelongtous2=2: error: cannot sign assertion: cannot sign using GPG: /usr/bin/gpg --personal-digest-preferences SHA512 --default-key 0x4A7677B256FB90F61B91C061C3E6F877EC048DD3 --detach-sign failed: exit status 2 ("gpg: signing failed: No such file or directory\ngpg: signing failed: No such file or directory\n")
The workaround is to first run the gpg command outside of snapcraft, so the key is unlocked:
echo "lalal" > a-file
/usr/bin/gpg --homedir=.snap/gnupg --personal-digest-preferences SHA512 --default-key 0xE185A8404D4CCDA151FA4AC51F5108DA9CD52BC6 --detach-sign a-file
then the snapcraft operation succeeds:
snapcraft validate allyoursnaparebelongtous1 allyoursnaparebelongtous2=2 --key-name an-example-two
Getting details for allyoursnaparebelongtous2
Signing validations assertion for allyoursnaparebelongtous2=2
snapcraft version
snapcraft, version 4.5.4
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.4 LTS
Release: 18.04
Codename: bionic
snap version
snap 2.49
snapd 2.49
series 16
ubuntu 18.04
kernel 4.15.0-136-generic
This is likely related to:
https://forum.snapcraft.io/t/snap-sign-unable-to-invoke-gpg-agent-pinentry/10938
and:
https://bugs.launchpad.net/snapcraft/+bug/1866257
from the latter, "there is a known issue with gpg-agent not freeing the lock"
Evaluation history
| Date | Model | Scores | Action | Summary |
|---|---|---|---|---|
| stealth/space-bunny-alpha |
Impact:
58
Quick Win:
26
Complexity:
42
Confidence:
86
Actionability:
76
|
keep open | GPG-backed assertion signing can fail on headless systems because no terminal is passed to gpg-agent; exporting GPG_TTY=$(tty) is reported to fix it | |
| stealth/space-bunny-alpha |
Impact:
48
Quick Win:
14
Complexity:
60
Confidence:
68
Actionability:
72
|
keep open | Headless/SSH `snapcraft validate` fails with 'gpg: signing failed: No such file or directory' when signing assertions; GPG_TTY export or pre-unlocking the key works around it. Still open, untriaged, spans snapcraft/snapd/gpg. | |
| stealth/space-bunny-alpha |
Impact:
42
Quick Win:
14
Complexity:
55
Confidence:
85
Actionability:
74
|
needs triage | Headless/SSH snapcraft validate fails during GPG signing; pre-unlocking the key or setting GPG_TTY works. The report remains open and untriaged, with ownership spanning Snapcraft, snapd, and GPG. | |
| qwen/qwen3.6-35b-a3b |
Impact:
40
Quick Win:
8
Complexity:
60
Confidence:
40
Actionability:
50
|
needs triage | snapcraft validate fails on headless/remote systems due to GPG passphrase handling issues; untriaged for 5.5 years with no maintainer response | |
| qwen/qwen3.8-27b |
Impact:
40
Quick Win:
18
Staleness:
92
Complexity:
55
Confidence:
60
Support Request:
10
|
close stale | snapcraft validate fails on headless/remote systems because gpg cannot prompt for the key passphrase; workaround is unlocking the key outside snapcraft first. Reported on snapcraft 4.5.4/Ubuntu 18.04; no maintainer response in 4+ years, no labels. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
95
Complexity:
60
Confidence:
85
Support Request:
10
|
close stale | snapcraft validate fails on headless systems due to GPG passphrase prompt failures. Unaddressed for over 5 years, targeting EOL software versions. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
95
Complexity:
65
Confidence:
85
Support Request:
10
|
close stale | GPG passphrase prompts fail during snapcraft validate on headless systems due to pinentry invocation issues. Reported on snapcraft 4.5.4 with reproduction steps and a workaround. No maintainer response in over 5 years. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
95
Complexity:
65
Confidence:
85
Support Request:
10
|
close stale | snapcraft validate fails on headless systems due to GPG passphrase handling. Reported against v4.5.4 with no maintainer response in over 4 years. |
Update history
| Date | Change |
|---|---|
| created |
Related work
-
Related To:
snapcraft (launchpad)#1866257
(confidence 96%)
The report explicitly links it to a known gpg-agent lock and passphrase-signing issue.
Related issues
No related issues found above the similarity threshold.