Hi again, Le 31/03/2018 à 20:30, Teddy Hogeborn a écrit : > That is the important message. It means that it failed to decrypt the > data from the server using the GPGME library. In the past, this error > has been due to all the necessary GnuPG binaries not having been copied > into the initramfs image.
I could make some further progress. The problem resides in GnuPG being unable to properly import the keys when running in the true initramfs, where it works running in the chroot. I've seen that Mandos creates a temporary directory in /tmp where it put files, in both situation. Then I turned on gpgme debug mode using : export GPGME_DEBUG='9:/tmp/gpgme.log' ...Before running the client, then checked and compared the outputs. (I won't attach the huge outputs because they obviously contain key material) I discovered that gpgme is first fed with a private key, sends it for GPG to import, then a public key, which it sends to GPG for import, and further on the decryption occurs. In the chroot, it ends by GPG replying with : [GNUPG:] DECRYPTION_OKAY. [GNUPG:] GOODMDC. [GNUPG:] END_DECRYPTION. But in the initramfs, it ends with : [GNUPG:] NO_SECKEY <key_id>. [GNUPG:] BEGIN_DECRYPTION. [GNUPG:] DECRYPTION_FAILED. [GNUPG:] PROGRESS - 1189 0 B. [GNUPG:] END_DECRYPTION. Then I interested myself to the key imports. In the chroot, the secret key import replies : [GNUPG:] KEY_CONSIDERED <key_id>. [GNUPG:] IMPORTED <key_name>. [GNUPG:] IMPORT_OK 1 <key_id>. Where in the actual initramfs, it replies : [GNUPG:] IMPORT_RES 1 1 0 0 0 0 0 0 0 1 0 0 0 0 0. So the issue is definitely GPG working in the chroot, and not working in the initramfs. I still have to try and figure out what difference could be a cause for this. Kind regards. ॐ -- Michel Bouissou <mic...@bouissou.net> OpenPGP ID 0xEB04D09C
signature.asc
Description: OpenPGP digital signature
