GPG keys are not imported in container if GPG is configured with `use-keyboxd`. Default for GPG >= 2.4.1 fresh install.

[DaazKu]

Description

The current implementation assume that ~/.gnupg/pubring.kbx exists and can be copied inside the container so that we have access to keys inside it. This is not the case if use-keyboxd is used.

=>> Since version 2.4.1 of gnupg, fresh installations are now using use-keyboxd by default. See: https://github.com/gpg/gnupg/blob/42ee84197695aca44f5f909a0b1eb59298497da0/README#L131C17-L131C22 <<=

Versions

• VSCode Version: 1.84.2
• Local OS Version: Darwin arm64 21.6.0
• Remote OS Version: debian:buster-20191118
• Remote Extension/Connection Type: K8s

Steps to Reproduce:

1. Have ~/.gnupg/common.conf with use-keyboxd. Supported since 2.3.0 and the default since 2.4.1 of gnupg
2. Attach VS to container
3. See that ~/.gnupg/pubring.kbx is not copied into the container because it does not exists.
4. Do gpg -k in the container for the first time and get the following message: gpg: keybox '~/.gnupg/pubring.kbx' created
   • Note that you don't have any keys loaded in the container

As per https://www.gnupg.org/documentation/manuals/gnupg/GPG-Configuration-Options.html, use-keyboxd changes the way GPG works:

Note that if the option use-keyboxd is enabled in common.conf, no keyrings are used at all and keys are all maintained by the keyboxd process in its own database.

We end up with no file ~/.gnupg/pubring.kbx.

You can use the below temporary fix to migrate off using use-keyboxd

TEMPORARY FIX

You can revert back to using pubring.kbx

1. Export keys
2. Disable use-keyboxd
3. Import keys

Basically you do the inverse of: https://github.com/gpg/gnupg/blob/42ee84197695aca44f5f909a0b1eb59298497da0/README#L134C2-L145

[3f6a]

Hi, what is the status of this issue?

I see https://github.com/microsoft/vscode-remote-release/issues/8549 is closed, but I'm running into this issue so it seems it's not fixed yet? Or was there a workaround?

For context, my issue is that on a fresh dev container, I cannot sign git commits with my GPG key. My local computer is a macOS. Signing works fine on my local machine. I followed Github docs (https://docs.github.com/en/authentication/managing-commit-signature-verification) to create the GPG key. And then tried following the steps here: https://code.visualstudio.com/remote/advancedcontainers/sharing-git-credentials#_sharing-gpg-keys. But I still cannot sign:

error: gpg failed to sign the data:
gpg: skipped "***": No secret key
[GNUPG:] INV_SGNR *******
[GNUPG:] FAILURE sign ****
gpg: signing failed: No secret key

Thanks!

[AvinZarlez]

I also just ran into this issue.

I was able to do the workaround by exporting keys, removing use-keyboxd from config, and then reimporting.

[jjshinobi]

I've stumbled over this issue as well. Also, it could be awesome to do the gpg keys sharing in such a way so it works not only in VSCode dev containers but also in Intellij or via DevPod.

[ArcticLampyrid]

Any progress?

[nipil]

I stumbled upon gpg-disable-keyboxd on my 2.4.5 gpg (from Gpg4win). It solved the issue for me on vscode 1.90.2 with devcontainer extension 0.369.0 on Windows 11. My devcontainers were all running gpg 2.2, and none could use the key from my 2.4 gpg on windows host.

So i started by loading my keys in GPG (Kleopatra) on my windows host, then i ran the gpg-disable-keyboxd command a PowerShell, and it automatically converted from "keybox" into "pubring" :

PS C:\Users\me> gpg -k
[keyboxd]
---------
pub   rsa4096 2013-09-21 [SC] [expire : 2025-06-08]
....

PS C:\Users\me> gpg-disable-keyboxd
--- Migrating your OpenPGP Certificates (Public Keys) from Keyboxd to the old format ---
--- If this fails or produces empty results your certificates are in the state where you migrated to keybox in the first place ---
Shutting down Kleopatra...
Opération réussie : le processus "kleopatra.exe" de PID 16368 a été arrêté.
Shutting down background processes...
Using "C:\Users\me\AppData\Roaming\gnupg" as GnuPG Homedir.
Exporting OpenPGP certificates to C:\Users\me\AppData\Roaming\gnupg\pubring-migration-bkp-openpgp.gpg"
Exporting X509 certificates to C:\Users\me\AppData\Roaming\gnupg\pubring-migration-bkp-x509.pem"
Disabling keyboxd by deleting common.conf
Importing OpenPGP certificates... this might take a while
gpg: le trousseau local « C:\\Users\\me\\AppData\\Roaming\\gnupg\\pubring.kbx » a été créé
gpg: clef xxxxxxxxxxx : clef publique .............
gpg:       Quantité totale traitée : 1
gpg:                     importées : 1
Importing X509 certificates... this might take a while
gpgsm: quantité totale traitée : 0
gpgsm: erreur d'importation du certificat : Fin de fichier
Checking database..
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: profondeur : 0  valables :   1  signées :   0
     confiance : 0 i., 0 n.d., 0 j., 0 m., 0 t., 1 u.
gpg: la prochaine vérification de la base de confiance aura lieu le 2025-06-08
All done.

PS C:\Users\me> gpg -k
C:\Users\me\AppData\Roaming\gnupg\pubring.kbx
------------------------------------------------
pub   rsa4096 2013-09-21 [SC] [expire : 2025-06-08]
...

I do not remember if i even need to rebuild the devcontainer, sorry ... but do it anyway :) Then in the devcontainer, after restarting vs code, everything finally worked as expected :

