-
-
Notifications
You must be signed in to change notification settings - Fork 199
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GnuPG2 2.2 vs 2.1 conflicts in keybox format #136
Comments
@gthank thanks for the report. Could you please try the same with the version from |
@sobolevn I get the same behavior from |
@gthank I'd like to try to replicate this. What OS/distribution uses gpg 2.1? |
I'm starting to think that incompatibilities between different versions of gpg are outside the scope of what git-secret should handle. I think we should just document the possibility of problems interoperating between GPG versions and close this (unless it's specifically related to git-secret) |
@joshrabinowitz That link is basically exactly what's going on. Ubuntu 16.04 uses the 2.1 line of code (probably with some backports, given their Debian heritage), which is also how it's a problem on Windows: the WLS thing on Windows uses Ubuntu 16.04. As for whether to even address this from |
@gthank I don't think the issue is the unexpected 'gpg: skipped packet of type 12 in keybox' warnings, but rather that gpg returns a non-0 exit code when it returns, which signals error. |
This issue is described in reasonable detail here: keybase/client#6923 |
#170 Displays an error message and exits if it is unable to decrypt any file. It also gives a more detailed error message if I'm not sure what is the ideal behavior in this case. Here are some possibilities:
What's the ideal solution for Also would be good to create a test for this issue. |
@joshrabinowitz @sobolevn @notjames From my perspective, there's not an ideal solution to this from the |
So, is this the desired logic?
|
@joshrabinowitz @sobolevn I like that idea. Depending on whether |
@gthank To follow up -- it does not return a unique exit code. I looked in the source, and as https://unix.stackexchange.com/questions/50541/what-does-gpg-error-code-2gpg-err-unknown-packet-mean explains,
|
Thanks for your detailed responses. For the record, I just successfully tested git-secret inter-operation between
I didn't do exhaustive testing, but I was unable to trigger any problems after several 'tell', 'killperson', 'reveal' and 'hide' operations between the machines (with git commits/pushes/pulls as appropriate). EDIT: I was able to eventually see problems interoperating between the above versions of gpg with git-secret From my reading, it seems like the solution is to make sure you use interoperating versions of gpg. If your gpg versions interoperate well in your 'clean room' testing (IE with newly created keychains and repos) but your keyfiles wind up causing issues anyway (which can occur if you used them through particular upgrades in the 2.0.X series, I believe), try "exporting and re-importing everything" (See: keybase/client#6923 (comment) ) @gthank = Is it possible to upgrade the gnupg version on the Edit - I also made use of the SECRETS_GPG_COMMAND environment variable as described at http://git-secret.io/git-secret to choose between installed versions of GPG as needed (particularly on Ubuntu to choose between gpg and gpg2) |
@joshrabinowitz Can you walk me through how you did this? If you did the EDIT: It's not really practical to upgrade the GnuPG version on the Windows box. We're using GnuPG straight out of |
@gthank when you say you're using 'gpg straight out of apt', you mean the apt included in windows10 WLS? If so, can the ubuntu subsytem be upgraded? Also have you tried using gpg2 2.2.6 from OSX's 'brew'? That's what I tested with on the Mac. Please let us know if you discover anything about the exact order of init/tell/hide/reveal on the different systems/gpg versions to either trigger or avoid the issue. It would be best if we could provide instructions on how to fix this issue ( skipped packet of type 12 in keybox) rather than doing some hacky workaround. If possible. |
@joshrabinowitz Yes, I mean the I have not checked the GnuPG from Homebrew; I can work try that out later today, probably. Initial StepsOn my Mac
On the other machines
Workaround StepsOn Ubuntu server
On my Mac
|
@sobolevn what do you think we should do about this? |
@joshrabinowitz I think we should not fix this issue from our side. This comment says that reimporting works: keybase/client#6923 (comment) Maybe we can even write some helper script to |
@gthank I'm planning on adding some documentation about this. Can you please try the |
Also, in my testing, I was able to replicate the |
@joshrabinowitz I'm actually fairly booked up for the next couple of days. Can you give me a 50,000 ft overview of what |
@gthank I just ran through the export/import process:
If that doesn't might be necessary to do the export on one system (probably the one where everything works), copy the file to the other system, and do the import there. |
It sounds like they turned off jenkins (https://lists.gnupg.org/pipermail/gnupg-users/2018-January/059817.html) and they don't follow any sort of semantic versioning so future breakages (or annoyances, I know this isn't technically breaking) shouldn't be much of a surprise. I started suppporting https://www.patreon.com/neopg According to https://lists.gnupg.org/pipermail/gnupg-users/2017-September/059096.html using GPGME is recommended for a (more) stable interface. |
@jcrben thanks for |
I get why the external format of a key is stable (people exchange keys) yet the key ring format may not be forwards compatible (people upgrade, but dont downgrade, and it's unusual to be sharing key rings rather than keys). How about we switch to storing keys in the public key format and don't commit the keyring that can "cache them" for repeated use:
The advantages of this approach should be:
That's just a rough sketch I may have missed something but fundermentally using a shared key ring rather than exported public keys is an "optimisation" over the approach above. Our current "optimisation" of a shared public key ring is causing teams who use different distributions or operating systems a compatibility challenge. So we should "downgrade" our approach to have logic that uses a local ignored keyring as a "cache". |
I like the idea of moving away from managing keyrings by ourself. |
@notjames as I understood @simbo1905's suggestion, we are not going to use the default keyring in But, this keyring will be ignored by the |
OK. I think I'm able to work through in my head how this will work. The part that I was not thinking about is the actual encrypted files which have been encrypted by specific keys as being the so-called "access list" I was on about. That said, why use the public keyring in the repo at all? Why not just use each user's |
Because we do not want to pollute user's main keyring with our keys. |
An interesting thing to want to avoid since the keyring is "polluted" by public keys already anyway. My keyring has keys from me, co-workers, public keys from OS maintainers, etc. I don't and have never really cared about what's in there. I think it's good to be cognizant of good housekeeping, but I believe you cause potentially more issues by not keeping the keyring in a well-known backed up place. If someone were to lose the keyring for whatever reason, would it be difficult to recover the keys required to re-encrypt the files? I'm not so sure it's a good idea to have a keyring that isn't backed up somewhere. Currently, that is the repo. If that is removed, recovery could end up being a problem. Putting the keyring in the repo but not backed up is something people who have knowledge of how this system works can deal with, but to the lay-user, not-so-much. |
I think what @simbo1905 is suggesting is that The file(s) of public keys in text representation would be portable across gpg versions. (You can see a public key in text representation with: The actual gpg keychains used on each given system (for each repo using git-secret) would be created, cached, and re-created from the public keys (and at least one of the needed private keys, which are probably in the user's keychain in The idea is that keychain files, which differ across gpg versions, would not be checked into the git repo. In this way git-secret would avoid issues with different systems' versions of gpg reading and writing files in |
@joshrabinowitz OK. I think I understand better by your description what @simbo1905's suggestion is. It all sounds OK, only maintaining the flat-file ascii-armored keys might become a pain in the butt... |
At https://stackoverflow.com/a/22147722 it says:
Here are the docs of the format https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob_plain;f=doc/DETAILS Running it over my old key I see:
The first line has
There might be other commands that need to be altered, so that is just a high-level approach. As it looks like we can use a documented machine-readable format that should be stable, it looks to me like we should be safe. A simple tool like |
For bonus marks I think we can make the new approach forwards compatible with the current approach. Let's say we version the new approach
This would mean:
We will have to maintain the old logic in the code base for a while. We can give a deprecated warning and at some future 0.4 (or 1.0!) drop that logic. I think backwards compatibility is worth the effort though as the new logic simply needs to runs the old logic and have a migrate step. We can keep an eye on how much maintenance the old logic needs and make a call to ditch it sooner rather than later if the burden is high. So how do we make the decision to adopt the proposed approach? One idea is I could make an "RFC001.md" containing the described approach and send a PR. We can then do a code review of it and update it and use the usual "LGTM" approach. Once we are happy to merge to master its the new design. Then we can open a fresh ticket to implement it. That would avoid these long and heavy comments in the future! |
+1 for this roadmap. Thanks @simbo1905 |
here is a first draft of the first part of the design as a PR #207 |
@simbo1905 @sobolevn I like the RFC, I think it's a big step forward. Would love to see 0.2.x released before this development starts though! |
The ticket for the long-term fix is #208 |
For anyone else arriving here, I created a Docker image that contains git-secret and gpg 2.2 to solve this problem for me. The repo (with usage documentation) is here: |
@ncpierson awesome! Thanks! |
I see this is still open. I ran into it today. Initialized git secret on my mac, gpg version: 2.2.27, but can't reveal secrets on our CI/CD server: Ubuntu 16.04 (xenial); gpg version: 2.1.11. Are there any plans to implement a fix? And is there any documentation for the export/import of keys? In the meantime, I may try this docker workaround. Thanks! |
I think the fix is to use |
That's good input about documenting how to export and import keys, I'll add a ticket about that @emacdona |
See also #631 |
See also #739 which appears to be a gnupg version interoperability issue too. |
the causes and implications of this and related issue are pretty well documented. Closing this |
What are the steps to reproduce this issue?
git-secret
on a machine usinggnupg2
version 2.2git-secret
(tell
,add
,hide
, etc.) and publish the changesgit
repo onto a machine usinggnupg2
version 2.1 (w/ the proper keys imported)git secret reveal
What happens?
And no secrets are revealed.
What were you expecting to happen?
The secrets to be revealed.
Any other comments?
After digging around, it seems that GnuPG 2.2 added some things to the keybox format that older versions don't have. I realize this is a result of problems with underlying libraries. What I'm hoping is there's some way for you to force an interoperable format by specifying a flag when creating the keybox (or just force use of the older
.gpg
keyring format instead of the newer.kbx
).What versions of software are you using?
Operating system:
Darwin hank-mbpr 17.4.0 Darwin Kernel Version 17.4.0: Sun Dec 17 09:19:54 PST 2017; root:xnu-4570.41.2~1/RELEASE_X86_64 x86_64
Linux falcon 4.4.0-43-Microsoft #1-Microsoft Wed Dec 31 14:42:53 PST 2014 x86_64 x86_64 x86_64 GNU/Linux
git-secret
path:*
/usr/local/bin/git-secret
/usr/bin/git-secret
git-secret
version:0.2.2
0.2.2
git
version:git version 2.16.2
git version 2.7.4
Shell type and version:
zsh 5.4.2 (x86_64-apple-darwin17.3.0)
GNU bash, version 4.3.48(1)-release (x86_64-pc-linux-gnu)
gpg
version:gpg (GnuPG/MacGPG2) 2.2.3
gpg (GnuPG) 2.1.11
The text was updated successfully, but these errors were encountered: