search

AGWA / git-crypt

Transparent file encryption in git
https://www.agwa.name/projects/git-crypt/
GNU General Public License v3.0
8.18k stars 475 forks source link

Can't add new user gpg keys #174

Open willb-the opened 5 years ago

willb-the commented 5 years ago

Hi,

I've setup git-crypt in one of my team's repos. Got it working for me locally using the git-crypt add-gpg-user <gpgid> the first time.

However, my colleagues can't add their key to the repo and therefore, can't view the encrypted files. I also tried to delete and re-clone my repo and add a new gpg key for myself and all I got was: git-crypt: Error: Unable to open key file - have you unlocked/initialized this repository yet?

These are the steps I took:

I have a feeling there is something obvious I'm missing. Can anyone help clear this up?

EDIT thought it would be worth mentioning, that typing git-crypt unlock shows this message: 

Error: no GPG secret key available to unlock this repository.
To unlock with a shared symmetric key instead, specify the path to the symmetric key as an argument to 'git-crypt unlock'.

I thought that using gpg means each person can have their own key?

olivergondza commented 5 years ago

Mind only the people with their key already added can add further keys. IOW, if your colleague would like to join you in maintaining secrets, it is you who has to add his key - not him. Otherwise everyone could add their keys and read the secrets...

willb-the commented 5 years ago

Thank you, @olivergondza, for responding.

After a lot of Googling we eventually figured that out. Would it be ok if I did a PR to include this little detail in the README? It seems obvious now, but at first it was quite confusing.

olivergondza commented 5 years ago

It does not appear to be stressed there so it is a good thing to do. Let's see what maintainers think...

jordanrobinson commented 2 years ago

In case anyone else ends up here from the same error message, in my case it was that I was using the -k, --key-name KEYNAME flag on a repo that had a different keyname, as I'd copied the command from another repository. It worked without that flag and used the default key.