codespace ➜ /workspaces/test (main) $ gpg -k
/home/codespace/.gnupg/pubring.kbx
----------------------------------
pub   rsa4096 2013-09-21 [SC] [expires: 2025-06-08]
...

When i tried to sign in the container too, and i was prompted for the passkey in the popup from gpg4win on my windows host, so everything was perfect .. and i did not need to do anything regarding any pinentry or anything like that (either in the container or in wsl or on the host) !

codespace ➜ /workspaces/test (main) $ echo toto | gpg --clear-sign
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

toto
-----BEGIN PGP SIGNATURE-----

iQGzBAEBCgAdFiEE2LWWuSw5K2rufr12JnueH3T+3VcFAmZ/HT4ACgkQJnueH3T+
...
=9f5i
-----END PGP SIGNATURE-----

So now it works and no need doing ugly things like copying your keys to the container, that's no-good.

Hope this helps someone !

[chrmarti]

I'm getting a fix in for this. Looking forward to your feedback once it is available in the next pre-release version of Dev Containers. Thanks!

There are a few combinations:

• no keyboxd locally and:
  • no keyboxd in container: copy pubring.kbx, pubring.pgp and trustdb.gpg (as before).
  • keyboxd in container: export public keys, certificates and owner trust locally and import in container.
• keyboxd locally and:
  • no keyboxd in container but GPG version supports it: enable keyboxd and forward keyboxd socket to local. And: Export and import owner trust.
  • no keyboxd in container: export public keys, certificates and owner trust locally and import in container.
  • keyboxd in container: forward keyboxd socket to local. And: Export and import owner trust.

Repository with configurations for verification: https://github.com/chrmarti/keyboxd-testing Commands to locally go between using pubring.kbx and keyboxd: https://github.com/gpg/gnupg/blob/42ee84197695aca44f5f909a0b1eb59298497da0/README#L134C2-L145 To verify: Have a key set up locally and verify it can be used with all the above combinations using the configurations from the above repository.

[nipil]

@chrmarti : could you please confirm that in any of these cases :

• the private keys are never copied to the container
• every access to secrets are done through sockets

Thanks in advance for the clarification

[chrmarti]

@nipil Certainly, secret keys are used through the gpg-agent socket as before. 👍

[chrmarti]

This is now available with Dev Containers 0.376.0-pre-release. Please give it a try and let me know how it goes.

Updated my lengthy comment above to mention that owner trust is also export locally and imported in the container when the keyboxd is used. Apparently the keyboxd only makes public keys and certificates available, but not owner trust.

Adding some details:

• Secret keys are indirectly available in the container through the agent-socket which is forwarded to the agent-extra-socket locally. (As before, this didn't change.)
• When only one side (local or container) ends up using the keyboxd, we export and import public keys and certificates the way https://github.com/gpg/gnupg/blob/42ee84197695aca44f5f909a0b1eb59298497da0/README#L134C2-L145 documents it except that we don't use files but only stdio for the transmission.
• Export locally:

       gpg --export --export-options backup  > allkeys-in-memory-buffer
       gpgsm --export --armor                > allcerts-in-memory-buffer

• Import in container:

       gpg --import --import-options restore < allkeys-in-memory-buffer
       gpgsm --import                        < allcerts-in-memory-buffer

• When one or both sides (local and/or container) use the keyboxd, we also export and import owner trust.
• Export locally:

       gpg --export-ownertrust                > ownertrust-in-memory-buffer

• Import in container:

       gpg --import-ownertrust                        < ownertrust-in-memory-buffer

[jesusfer]

I may be missing something, but I just updated to the prerelease version and created a new dev container using the Python 3 image (mcr.microsoft.com/devcontainers/python:1-3.12-bookworm) which uses gnupg v2.2.40.

My local Windows is running keyboxd:

gpg --version
gpg (GnuPG) 2.4.5
libgcrypt 1.10.3
[...]
gpg -k
[keyboxd]
---------
pub   ed25519 2024-05-15 [SC]
[...]
sub   cv25519 2024-05-15 [E]

Once the container starts, I see the following when trying to list the keys (no keys are listed):

vscode ➜ /workspaces/test $ gpg --version
gpg (GnuPG) 2.2.40
libgcrypt 1.10.1
[...]
vscode ➜ /workspaces/test $ gpg -k
gpg: keybox '/home/vscode/.gnupg/pubring.kbx' created
gpg: /home/vscode/.gnupg/trustdb.gpg: trustdb created

Do we still need to manually import keys and trust into the container?

[chrmarti]

@jesusfer Could you append the Dev Containers log from when you rebuild the container? (F1 > Dev Containers: Show Container Log)

[chrmarti]

Fixed in Dev Containers 0.377.0-pre-release. Please give that a try and let me know how that goes, thanks!

[jesusfer]

It works now with 0.377 👍🏻