git-secret: gpg: [don't know]: partial length invalid for packet type 20 in the gitlab ci job

Question

I have a trouble with git secret in the gitlab ci jobs.

What I done:

1. init, add users, add files, hide them using git secret
2. create a job where I want to reveal files:

git secret:
  stage: init
  before_script:
    - sh -c "echo 'deb https://gitsecret.jfrog.io/artifactory/git-secret-deb git-secret main' >> /etc/apt/sources.list"
    - wget -qO - 'https://gitsecret.jfrog.io/artifactory/api/gpg/key/public' | apt-key add -
    - apt-get update && apt-get install -y git-secret
  script:
    - echo $GPG_PRIVATE_KEY | tr ',' '\n' > ./pkey.gpg
    - export GPG_TTY=$(tty)
    - gpg --batch --import ./pkey.gpg
    - git secret reveal -p ${GPG_PASSPHRASE}

Result logs:

...
$ gpg --batch --import ./pkey.gpg
gpg: directory '/root/.gnupg' created
gpg: keybox '/root/.gnupg/pubring.kbx' created
gpg: /root/.gnupg/trustdb.gpg: trustdb created
gpg: key SOMEKEY: public key "Email Name <[email protected]>" imported
gpg: key SOMEKEY: secret key imported
gpg: Total number processed: 1
gpg:               imported: 1
gpg:       secret keys read: 1
gpg:   secret keys imported: 1
$ git secret reveal -p ${GPG_PASSPHRASE}
gpg: [don't know]: partial length invalid for packet type 20
git-secret: abort: problem decrypting file with gpg: exit code 2: /path/to/decrypted/file

I don't understand where the problem. What mean packet type 20? And length of what? Locally it revealed fine. Command git secret whoknows shows that email on the ci env can decrypt. Passphrase checked and passed to the job.

Answer 1

For me, the problem was the GnuPG versions being different between the encryption machine (v2.3) and the decryption side (v2.2).

After I downgraded it to v2.2 (due to v2.3 not yet being available on Debian), the problem went away.

Answer 2

This is a common problem with the format of the keys.

Since you're using GitLab CI, you should get advantage of the File type in the CI/CD Variables instead of storing the value of the GPG Key as a Variable type.

First of all, forget about generating the armor in one line with the piped | tr '\n' ',' and get the proper multiline armor.

Second, add it to your GitLab CI Variables with type "File", add an empty line at the end and then delete it (this seems stupid but will save you headaches, since it seems to be a problem when copying directly from the shell to the textbox in GitLab).

Third, import directly the file in your keychain:

gpg --batch --import $GPG_PRIVATE_KEY

Answer 3

Here's the technical answer:

GnuPG has made some long-overdue changes between 2.2 and 2.3. 2.2 defaults to "let's generate traffic like we've done since 2000", and 2.3 defaults to "let's use some newer and better cryptography". It's possible to create traffic in 2.3 that cannot be read in 2.2.

Adding "rfc4880" to your %APPDATA%\gnupg\gpg.conf file on your Windows box might help: this forces GnuPG to use the older style of cryptography.

From: https://lists.gnupg.org/pipermail/gnupg-users/2022-January.txt

Update: As of today, I have not been able to get gpg 2.4 to encrypt in a way that is compatible with gpg 2.2