Improve usability/documentation with untrusted GPG keys

[BrendanThompson]

Hey @AGWA having a weird issue when I'm trying to add my GPG key, i get the following

gpg: <Key ID>: There is no assurance this key belongs to the named user
gpg: [stdin]: encryption failed: Unusable public key
git-crypt: GPG error: Failed to encrypt

Any ideas on that one matey?

[AGWA]

The issue is that the key isn't trusted by GPG, which is to say GPG doesn't know that the key really belongs to the person whose name is on the key. It's important to be sure you're encrypting to the right person, which is why GPG blocks attempts to encrypt to untrusted keys by default.

To make GPG trust the key, you can locally sign it:

gpg --lsign-key KEYID

I need to think long and hard about how git-crypt should handle this. PGP (and by extension, GPG) was originally meant to be used with a web-of-trust model where trust is established by people signing each other's keys. However, many people who use GPG these days don't bother with the web-of-trust and it may just be an impediment to people using git-crypt. git-crypt could disable trust checking when using GPG, which is apparently what git-annex and git-remote-gcrypt do[1], but I'm not really comfortable forcing that on users who actually do use the web-of-trust.

[1] https://github.com/blake2-ppc/git-remote-gcrypt/issues/3

[BrendanThompson]

@AGWA ahh my bad!! I have my GPG setup in TEMPFS. Forgot to reauth it as my own key :).

There is however seemingly an issue with the creation. As you can see below the first is a backtick and the final is a '

gpg: can't create `/Users/bthompson/Test/enc/.git-crypt/keys/default/0/B66010426D520F61ED34742E8D3725145E871BD7.gpg': No such file or directory

thanks :)

[AGWA]

I'm pretty sure the quotes are just part of the error message, not part of the path. I think this means that the /Users/bthompson/Test/enc/.git-crypt/keys/default/0 directory does not exist, which is very strange because git-crypt creates it right before calling GPG.

Could you check to see if the /Users/bthompson/Test/enc/.git-crypt/keys/default/0 directory exists, and if not, which of its ancestor directories do exist?

[BrendanThompson]

@AGWA Okay i checked. (keeping in mind this is in a windows environment, as this all works fine on OS X) That entire directory structure actually exists, just the *.gpg doesn't. Also if i manually create that gpg file then things just break!

[AGWA]

Ah, didn't know this was Windows. I'll try to debug this but it might be a while before I can get to it. Are you running this from the Windows command prompt or from a MinGW shell?

[BrendanThompson]

I'm actually using babun which in essence uses MinGW :). It was able to make git-crypt fine but yeah there just seems to be the issue with the adding a gpg key which kind of sucks! :( Anything i can do to assist let me know

[AGWA]

I think the problem may be that the path passed to GPG is missing C:\. Could you run git rev-parse --show-toplevel from inside your Git repo and send me the output?

[BrendanThompson]

Hey mate,

This is the path it actually get's sent, I skipped out some crud on the first comment.

gpg: can't create `/cygdrive/c/Users/bthompson/Test/enc3/.git-crypt/keys/default/0/B66010426D520F61ED34742E8D3725145E871BD7.gpg': No such file or directory

The command you stated returns: /cygdrive/c/Users/bthompson/Test/enc which i can cd or touch into as well.

[AGWA]

Try running this:

gpg -e -r KEYID -o /cygdrive/c/Users/bthompson/Test/enc/test.gpg

where KEYID is some key ID that's in your keychain, and test.gpg is some filename of your choosing (doesn't matter what it is).

[BrendanThompson]

Yeah that fails with the same issue. It does kinda look as though it's the fact that there is no C:\ at the front and the slashes are the wrong way :).

It seems that babun doesn't use MinGW, but cygwin instead. I am just going to try with MinGW. Wish there was a way to natively build git-crypt on Windows! :)

[AGWA]

Right, I was just thinking that Cygwin might be the problem here. Git is clearly using Cygwin if it's outputting /cygdrive paths. I'm guessing that GPG is not because it doesn't understand the /cygdrive paths. If you could install GPG through Cygwin it would probably fix the problem.

Alternatively, you could try to install Git and git-crypt natively with MinGW. git-crypt has very preliminary native Windows support on the revamp branch. It compiles and runs but I haven't figured out the build system yet so you'll have to tinker with the Makefile a bit.

[BrendanThompson]

yeah already trying to do that at the moment. Having a few issues with the key seemingly not working on a remote system. I might just create a new repo and start again :). Let me know if there is a procedure that i should be following for this one :)

[AGWA]

What issues are you seeing with the key on the remote system?

It is possible things got a bit messed up when you were debugging the Cygwin issue, so a fresh repo might just be easier. And if you record the steps you take setting up the new repo, it would help with debugging if you hit a problem.

[dupuy]

I had this issue ("There is no assurance this key belongs to the named user") when I started using the GPG keys feature, and I suspect that pretty much anyone who tries to use git-crypt with GPG keys will run into it sooner or later. My first guess was that the user who generated the key had somehow forgotten to sign it, but of course the problem was that I hadn't signed it; this needs to be in the documentation (probably the README) and perhaps in the error handling code as well (i.e. if gpg command fails then suggest to the user that they may need to sign the key that they are trying to add).

[AGWA]

Ah, thanks for reminding me about this issue @dupuy. Last week I added a --trusted option to git-crypt add-gpg-user. If you use it, it will add the user even if their key isn't trusted by GPG. I would like it if git-crypt could output a helpful error message informing the user of the --trusted option, but unfortunately GPG doesn't use a unique exit status for an untrusted key, so I would have to either output the message upon any GPG error, even if it's not relevant, or attempt to parse stderr. Documenting this in the README is also a very good idea.

[pfalcon]

I read this ticket, #39, #47 - and they not only cover issues with git-crypt I immediately spotted during initial testing of git-crypt, but also offer comprehensive discussion, and good plan for solutions. And... nothing. Perhaps, at this point, user pull request should be coming in. But having so many obvious issues not resolved makes one wonder if the overall approach is sound and if someone better be using something like git-remote-gcrypt . So, @AGWA, what's happening with git-crypt - do you maintain it, or may I imagine that you fell out of love with it, with having so many unresolved issues?

[BrendanThompson]

Going to close this off, as there is seemingly no resolution in sight.