Does not find private keys on CI/Jenkins node

[ChrisHubinger]

What are the steps to reproduce this issue?

Try to run git secret [cat|reveal] ... as part of jenkins build.

What happens?

Aborts with: git-secret: abort: no public keys for users found. run 'git secret tell email@address'

What were you expecting to happen?

To decrypt our secrets.

Any logs, error output, etc?

When listing keys with gpg --list-secret-keys as part of the same build script just one line before the reveal command i get:

/home/jenkins/.gnupg/secring.gpg
--------------------------------
sec   4096R/1E31BAB8 2019-07-12
uid                  jenkins@jenkins.xxx.xx (Key used to decrypt build/deployment secrets) <jenkins@jenkins..xxx.xx>
ssb   4096R/171342A0 2019-07-12

The command git secret reveal
returns:

gpg: keyring `/var/lib/jenkins/jobs/GEMS/jobs/design-system/branches/feature-GE.re5lfdiic.e-npm-token/workspace/.gitsecret/keys/pubring.gpg' created
git-secret: abort: no public keys for users found. run 'git secret tell email@address'.
Revealing secrets failed. Create empty file.

Manually cloneig the repository and git secret reveal works

What versions of software are you using?

Operating system: (uname -a) …
Linux jenkins1 3.10.0-957.21.3.el7.x86_64 #1 SMP Tue Jun 18 16:35:19 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

git-secret path: (which git-secret) …
/bin/git-secret
git-secret version: (git secret --version) …
0.2.6
git version: (git --version) …
git version 1.8.3.1

Shell type and version: ($SHELL --version) …
GNU bash, version 4.2.46(2)-release (x86_64-redhat-linux-gnu)
gpg version: (gpg --version) …

gpg (GnuPG) 2.0.22
libgcrypt 1.5.3

kind regards & thanks for the great piece of stoftware you provide
Christian

[joshrabinowitz]

Hello, @theanimal666 , thank you for this issue report!

My first thought is to check what version of gpg was used when creating the git-secret keyrings (IE, at .gitsecret/keys/pubring.gpg in your repo).

When running gpg --list-secret-keys in jenkins, you're looking at the keychain in ~/.gnupg, not your-repo/.gitsecret/keys

There are known compatibility issues when reading binary files created from different versions of gpg. See: #228 , #136, #208 . We have plans to move away from dependence on gnupg's binary formats: see #207 . As always, PRs are welcome!

Please let us know if gnupg interoperability issues seem to explain the issues you're seeing.

[joshrabinowitz]

When you say Manually cloning the repository and (using) git secret reveal works, do you mean it works on your development env? If so, as per comment above, check what version of gnupg you're using on your dev env.

[ChrisHubinger]

Hi, Thanks for the quick answer.

I do not have a .gitsecret/keys/pubring.gpg file in my repo, only a pubring.kbx. So that seems to be the issue.

On my dev machine, where i've setup the repository & added the keys i'm running gpg 2.2.x and on the CI server it is 2.0.x.
Is it possible that not only the format but also the filename changed?

When you say Manually cloning the repository and (using) git secret reveal works
yes, a colleague cloned the repo and had no poblems revealing the secrets.

I'll make a gpg upgrade and check if it works with a newer version, and let you know.

[joshrabinowitz]

@theanimal666

Yes both the content, and the filenames of the binary files used by different versions of gnupg may change, especially between disparate versions such as 2.0.x and 2.2.x.

Quoting https://github.com/sobolevn/git-secret/blob/master/RFC/RFC001.md :

GPG maintains backwards compatibility but not forwards compatibility. Running a new GPG version can and will upgrade the keyring storage files in a way that is not recognized by older versions of GPG. This is not normally a problem for typical GPG usage. Users will upgrade and rarely downgrade. It is a problem for git-secret as the keyring storage is committed to git and shared between users. Someone using an older version of GPG can no longer open the upgraded keyring file.

[ChrisHubinger]

I just compiled and installed gnupg 2.2 on the server and now everything works as expected 🎉🎉🎉

Thanks a lot for the great support! Without the hint i'd never guessed that 2.2 may not be compatible with 2.0, maybe too long working in semver county ;)