chrmarti
commented
1 year ago Does gpg --list-secret-keys show any keys when run locally? What is in you local ~/.gnupg/gpg.conf and ~/.gnupg/gpg-agent.conf?
Closed dallinb closed 9 months ago
chrmarti
commented
1 year ago Does gpg --list-secret-keys show any keys when run locally? What is in you local ~/.gnupg/gpg.conf and ~/.gnupg/gpg-agent.conf?
dallinb
commented
1 year ago Hi @chrmarti thank you for the fast response,
Yes, all runs fine locally. Both gpg --list-secret-keys and echo "test" | gpg --clearsign work as expected when run locally.
This is the contents of my local ~/.gnupg directory:
ls -l ~/.gnupg
total 32
srwx------@ 1 ben.dalling staff 0 29 May 08:12 S.gpg-agent
srwx------@ 1 ben.dalling staff 0 29 May 08:12 S.gpg-agent.browser
srwx------@ 1 ben.dalling staff 0 29 May 08:12 S.gpg-agent.extra
srwx------@ 1 ben.dalling staff 0 29 May 08:12 S.gpg-agent.ssh
srwx------@ 1 ben.dalling staff 0 29 May 08:12 S.keyboxd
-rw-r-----@ 1 ben.dalling staff 12 19 May 17:42 common.conf
-rw-r--r--@ 1 ben.dalling staff 48 19 May 17:45 gpg-agent.conf
drwx------@ 4 ben.dalling staff 128 19 May 17:42 private-keys-v1.d
drwxr-x---@ 5 ben.dalling staff 160 29 May 08:12 public-keys.d
-rw-------@ 1 ben.dalling staff 32 19 May 19:48 pubring.kbx
-rw-------@ 1 ben.dalling staff 1280 19 May 17:51 trustdb.gpgcat ~/.gnupg/gpg-agent.conf
pinentry-program /opt/homebrew/bin/pinentry-maccat ~/.gnupg/common.conf
use-keyboxdAlso this is the version of gpg locally:
gpg --version
gpg (GnuPG) 2.4.1
libgcrypt 1.10.2
Copyright (C) 2023 g10 Code GmbH
License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Home: /Users/ben.dalling/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2On the Dev Container, it is:
gpg (GnuPG) 2.2.27
libgcrypt 1.8.8
Copyright (C) 2021 Free Software Foundation, Inc.
License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Home: /home/vscode/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2The contents of ~/.gnupg on the Dev Container, immediately after a rebuild is:
1711349 4 drwx------ 3 vscode vscode 4096 May 30 08:46 /home/vscode/.gnupg/
1716097 0 srwxr-xr-x 1 vscode vscode 0 May 30 08:40 /home/vscode/.gnupg/S.gpg-agent
1711352 4 -rw-r--r-- 1 vscode vscode 32 May 30 06:53 /home/vscode/.gnupg/pubring.kbx
1711353 4 -rw-r--r-- 1 vscode vscode 1280 May 30 06:53 /home/vscode/.gnupg/trustdb.gpg
1711403 4 drwx------ 2 vscode vscode 4096 May 30 07:02 /home/vscode/.gnupg/private-keys-v1.dDoes it work with a sample dev container? (F1 > Dev Containers: Try a Dev Container Sample... > Node)
dallinb
commented
1 year ago Hi @chrmarti I'll try that out, but I'm afraid that won't be until Thursday. Will let you know the outcome as soon as possible then.
dallinb
commented
1 year ago @chrmarti,
I followed your instructions to create a "Dev Container Sample" (specifically a Node one) and still have the problem. I've also removed the version of GnuPG I had installed on the host node (MacOS) and installed the specific version as suggested by GitHub (see https://www.gnupg.org/download/). Now my host node version of GPG is:
gpg --version
gpg (GnuPG) 2.4.2
libgcrypt 1.10.1
Copyright (C) 2023 g10 Code GmbH
License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Home: /Users/ben.dalling/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2Trying this out on a completely brand new project, but these are the results in the newly created container:
$ ls -l ~/.gnupg/
total 8
-rw-r--r-- 1 node node 32 Jun 8 13:00 pubring.kbx
srwxr-xr-x 1 node node 0 Jun 8 13:03 S.gpg-agent
-rw-r--r-- 1 node node 1280 Jun 8 13:00 trustdb.gpg
$ echo "test" | gpg --clearsign
gpg: no default secret key: No secret key
gpg: [stdin]: clear-sign failed: No secret key
$ gpg --list-secret-keys
<RETURNS NOTING>On my native laptop, the echo "test" | gpg --clearsign and gpg --list-secret-keys work as expected, just not in the container.
Also, this is an M2 MacBook pro. In case that makes any difference.
chrmarti
commented
1 year ago What do you get when running gpgconf --list-dir agent-extra-socket locally? And what do you get when running gpgconf --list-dir agent-socket in the container? (Note the slightly different option value in the two.) Wondering if these are different from what the extension sees as shown in the log.
dallinb
commented
1 year ago Running locally:
$ gpgconf --list-dir agent-extra-socket
/Users/ben.dalling/.gnupg/S.gpg-agent.extraRunning in the Dev Container
node ➜ /workspaces/vscode-remote-try-node (main) $ gpgconf --list-dir agent-socket
/home/node/.gnupg/S.gpg-agentFor the sake of simplicity, I'm creating the Dev Container from the method you suggested in https://github.com/microsoft/vscode-remote-release/issues/8549#issuecomment-1576387302. Therefore I have also attached the startup log as it will be different from the one I originally posted devcontainer-log.txt
gremo
commented
1 year ago Same problem here. I'm running Windows and GPG works fine:
Marco@PC-Marco MINGW64 ~/.ssh
$ gpg --version
gpg (GnuPG) 2.2.29-unknown
libgcrypt 1.9.3-unknown
Copyright (C) 2021 Free Software Foundation, Inc.
License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Home: /c/Users/Marco/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2Commands echo "test" | gpg --clearsign and gpg --list-secret-keys work as expected but fail in the container.
root@a10232c8e7a2:/var/www/html# echo "test" | gpg --clearsign
gpg: no default secret key: No secret key
gpg: [stdin]: clear-sign failed: No secret keyThis prevents me to use git in the container at all, as I've configured it with with gpgsign = true (that works, on Windows).
chrmarti
commented
1 year ago What is the output of gpg --list-secret-keys --verbose in the container? Is anything added to the container log when you run this?
dallinb
commented
1 year ago Is there anything more I can do to gather more information to help resolve this? It's not a massive blocker, just inconvenient that I have to commit code externally from VSCode to have signed commits.
gremo
commented
1 year ago I'm on holiday, I'll provide all the information next week, thanks
mdhthahmd
commented
1 year ago hello, @dallinb did you find a solution/workaround, i also having the exact same problem
dallinb
commented
1 year ago @mdhthahmd , there is no solution so far, but it would probably be useful if you confirmed your host platform.
mdhthahmd
commented
1 year ago @mdhthahmd , there is no solution so far, but it would probably be useful if you confirmed your host platform.
Same as mentioned, m2 mac
MRDGH2821
commented
1 year ago I found a hacky work around for Windows (should work wherever GPG & VSCode can be installed)
devcontainer.json to add following commands:
"initializeCommand": {
"gpg.exportPublicKeys": "gpg -a --export --output .devcontainer/gpg/public-keys.asc --yes",
"gpg.exportPrivateKeys": "gpg -a --pinentry-mode loopback --passphrase-file=.devcontainer/gpg/gpg-password.txt --export-secret-keys --output .devcontainer/gpg/private-keys.asc --yes",
"gpg.exportTrustDB": "gpg -a --export-ownertrust --output .devcontainer/gpg/owner-trust-db.txt > .devcontainer/gpg/owner-trust-db.txt"
},
"postCreateCommand": {
"gpg.importPublicKeys": "sudo gpg --import .devcontainer/gpg/public-keys.asc",
"gpg.importPrivateKeys": "sudo gpg -v --pinentry-mode loopback --passphrase-file=.devcontainer/gpg/gpg-password.txt --import .devcontainer/gpg/private-keys.asc",
"gpg.importTrustDB": "sudo gpg --import-ownertrust .devcontainer/gpg/owner-trust-db.txt"
},gpg in .devcontainer foldergpg-password.txt which has your GPG passphrase in plain textThis way I was able to get commit signing working (although for pin entry, host's gpg pin entry was invoked instead of dev container's gpg pin entry)
This extension can help if the dev container is linux based Name: GPG Indicator VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=wdhongtw.gpg-indicator
I'm still finding ways to make a command pipeline to detect GitHub codespaces where the above commands should not execute.
I'm also looking to export specific key and tried using gpg.conf but didn't work as expected.
mdhthahmd
commented
1 year ago i can confirm that the issue is not reproducible in a debian host (works as expected on debian), so it seems something is going wrong on mac @chrmarti, when i run gpg -k (within dev container) on mac: has no output, but on debian i do get the output for the key on host
chrmarti
commented
1 year ago @mdhthahmd Could you try the following:
gpg-agent is running locally with: ps ax | grep gpg-agent.gpg --list-secret-keys.ls -l ~/.gnupg/S.* (is there more than one?)rm ~/.gnupg/S.*F1 > Developer: Reload Window.ls -l ~/.gnupg/S.* (there should be a single one now)gpg --list-secret-keys.F1 > Dev Containers: Show Container Logmdhthahmd
commented
1 year ago [X] Confirm the gpg-agent is running locally with: ps ax | grep gpg-agent.
1774 ?? Ss 0:03.84 gpg-agent --homedir /Users/<user>/.gnupg --use-standard-socket --daemon 27273 s000 S+ 0:00.00 grep gpg-agent
[x]Confirm you see your keys locally: gpg --list-secret-keys.
sec ed25519 2023-07-23 [SC] [expires: 2023-10-21] 4XXXXXXXXXXXXXXXXXXXX uid [ultimate] Midhath Ahmed <email> ssb cv25519 2023-07-23 [E] [expires: 2023-10-21]
[X] Check what socket paths you have in the container: ls -l ~/.gnupg/S.* (is there more than one?)
srwxr-xr-x 1 node node 0 Jul 30 03:12 /home/node/.gnupg/S.gpg-agent
@chrmarti theres just one
Wodann
commented
1 year ago I followed this tutorial but am experiencing the same problem as reported in this issue. I have tried the advice listed above (and in other closed issues), but to no avail.
Local OS: Windows 11 (10.0.22621) Dev container: https://github.com/NomicFoundation/hardhat/blob/rethnet/main/.devcontainer/devcontainer.json Using: Docker Desktop + WSL2 (Ubuntu)
In Windows (Powershell):
gpg --list-secret-key worksOn devcontainer:
gpg --list-secret-key results in:
'/home/vscode/.gnupg/pubring.kbx' created
ls -la ~/.gnupg/ shows:
total 20 drwx------ 2 vscode vscode 4096 Aug 7 20:59 . drwxr-xr-x 1 vscode vscode 4096 Aug 7 20:48 .. -rw------- 1 vscode vscode 32 Aug 7 20:48 pubring.kbx srwxr-xr-x 1 vscode vscode 0 Aug 7 20:48 S.gpg-agent -rw-r--r-- 1 vscode vscode 1520 Aug 7 20:35 trustdb.gpg
My suspicion is that I might be missing something between the Windows <-> WSL (Ubuntu) gpg setup, but I'm not sure what it could be based on tutorial, as I followed all steps..
SvenAelterman
commented
1 year ago Similar situation here with Windows 11.
However, on the host machine, running gci ~/.gnupg/* only results in a single file present: pubring.kbx.
I suspect this means I didn't set up GPG correctly on Windows, though I am successfully signing commits on Windows (and echo "test" | gpg --clearsign works too.
I didn't set up GPG using Git bash; I never use it.
[EDIT]
agent-socket and agent-extra-socket are in C:\Users\<username>\AppData\Local\gnupg\S.gpg-agent
SvenAelterman
commented
1 year ago Is there anything more I can do to gather more information to help resolve this? It's not a massive blocker, just inconvenient that I have to commit code externally from VSCode to have signed commits.
Just adding the thought that if you clone the repo in the devcontainer volume, which provides better performance (versus mounting it), you must have access to keys inside the devcontainer.
jamisonbryant
commented
1 year ago I also have this issue on a 2021 Apple M1 MacBook Pro, GPG-signed commits were working one day and not the next.
Local OS: macOS Monterey (12.5.1) Using: Docker Desktop + VS Code
I resolved my issues by disabling GPG signing in git: git config --global commit.gpgsign false because signing is not a requirement for my organization, but it is a nice-to-have.
Connect to the dev container with VS Code. [DONE]
Confirm the gpg-agent is running locally with: ps ax | grep gpg-agent. [DONE - AGENT IS RUNNING]
```
❯ ps ax | grep gpg-agent
590 ?? S 0:00.01 /bin/bash /usr/local/MacGPG2/libexec/shutdown-gpg-agent
4970 ?? Ss 2:59.99 gpg-agent --homedir /Users/mrunicorn/.gnupg --use-standard-socket --daemon
68118 s001 S+ 0:00.00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn --exclude-dir=.idea --exclude-dir=.tox gpg-agent
```
Confirm you see your keys locally: gpg --list-secret-keys. [DONE - KEYS PRESENT]
```
❯ gpg --list-secret-keys
/Users/mrunicorn/.gnupg/pubring.kbx
---------------------------------------
sec rsa4096 2023-03-23 [SC] [expires: 2027-03-23]
E12E8F0D7B60F58B03C3FEEA85AB3B351D6CC61D
uid [ultimate] Mr Unicorn (Mr's GPG Key)
ssb rsa4096 2023-03-23 [E] [expires: 2027-03-23]
```
Check what socket paths you have in the container: ls -l ~/.gnupg/S.* (is there more than one?) [DONE - NOT MORE THAN ONE]
```
➜ ui-vite-vue3 git:(feature/municorn-fun-stuff) ✗ ls -l ~/.gnupg/S.*
srwxr-xr-x 1 root root 0 Aug 16 02:11 /root/.gnupg/S.gpg-agent
```
Remove the socket paths in the container: rm ~/.gnupg/S.* [DONE]
Reload the VS Code window: F1 > Developer: Reload Window. [DONE]
Again check what socket paths you have in the container: ls -l ~/.gnupg/S.* (there should be a single one now) [DONE - ONLY ONE PRESENT]
Check if you see any keys in the container: gpg --list-secret-keys. [DONE - NO KEYS]
If there are no keys, check if there are any errors in the container log: F1 > Dev Containers: Show Container Log [DONE - NO ERRORS]
antony-frolov
commented
1 year ago Hi! I am experiencing the same issue. Actually I've got two images one of which works, and the other has this issue.
The one that works has Ubuntu 20.04, gpg 2.2.19, libgcrypt 1.8.5 and the one that doesn't has Ubuntu 22.04, gpg2.2.27, libgcrypt 1.9.4
Ready to provide some additional info if needed
chrmarti
commented
1 year ago @antony-frolov Which version do you have installed locally and which OS are you on? Does it work with the following devcontainer.json? This is using Ubuntu 22.04, gpg2.2.27, libgcrypt 1.9.4 as you reported as not working:
{
"image": "mcr.microsoft.com/devcontainers/base:jammy"
}(This works for me on macOS Ventura with gpg 2.4.1 and libgcrypt 1.10.2.)
antony-frolov
commented
1 year ago @antony-frolov Which version do you have installed locally and which OS are you on? Does it work with the following devcontainer.json? This is using Ubuntu 22.04, gpg2.2.27, libgcrypt 1.9.4 as you reported as not working:
{ "image": "mcr.microsoft.com/devcontainers/base:jammy" }(This works for me on macOS Ventura with gpg 2.4.1 and libgcrypt 1.10.2.)
I'll try! I've also looked into it and found out that both images work on our VMs with Ubuntu 18.04. So I only have issues on our older VM with Ubuntu 16.04 (which also probably has some outdated packages installed).
Locally I've got MacOS, but as I've said we're developing and running Docker on Ubuntu VMs. The extension version is v0.304.0.
antony-frolov
commented
1 year ago @antony-frolov Which version do you have installed locally and which OS are you on? Does it work with the following devcontainer.json? This is using Ubuntu 22.04, gpg2.2.27, libgcrypt 1.9.4 as you reported as not working:
{ "image": "mcr.microsoft.com/devcontainers/base:jammy" }(This works for me on macOS Ventura with gpg 2.4.1 and libgcrypt 1.10.2.)
Got the same error with the devcontainer.json you provided. Changed jammy to focal
{
"image": "mcr.microsoft.com/devcontainers/base:focal"
}and it worked fine. Both focal and jammy images work fine on VMs with Ubuntu 18.04 (and probably some newer system packages).
Here's a paste of the logs I've got with jammy image on Ubuntu 16.04 VM https://pastebin.com/eN211h6G. Not sure it's a problem with gpg at this point cause I tried to upgrade it to 2.4.1 and the issue is still there.
chrmarti
commented
1 year ago pastebin.com seems to have removed the log, could you post it here?
What versions of GPG and libgcrypt are others using seeing this? (Run gpg --version to find out.)
antony-frolov
commented
1 year ago pastebin.com seems to have removed the log, could you post it here?
What versions of GPG and libgcrypt are others using seeing this? (Run
gpg --versionto find out.)
The VM has: Ubuntu 16.04, gpg (GnuPG) 2.2.4, libgcrypt 1.10.2
The devcontainer.json used
{
"image": "mcr.microsoft.com/devcontainers/base:jammy",
"name": "${localEnv:USER}_jammy",
"runArgs": [
"--name", "${localEnv:USER}_jammy"
]
}
The log shows assertion failures in Node similar to https://github.com/nodejs/node/issues/43064. Are others seeing the same?
antony-frolov
commented
1 year ago The log shows assertion failures in Node similar to nodejs/node#43064. Are others seeing the same?
Huge thanks, that helped a lot!
Wodann
commented
1 year ago The log shows assertion failures in Node similar to nodejs/node#43064. Are others seeing the same?
@chrmarti AFAICT there is no nodejs assertion failure in my case: https://github.com/microsoft/vscode-remote-release/issues/8549#issuecomment-1668576634
I'm not sure what I should be looking for in the log as a cause for the failure, but one thing I noticed is that it seems to detect and copy GPG-related settings from Windows to WSL but then doesn't do anything in the next step:
[12160 ms] Start: Run in container: # Test for /home/vscode/.gnupg/trustdb.gpg and gpg [12162 ms] /home/vscode/.gnupg/trustdb.gpg exists
chrmarti
commented
1 year ago @Wodann It copies the public keys and trust db to the container as these are not available through the gpg-agent. It will not overwrite existing files. Make sure pubring.kbx, pubring.gpg and trustdb.gpg do not already exist in the container image.
Wodann
commented
1 year ago @Wodann It copies the public keys and trust db to the container as these are not available through the gpg-agent. It will not overwrite existing files. Make sure
pubring.kbx,pubring.gpgandtrustdb.gpgdo not already exist in the container image.
@chrmarti I checked and:
My WSL ~/.gnupg/ folder only contains a gpg-agent.conf file with the following content:
pinentry-program /mnt/c/Program Files (x86)/Gpg4win/bin/pinentry.exeMy container image is a standard: mcr.microsoft.com/devcontainers/base:bullseye, which I assume doesn't have any of those in it. Yet, after creation of the container, this is the content in ~/.gnupg/:
$ ls -la ~/.gnupg/
total 16
drwx------ 2 vscode vscode 4096 Aug 25 19:28 .
drwxr-xr-x 1 vscode vscode 4096 Aug 25 19:28 ..
srwxr-xr-x 1 vscode vscode 0 Aug 25 19:28 S.gpg-agent
-rw-r--r-- 1 vscode vscode 1520 Aug 25 19:28 trustdb.gpg@Wodann The log you posted shows that it connects to the gpg-agent on Windows and also copies that file from Windows (~\AppData\Roaming\gnupg). (For workspace folders on Windows it will prefer the GPG install on Windows, for workspace folder in WSL it will prefer the one in WSL.)
Wodann
commented
1 year ago Just to make sure I understand correctly:
Since I'm running a devcontainer with a virtual volume, it tries to copy the GPG keys from WSL and WSL has unique GPG keys compared to Windows.
If my understanding is correct, then how can I ensure that my Windows keys are instead copied?
If instead you meant that the devcontainer is correctly copying the files from Windows, how can it be that in Windows my GPG keys are listed on the CLI but in the devcontainer they are not?
mamiu
commented
1 year ago @chrmarti Were you already able to find the issue? If not, I'm happy to give you all information you need to solve the issue.
I have the same problem as explained by all the others above.
Everything works fine locally, but not in the dev container.
ssh-add -l:
2048 SHA256:v+7UsdAuBvRks48DOAGNVb+sSg/iR4yWN/iTZnnqa1c manu@miu-mbp.local (RSA)gpg --list-secret-keys:
/Users/manu/.gnupg/pubring.kbx
------------------------------
sec ed25519 2021-08-26 [SC]
B9626714B84DA885341E17A3E29AC8CADE1A807B
uid [ultimate] Paul Miu <miu.manu@gmx.de>
ssb cv25519 2021-08-26 [E]echo "test" | gpg --clearsign:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
test
-----BEGIN PGP SIGNATURE-----
iHUEARYKAB0WIQS5YmcUuE2ohTQeF6PimsjK3hqAewUCZPlxjQAKCRDimsjK3hqA
e5G9AP9MjHT7aFqyXwaFC11+S2YiW1Zw0hfnTGDL5zcoKUeHaAEA3fojVtoMpQ4p
D/R4gy4UJh4ug/gLn7fmtWQvW4yfVQA=
=u5eC
-----END PGP SIGNATURE-----ls -la ~/.gnupg/:
total 4.0K
drwx------ 13 manu staff 416 Sep 7 02:45 .
drwxr-x---+ 50 manu staff 1.6K Sep 5 16:07 ..
drwxr-xr-x 3 manu staff 96 Jul 6 05:18 openpgp-revocs.d
drwxr-x--- 4 manu staff 128 Jul 6 05:18 private-keys-v1.d
srwx------ 1 manu staff 0 Sep 7 01:44 S.gpg-agent
srwx------ 1 manu staff 0 Sep 7 01:44 S.gpg-agent.browser
srwx------ 1 manu staff 0 Sep 7 01:44 S.gpg-agent.extra
srwx------ 1 manu staff 0 Sep 7 01:44 S.gpg-agent.ssh
srwx------ 1 manu staff 0 Sep 7 01:44 S.scdaemon
-rw-r--r-- 1 manu staff 48 Jul 24 17:35 gpg-agent.conf
lrwxr-xr-x 1 manu staff 45 Jul 6 05:18 pubring.kbx
lrwxr-xr-x 1 manu staff 46 Jul 6 05:18 pubring.kbx~
lrwxr-xr-x 1 manu staff 45 Jul 6 05:18 trustdb.gpgcat ~/.gnupg/gpg-agent.conf:
pinentry-program /opt/homebrew/bin/pinentry-macps -ax | grep gpg-agent | grep -v grep:
24426 ?? 0:01.70 gpg-agent --homedir /Users/manu/.gnupg --use-standard-socket --daemonpython:latest)devcontainer.json contains an "initializeCommand":
"initializeCommand": ["ssh-add"],pubring.kbx, pubring.gpg and trustdb.gpg do not already exist in the container. ls -la ~/.gnupg/:
ls: cannot access '/root/.gnupg/': No such file or directoryapt list gpg gnupg2:
Listing... Done
gnupg2/stable,now 2.2.40-1.1 all [installed]
gpg/stable,now 2.2.40-1.1 arm64 [installed]ssh-add -l:
2048 SHA256:v+7UsdAuBvRks48DOAGNVb+sSg/iR4yWN/iTZnnqa1c manu@miu-mbp.local (RSA)echo "test" | gpg2 --clearsign:
gpg: directory '/root/.gnupg' created
gpg: keybox '/root/.gnupg/pubring.kbx' created
gpg: no default secret key: No secret key
gpg: [stdin]: clear-sign failed: No secret keygpg --list-secret-keys
gpg: /root/.gnupg/trustdb.gpg: trustdb createdexport GPG_TTY=$(tty) doesn't change anythingAlso tested it with the "Dev Containers: Try a Dev Container Sample..." command and the Node image (vscode-remote-try-node), but I still get exactly the same output from above.
If you need more information, please let me know.
mamiu
commented
1 year ago @chrmarti I think I found the issue.
When I launch VS Code from the terminal everything works fine (e.g. code path/to/project). Only when I launch VS Code from the Dock, Launchpad, Spotlight, Alfred, etc. I'll see the issue described above.
This reminded me of our discussion almost two and a half years ago.
Especially this part:
As already mentioned by @weinand:
On macOS all apps started from Finder, Dock, or Launchpad do not read the users ".profile", ".bash_profile" etc. files. So they don't inherit the same environment as apps launched from a terminal.
When I launch VSCode from a terminal I don't get any error message and it works as expected.
Maybe we could introduce a user setting to configure what type of shell should be used to read the environment.
In the end you left it for @bpasero @deepak1556 @joaomoreno to move or extract an issue.
It'd be great if we could at least warn users (with a popup, notification, or something) or add it somewhere in the docs so that we don't create GitHub issues every time this comes up, and also to save you and us time investigating the unexpected behavior.
Wodann
commented
10 months ago @chrmarti Circling back to validate my earlier question:
https://github.com/microsoft/vscode-remote-release/issues/8549#issuecomment-1695149105
chrmarti
commented
10 months ago @Wodann Your log indicates that the gpg socket is forwarded to the gpg-agent on Windows:
[2441 ms] gpg-agent: Socket in container (/root/.gnupg/S.gpg-agent) forwarded to local host (C:\Users\Remco\AppData\Local\gnupg\S.gpg-agent.extra).@mamiu VS Code should use your default shell to read the environment variables from an interactive login shell session (e.g., running something like bash -lic printenv). To investigate further, you could:
F1 > Preferences: Configure Runtime Arguments."log-level": "trace" to the opened argv.json.F1 > Output: Focus on Output View.Log (Main) channel.Cmd + F works).Afterwards remove the "log-level": "trace" entry to stop filling the logs with trace output.
Wodann
commented
10 months ago @Wodann Your log indicates that the gpg socket is forwarded to the gpg-agent on Windows:
[2441 ms] gpg-agent: Socket in container (/root/.gnupg/S.gpg-agent) forwarded to local host (C:\Users\Remco\AppData\Local\gnupg\S.gpg-agent.extra).
@chrmarti one thing I've noticed is that when I run gpg --version on the Windows terminal, it tells me the following:
Home: C:\Users\wodan\AppData\Roaming\gnupg
That's making me wonder why the devcontainer is targetting the AppData\local instead of AppData\Roaming. Maybe this is the source of the problem?
mamiu
commented
10 months ago Thanks for your response @chrmarti
I followed the steps you described and found this error in the logs:
2023-10-28 05:45:03.486 [trace] getUnixShellEnvironment#stderr warning: Could not set up terminal.
warning: TERM environment variable not set.
warning: Using fallback terminal type 'xterm-256color'.
open terminal failed: not a terminal
```
2023-10-28 05:45:03.322 [trace] [File Watcher (node.js)] Request to start watching: /Users/manu/Library/Application Support/Code/User (excludes:
The error says that the TERM environment variable isn't set, but it is set as you can see here in my fish config file.
My current setup works perfectly fine with everything for many years now, apart from VS Code.
I use the fish shell on macOS. When I run which fish I get /opt/homebrew/bin/fish.
And this is the terminal config in my settings.json:
{
...
"terminal.integrated.profiles.osx": {
"fish": {
"path": "/opt/homebrew/bin/fish"
}
},
"terminal.integrated.defaultProfile.osx": "fish",
...
}I also always get this popup when I open VS Code from the Dock:
What am I missing here?
chrmarti
commented
10 months ago @Wodann The home folder and the socket can be indifferent folders. What's a bit curious is that you mention C:\Users\wodan while the logs show C:\Users\Remco. Are there two user accounts involved?
@mamiu I don't see any recent changes in VS Code's env probing. What do you get when running env -i PATH="$PATH" fish -lic printenv ; echo "exit code: $?" in a terminal?
mamiu
commented
10 months ago @chrmarti I have that issue for years already (at least 3 years).
This is the output:
bash-5.2$ env -i PATH="$PATH" fish -lic printenv ; echo "exit code: $?"
warning: Could not set up terminal.
warning: TERM environment variable not set.
warning: Using fallback terminal type 'xterm-256color'.
PWD=/Users/manu
SYSTEMD_PAGER=/opt/homebrew/bin/bat -l log -p
HOME=/Users/manu
XDG_CONFIG_HOME=/Users/manu/.config
LC_ALL=en_US.UTF-8
USER=manu
LC_CTYPE=en_US.UTF-8
SHLVL=1
MANPAGER=sh -c 'col -bx | /opt/homebrew/bin/bat -l man --style=plain,numbers'
LANG=en_US.UTF-8
TERM=xterm-256color
XDG_DATA_HOME=/Users/manu/.local/share
GPG_TTY=/dev/ttys006
PAGER=/opt/homebrew/bin/bat -p
MANROFFOPT=-c
PATH=/Users/manu/.config/fish/scripts:/opt/homebrew/bin:/usr/local/gnubin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/Users/manu/bin:/Users/manu/.config/fish/scripts
EDITOR=vim
XDG_CACHE_HOME=/Users/manu/.cache
exit code: 0Interestingly I see the same warnings in here as in VS Code:
warning: Could not set up terminal.
warning: TERM environment variable not set.
warning: Using fallback terminal type 'xterm-256color'.If I just run fish -lic printenv it works perfectly well. (Printing all env variables from the fish shell)
And if I add TERM="$TERM" to your command, it also works without a warning.
Here's the same command with the TERM variable and the output:
bash-5.2$ env -i PATH="$PATH" TERM="$TERM" fish -lic printenv ; echo "exit code: $?"
PWD=/Users/manu
SYSTEMD_PAGER=/opt/homebrew/bin/bat -l log -p
HOME=/Users/manu
XDG_CONFIG_HOME=/Users/manu/.config
USER=manu
LC_CTYPE=en_US.UTF-8
SHLVL=1
MANPAGER=sh -c 'col -bx | /opt/homebrew/bin/bat -l man --style=plain,numbers'
LANG=en_US.UTF-8
LC_ALL=en_US.UTF-8
TERM=xterm-256color
XDG_DATA_HOME=/Users/manu/.local/share
GPG_TTY=/dev/ttys001
PAGER=/opt/homebrew/bin/bat -p
MANROFFOPT=-c
PATH=/Users/manu/.config/fish/scripts:/opt/homebrew/bin:/usr/local/gnubin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/Users/manu/bin:/Users/manu/.config/fish/scripts
EDITOR=vim
XDG_CACHE_HOME=/Users/manu/.cache
exit code: 0Does this help you troubleshoot?
chrmarti
commented
10 months ago The log also shows open terminal failed: not a terminal. Does that show when you run env -i PATH="$PATH" TERM="$TERM" sh -c 'echo | fish -lic printenv | cat' ; echo "exit code: $?"?
paul-gilber
commented
10 months ago have you tried with bionic image? mcr.microsoft.com/devcontainers/base:bionic this resolved the issue for me
mamiu
commented
10 months ago You're right @chrmarti.
But I don't get the open terminal failed: not a terminal error when executing the command you gave me, independent of having TERM="$TERM" in the command or not.
However, if I run your command from a shell that doesn't initialize the environment (i.e. doesn't source the /etc/profile file) such as env -i bash or env -i sh I get the following error:
bash-3.2$ env -i PATH="$PATH" TERM="$TERM" sh -c 'echo | fish -lic printenv | cat' ; echo "exit code: $?"
sh: fish: command not found
exit code: 0If you want to see the exit code of fish -lic printenv:
sh-3.2$ env -i PATH="$PATH" TERM="$TERM" sh -c 'fish -lic printenv ; echo "exit code: $?"'
sh: fish: command not found
exit code: 127This error occurs because the dirname of the fish shell (/opt/homebrew/bin/fish) isn't in the PATH variable.
If I run this command with the -l (login) and -i (interactive) shell flags, then it works fine.
sh-3.2$ env -i PATH="$PATH" TERM="$TERM" sh -lic 'echo | fish -lic printenv | cat' ; echo "exit code: $?"
PWD=/Users/manu
SYSTEMD_PAGER=/opt/homebrew/bin/bat -l log -p
HOME=/Users/manu
XDG_CONFIG_HOME=/Users/manu/.config
USER=manu
LC_CTYPE=en_US.UTF-8
SHLVL=2
MANPAGER=sh -c 'col -bx | /opt/homebrew/bin/bat -l man --style=plain,numbers'
LANG=en_US.UTF-8
LC_ALL=en_US.UTF-8
TERM=xterm-256color
XDG_DATA_HOME=/Users/manu/.local/share
GPG_TTY=not a tty
PAGER=/opt/homebrew/bin/bat -p
MANROFFOPT=-c
PATH=/Users/manu/.config/fish/scripts:/opt/homebrew/bin:/usr/local/gnubin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/usr/gnu/bin:.
EDITOR=vim
XDG_CACHE_HOME=/Users/manu/.cache
exit code: 0I don't know if this is relevant to troubleshoot this problem.
Thanks a lot for looking into this @chrmarti. If you need any other information let me know
beplay
commented
10 months ago Facing the same issue as the OP:
Everything works locally (i.e., gpg --list-secret-keys lists the key, echo "test" | gpg --clearsign signs the message).
What is interesting in the remote session is that when running echo "test" | gpg --clearsign -vvv I get the following output:
gpg: using character set 'utf-8'
gpg: connection to agent is in restricted mode
gpg: no default secret key: No secret key
gpg: [stdin]: clear-sign failed: No secret keyBut when listing the secret keys using: gpg --list-secret-keys -vvv it seems to at least pick up the key as a trusted key:
gpg: using character set 'utf-8'
gpg: using pgp trust model
gpg: key F64BFF0C6C5382AD: accepted as trusted keyThere is no issue under Windows 10 and WSL when signing commits in the Dev Container, however, on MacOS it stopped to work a few weeks ago (I can't remember when exactly, unfortunately).
Are there any steps required under MacOS similar to following these steps for WSL to enable the pinentry popup or console prompt to the Dev Container?
DaazKu
commented
9 months ago For some of you this is probably the problem: https://github.com/microsoft/vscode-remote-release/issues/9217
You do not have a ~/.gnupg/pubring.kbx locally because use-keyboxd is set in ~/.gnupg/common.conf
chrmarti
commented
9 months ago @mamiu Your log in https://github.com/microsoft/vscode-remote-release/issues/8549#issuecomment-1783766850 shows the full path to fish, so it not being on the PATH initially is indeed not a problem.
Since it is working when starting VS Code from the terminal, could you compare printenv output from the terminal with the output when first clearing the environment with env as you already did?
VSCode Version: 1.78.2
Local OS Version: MacOS Ventura
Remote OS Version: Debian 11 (bullseye)
Remote Extension/Connection Type: Docker
Logs:
Dev Container start logs:
Steps to Reproduce:
Similar to #3221 except that I don't attempt to mount
~/.gnupg. The files~/.gnupg/pubring.kbxand~/.gnupg/trustdb.gpgare copied over OK.GPG_TTYis set:Running the following command:
Gives the following output:
Returns nothing.
As done in #3221, I attempted killing the GPG agent (with
gpgconf --kill gpg-agent) when the socket is removed, I reattempt the commands, but with identical results.Does this issue occur when you try this locally?: No Does this issue occur when you try this locally and all extensions are disabled?: No