agwa / git-crypt Goto Github PK

View Code? Open in Web Editor NEW

8.0K 88.0 464.0 333 KB

Transparent file encryption in git

Home Page: https://www.agwa.name/projects/git-crypt/

License: GNU General Public License v3.0

Makefile 1.29% C++ 98.71%

git-crypt's People

Stargazers

Watchers

Forkers

jesboat linus repos-git jwshapiro obazoud daemon13 itcgbaggi darayusn darayus helios66 stabledog skettler apanly marcelhuberfoo mkubenka weiyeh jo ccleaud silky ndbroadbent magnum manithnuon alerque kotlinski tristanz hobson kevikoech umurkontaci bdacode tourountzis boucher aaronromeo libertyy kalbasit programfan staticfloat dwdunn-llu yarnhoj madeiracloud eluxen sharedhealth balexander123 paulbovbel dsernst akram pombreda tachang charg flashbuckets opavader magnite archsaber i-sam florin-t telekom-pd pfalcon rowhit rbehnke imjerrybao planorama-bot kostyll janhalfar sweetjian osoroka-evo 40a leslie89xlxiao yanchunlei licong alanrossmachinery jjensn michaelaquilina mikulas juanmhidalgo charlesmims jacobben85 nirvdrum dcreemer ricebeans happy-ferret serrvius chance-focalcast wemstad ggeorggg junaid-ali brammittendorff-dd jean aislematt underxirox haoyayun bluepine shlomosh teaforthecat shezis tkooda boundary deathstrob23 antoine-dbr zetneteork etsangsplk adamnbowen

git-crypt's Issues

debian package maintainer ?

Hi,
i wonder if you are planning to upload your software to debian,
and i offer to help reviewing / uploading it.

Use an IV when encrypting with AES

For encrypted files it would be beneficial to use an IV and using CBC when doing the AES encryption. Store the IV in the header portion of the encrypted files (with your GITCRYPT header).

Major issue - Locked but unlock stopped working.

I've recently encrypt all my files using lock and unlock apparently now broken...

gpg: no valid OpenPGP data found.
gpg: decrypt_message failed: Unknown system error
git-crypt: GPG error: Failed to decrypt

Is there a way to manually unlock using my existing GPG key?

git-crypt used alongside Github for Mac reliably breaks

This is essentially Issue #26 for Github for Mac instead of Atlassian SourceTree.

If I have a file to be encrypted upon commit, git commit ... from the command line works as expected. Clicking commit from the Github app produces the following message.

[master 3846a0e] MY_COMMIT_MESSAGE


"git-crypt" clean: git-crypt: command not found
error: cannot feed the input to external filter "git-crypt" clean
error: external filter "git-crypt" clean failed -1
error: external filter "git-crypt" clean failed
fatal: FILE_TO_BE_ENCRYPTED: clean filter 'git-crypt' failed
 (128)

The file(s) then pass through to the repository unencrypted.

I understand this might not be a high priority. Just thought it might as well be documented. ℹ️

Only encrypt specific words / lines in a file

It might be nice to only encrypt the parts of the file that contain sensitive information, as opposed to the entire file.

git-crypt unlock doesn't decrypt file

We have added 2 gpg's by doing:
git-crypt add-gpg-user USER_ID

Decrypting works for the first user, but when he pushes it and I pull and run git-crypt unlock, I get prompted for the passphrase (MacOS, GPG Suite):

You need a passphrase to unlock the secret key for
user: ...
4096-bit RSA key, ID ..., created 2015-08-17 (main key ID ...)

The program then finishes (no error message) but the file is still encrypted.

git-crypt does not compile on older Mac OS versions (10.8 or older)

Error log:

git-crypt-0.4.2 
$ make
c++ -Wall -pedantic -Wno-long-long -O2   -c -o util.o util.cpp
In file included from util.cpp:129:
./util-unix.cpp:322:12: error: no matching function for call to 'scandir'
        int                     n = scandir(path, &namelist, dirfilter, alphasort);
                                    ^~~~~~~
/usr/include/dirent.h:128:5: note: candidate function not viable: no known conversion from 'int (const struct dirent *)' to 'int (*)(struct dirent *)' for 3rd argument;
int scandir(const char *, struct dirent ***,
    ^
1 error generated.
make: *** [util.o] Error 1

A quick search turns up Homebrew/legacy-homebrew#13649 - seems like scandir has to be defined by our source for older OS?

git apply does not work on encrypted files

git apply can be useful when applying a patch from an email, or when working with stashes. When I try to use it with an encrypted file however, it seems to fail:

$ git apply some.patch
error: patch failed: conf/dbinfo.xml:1
error: conf/dbinfo.xml: patch does not apply

Applying the same patch to file that is not encrypted works fine.

Clarification on .gitattribute files.

I just tried the new git-crypt version, with asymmetric crypto, I ran git-crypt init on my new repo, and edited the .git-crypt/.gitattributes file to add the specs I wanted. However, I can't get git-crypt to actually encrypt the files. Am I supposed to move the .gitattributes file to the root dir of the repo?

21:24:40 $ cat .gitattributes 
*.secret filter=git-crypt diff=git-crypt
*.key filter=git-crypt diff=git-crypt
group_vars/*.yml filter=git-crypt diff=git-crypt
secret_keys.py filter=git-crypt diff=git-crypt

* !filter !diff

Command to edit .gitattributes

How would you feel about adding a command to more quickly add new items to git-crypt?

For example:

git-crypt add foobar.txt (or alternatively: git-crypt encrypt foobar.txt)
would be like running
echo "foobar.txt filter=git-crypt diff=git-crypt" >> .gitattributes

The aim here is for a simpler way to use git-crypt with less chance to screw up the syntax when adding new filters to .gitattributes

Pre-commit hook to avoid accidentally adding unencrypted files

This should not happen very often, but for users who do not read the doc, or someone who has locked their repository a long time ago and forgot about it, it could be useful to try and prevent this situation:

$ git crypt lock # a long time ago... then forgotten
$ echo "secret.file filter=git-crypt diff=git-crypt" >> .gitattributes
$ echo "secret" > secret.file
$ git status # forgot to check using git-crypt status
$ git add secret.file
$ git commit -m "added secret file"
$ git push

secret.file has been added to .gitattributes, but the repository was locked so the person ended up adding it unencrypted.

git-crypt status already displays a huge warning in this situation, but it remains possible to make a mistake when it is not run. May I suggest adding to the documentation an example of a pre-commit hook such as this:

#!/bin/sh
#pre-commit
git-crypt status | grep "*** WARNING"; test $? -eq 1

Add `list-gpg-user`command to list all added users

Is it feasible to introduce a new command

git-crypt list-gpg-user

to list all added gpg users? Are there alternatives to show that info with the existing implementation?

Add subcommand to know if repository is locked or unlocked

To automate my workflow, I would like to have a command to check if the repository is unlocked.

For instance, git-crypt locked which return code can be checked for automation purpose.

git-crypt unlock failing

I have a git repo on bitbucket. I was able to configure git-crypt add secure files lock and unlock. I recently tried cloning the repo and the running git-crypt unlock and it is failing.

> git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean

> git-crypt unlock

You need a passphrase to unlock the secret key for
user: "Russell Simpkins (Russ) <russellsimpkins@donotreply>"
4096-bit RSA key, ID 065C5B7A, created 2015-04-20 (main key ID 3B3F5A08)

git-crypt: error: encrypted file has been tampered with!
error: external filter "git-crypt" smudge failed 1
error: external filter "git-crypt" smudge failed
fatal: files/secure/appstack/app.properties: smudge filter git-crypt failed
Error: 'git checkout' failed
git-crypt has been set up but existing encrypted files have not been decrypted

Here is my current config

> cat .gitattributes 
files/secure/**/* filter=git-crypt diff=git-crypt

> git-crypt status |grep files/secure
    encrypted: files/secure/appstack/app.properties
    encrypted: files/secure/jenkins/id_jenkins

I thought maybe having the wildcards was causing an issue. I tried pointing at the files e.g.

> cat .gitattributes 
files/secure/appstack/app.properties filter=git-crypt diff=git-crypt
files/secure/jenkins/id_jenkins filter=git-crypt diff=git-crypt

But that did not make a difference.

I'm working on Yosemite 10.10.3. Git-crypt installed using brew to install version 0.4.2

Any thoughts on this? Is it possibly related to bitbucket?

`git-crypt unlock` fails

I have a repo with GPG-encrypted keys, and if I try to unlock it, I get this:

00:59:55 $ git clone [email protected]:thing
Cloning into 'thing'...
Checking connectivity... done.

01:00:01 $ cd thing

01:00:17 $ git-crypt unlock
git-crypt: error: encrypted file has been tampered with!
error: external filter "/home/stavros/bin/git-crypt" smudge failed 1
error: external filter "/home/stavros/bin/git-crypt" smudge failed
fatal: deployment/group_vars/all.yml: smudge filter git-crypt failed
Error: 'git checkout' failed
git-crypt has been set up but existing encrypted files have not been decrypted

I tried changing the file on a machine that has it decrypted and committing, which worked for that machine/repo, but cloning it still fails.

git-crypt setup fails when user has untracked files in repository

$ git status 
...
nothing added to commit but untracked files present (use "git add" to track)

$ git-crypt init ~/git-crypt.key
Working directory not clean.
Please commit your changes or 'git stash' them before setting up git-crypt.

this is apparently due to git-crypt just checking for output of git status --porcelain not being empty in https://github.com/AGWA/git-crypt/blob/master/commands.cpp#L205

I think it should only check for modified files, and ignore untracked files (untracked files are not touched by git reset anyway, so git-crypt setup should be safe even with untracked files being present).

git crypt new version throws "not a valid git-crypt key file"

With the new version git-crypt throws me the following error:

Error: /opt/git-crypt-secret-key/git-crypt-secret-key: not a valid git-crypt key file

Since this is an old key created with an older version of git-crypt, do I have to recreate the key to get it working with the new version or is there another problam/solution?

thanks so much
Martin

Allow users to use GPG private keys as keyfiles

Rename key

How can one rename the key (that's easy) and then relink the git-crypt repository with the renamed key? Is a simple init sufficient, or does one has to git clone the repository again and relink it by init it?

'status' subcommand should not include ".git-crypt/" directory

for example, git-crypt status says something like this:

...
    encrypted: my.secret
not encrypted: .git-crypt/.gitattributes
not encrypted: .git-crypt/keys/default/0/DEADBEAF.gpg

but we already know that... really, the git-crypt metadata dir
should not be displayed by status (it's essentially metadata,
and should be considered as "out of band" information).

Issue performing interactive rebases

I was wondering if there is a known problem with interactive rebasing? This happens on a freshly-cloned repo containing git-crypt objects:

$ git clone [email protected]:user/somethinghere.git
$ cd somethinghere
$ git checkout some_branch_name
Switched to branch 'some_branch_name'
Your branch is up-to-date with 'origin/some_branch_name'.
$ git status
On branch some_branch_name
Your branch is up-to-date with 'origin/some_branch_name'.
nothing to commit, working directory clean
$ git rebase -i HEAD~5
Cannot rebase: You have unstaged changes.
Please commit or stash them.
$ git status
On branch some_branch_name
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean

Unfortunately I can't share the actual repo that has the issue.

Environment:

git-crypt 0.4.2
Mac os 10.10.3
git version 2.4.0

Thanks for your time!

Help me please. Error: 'git checkout' failed git-crypt has been set up but existing encrypted files have not been decrypted.

I have checked out my branch and tried to decrypt it's data, but got the error mesage:

Error: 'git checkout' failed
git-crypt has been set up but existing encrypted files have not been decrypted

Here is the steps that led up to it.

git checkout -b wnr2200_Flat4 origin/wnr2200_Flat4

Branch wnr2200_Flat4 set up to track remote branch wnr2200_Flat4 from origin.
Switched to a new branch 'wnr2200_Flat4'

git pull

Already up-to-date.

git-crypt status

not encrypted: .git-crypt/.gitattributes
not encrypted: .git-crypt/keys/default/0/B8F91A7C454C712DAF8CAD6A4C7B8EA505CF6FE4.gpg
not encrypted: .gitattributes
not encrypted: .gitignore
not encrypted: archives/backup-2Lv-dn-2015-02-21.tar.gz
not encrypted: archives/backup-2Lv-up-2015-02-25.tar.gz
not encrypted: archives/backup-3Lv-2015-02-25.tar.gz
not encrypted: archives/backup-4Lv-2015-02-25.tar.gz
not encrypted: archives/backup-Bungalow-2015-02-25.tar.gz
not encrypted: archives/backup-Flat1-2015-02-25.tar.gz
not encrypted: archives/backup-Flat4-2015-09-22_initial-upload-bef-chg-root-pwd.tar.gz
not encrypted: archives/backup-Flat4-2015-09-22_w-chgd-root-pwd.tar.gz
not encrypted: archives/backup-Flat4_blank_192.168-2015-09-22.tar.gz
not encrypted: archives/backup-Flat5-2015-02-25.tar.gz
not encrypted: archives/backup-Flat6-2015-02-25.tar.gz
not encrypted: archives/backup-Flat7-2015-02-25.tar.gz
not encrypted: archives/backup-Test_AP-2015-02-25.tar.gz
not encrypted: etc/config/dhcp
not encrypted: etc/config/dropbear
not encrypted: etc/config/firewall
not encrypted: etc/config/luci
not encrypted: etc/config/network
not encrypted: etc/config/rpcd
not encrypted: etc/config/system
not encrypted: etc/config/ubootenv
not encrypted: etc/config/ucitrack
not encrypted: etc/config/uhttpd
    encrypted: etc/config/wireless
not encrypted: etc/dnsmasq.conf
    encrypted: etc/dropbear/dropbear_dss_host_key
    encrypted: etc/dropbear/dropbear_rsa_host_key
not encrypted: etc/firewall.user
not encrypted: etc/group
not encrypted: etc/hosts
not encrypted: etc/inittab
not encrypted: etc/opkg.conf
not encrypted: etc/passwd
not encrypted: etc/ppp/chap-secrets
not encrypted: etc/ppp/filter
not encrypted: etc/ppp/options
not encrypted: etc/profile
not encrypted: etc/protocols
not encrypted: etc/rc.local
not encrypted: etc/services
    encrypted: etc/shadow
not encrypted: etc/shells
not encrypted: etc/sysctl.conf
not encrypted: etc/sysupgrade.conf
    encrypted: etc/uhttpd.crt
    encrypted: etc/uhttpd.key

Then I thought this woudl be the right thing to do, but maybe it wasn't?

git-crypt unlock ~/git-crypt-mykey.key 

git-crypt: error: encrypted file has been tampered with!
error: external filter "git-crypt" smudge failed 1
error: external filter "git-crypt" smudge failed
fatal: etc/config/wireless: smudge filter git-crypt failed
Error: 'git checkout' failed
git-crypt has been set up but existing encrypted files have not been decrypted

And now I suddenly have 6 changed files. (and if I peek into them they all have '^@gitcrypt^@' at the start of the file.)

git status

On branch wnr2200_Flat4
Your branch is up-to-date with 'origin/wnr2200_Flat4'.
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    deleted:    etc/config/wireless
    modified:   etc/dropbear/dropbear_dss_host_key
    modified:   etc/dropbear/dropbear_rsa_host_key
    modified:   etc/shadow
    modified:   etc/uhttpd.crt
    modified:   etc/uhttpd.key

no changes added to commit (use "git add" and/or "git commit -a")

How do I recover from this?

Various clang warnings when complining on OS X

Firstly: Thank you for writing git-crypt! We are using it in production.

$ clang --version
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix
$ uname -a
Darwin arcturus 13.4.0 Darwin Kernel Version 13.4.0: Sun Aug 17 19:50:11 PDT 2014; root:xnu-2422.115.4~1/RELEASE_X86_64 x86_64

Here are the warnings from clang:

crypto-openssl.cpp:45:2: warning: 'ERR_load_crypto_strings' is deprecated: first deprecated in OS X 10.7 [-Wdeprecated-declarations]
        ERR_load_crypto_strings();
        ^
/usr/include/openssl/err.h:296:6: note: 'ERR_load_crypto_strings' declared here
void ERR_load_crypto_strings(void) DEPRECATED_IN_MAC_OS_X_VERSION_10_7_AND_LATER;
     ^
crypto-openssl.cpp:55:6: warning: 'AES_set_encrypt_key' is deprecated: first deprecated in OS X 10.7 [-Wdeprecated-declarations]
        if (AES_set_encrypt_key(raw_key, KEY_LEN * 8, &(impl->key)) != 0) {
            ^
/usr/include/openssl/aes.h:92:5: note: 'AES_set_encrypt_key' declared here
int AES_set_encrypt_key(const unsigned char *userKey, const int bits,
    ^
crypto-openssl.cpp:70:2: warning: 'AES_encrypt' is deprecated: first deprecated in OS X 10.7 [-Wdeprecated-declarations]
        AES_encrypt(plain, cipher, &(impl->key));
        ^
/usr/include/openssl/aes.h:97:6: note: 'AES_encrypt' declared here
void AES_encrypt(const unsigned char *in, unsigned char *out,
     ^
crypto-openssl.cpp:80:40: warning: 'EVP_sha1' is deprecated: first deprecated in OS X 10.7 [-Wdeprecated-declarations]
        HMAC_Init(&(impl->ctx), key, key_len, EVP_sha1());
                                              ^
/usr/include/openssl/evp.h:666:15: note: 'EVP_sha1' declared here
const EVP_MD *EVP_sha1(void) DEPRECATED_IN_MAC_OS_X_VERSION_10_7_AND_LATER;
              ^
crypto-openssl.cpp:80:2: warning: 'HMAC_Init' is deprecated: first deprecated in OS X 10.7 [-Wdeprecated-declarations]
        HMAC_Init(&(impl->ctx), key, key_len, EVP_sha1());
        ^
/usr/include/openssl/hmac.h:95:6: note: 'HMAC_Init' declared here
void HMAC_Init(HMAC_CTX *ctx, const void *key, int len,
     ^
crypto-openssl.cpp:88:2: warning: 'HMAC_CTX_cleanup' is deprecated: first deprecated in OS X 10.7 [-Wdeprecated-declarations]
        HMAC_cleanup(&(impl->ctx));
        ^
/usr/include/openssl/hmac.h:93:27: note: expanded from macro 'HMAC_cleanup'
#define HMAC_cleanup(ctx) HMAC_CTX_cleanup(ctx) /* deprecated */
                          ^
/usr/include/openssl/hmac.h:91:6: note: 'HMAC_CTX_cleanup' declared here
void HMAC_CTX_cleanup(HMAC_CTX *ctx) DEPRECATED_IN_MAC_OS_X_VERSION_10_7_AND_LATER;
     ^
crypto-openssl.cpp:93:2: warning: 'HMAC_Update' is deprecated: first deprecated in OS X 10.7 [-Wdeprecated-declarations]
        HMAC_Update(&(impl->ctx), buffer, buffer_len);
        ^
/usr/include/openssl/hmac.h:99:6: note: 'HMAC_Update' declared here
void HMAC_Update(HMAC_CTX *ctx, const unsigned char *data, size_t len) DEPRECATED_IN_MAC_OS_X_VERSION_10_7_AND_LATER;
     ^
crypto-openssl.cpp:99:2: warning: 'HMAC_Final' is deprecated: first deprecated in OS X 10.7 [-Wdeprecated-declarations]
        HMAC_Final(&(impl->ctx), digest, &len);
        ^
/usr/include/openssl/hmac.h:100:6: note: 'HMAC_Final' declared here
void HMAC_Final(HMAC_CTX *ctx, unsigned char *md, unsigned int *len) DEPRECATED_IN_MAC_OS_X_VERSION_10_7_AND_LATER;
     ^
crypto-openssl.cpp:105:6: warning: 'RAND_bytes' is deprecated: first deprecated in OS X 10.7 [-Wdeprecated-declarations]
        if (RAND_bytes(buffer, len) != 1) {
            ^
/usr/include/openssl/rand.h:104:6: note: 'RAND_bytes' declared here
int  RAND_bytes(unsigned char *buf,int num) DEPRECATED_IN_MAC_OS_X_VERSION_10_7_AND_LATER;
     ^
crypto-openssl.cpp:107:31: warning: 'ERR_get_error' is deprecated: first deprecated in OS X 10.7 [-Wdeprecated-declarations]
                while (unsigned long code = ERR_get_error()) {
                                            ^
/usr/include/openssl/err.h:266:15: note: 'ERR_get_error' declared here
unsigned long ERR_get_error(void) DEPRECATED_IN_MAC_OS_X_VERSION_10_7_AND_LATER;
              ^
crypto-openssl.cpp:109:4: warning: 'ERR_error_string_n' is deprecated: first deprecated in OS X 10.7 [-Wdeprecated-declarations]
                        ERR_error_string_n(code, error_string, sizeof(error_string));
                        ^
/usr/include/openssl/err.h:280:6: note: 'ERR_error_string_n' declared here
void ERR_error_string_n(unsigned long e, char *buf, size_t len) DEPRECATED_IN_MAC_OS_X_VERSION_10_7_AND_LATER;
     ^
11 warnings generated.

Add --version.

Hello!

We rely on git-crypt for a lot of repos, and the absence of --version is making us sad as its hard to debug issues when some people can decrypt repos and some people cannot. "Oh, my version? Idk, HEAD of the repo from a month or so back".

Our team is on all sorts of distros + OS X so we cannot rely on a single package.

--version
"0.4.2 commit: 1ca8f89"

Would be super neat!

Symmetric secret key rotation

I didn't see anything in the README about key rotation. Is there a command like:

git-crypt re-encrypt /path/to/old/key /path/to/new/key

reserved identifier violation

I would like to point out that identifiers like "_COMMANDS_H" and "_CRYPTO_H" do not fit to the expected naming convention of the C++ language standard.
Would you like to adjust your selection for unique names?

Homebrew formula

Cool project ! Here's a Homebrew formula for the OSX users among us: https://gist.github.com/zimbatm/4727240

apply encryption retroactively with filter-branch

Would be nice to have an option in git-crypt to allow one to encrypt the protected files retroactively starting from beginning of time. This would rewrite all history, so would have to be done with care, but would be quite useful when doing an initial public release of a private repository.

Is this possible to do manually?

Add `del-gpg-user` to delete (and re-encrypt) repository

Need to be able to remove a GPG key for a user and then re-encrypt the repository. Obviously, the user would be able to decrypt old revisions but any new revisions would not be encrypted with the user's key.

please support user-specified gpg executable

On my system, the gpg binary is gpg1, but I want to use gpg2
(among other reasons, only gpg2 supports elliptic curves).

I looked at gpg.cpp and it looks like you are hardcoding gpg
invocations with:

    command.push_back("gpg")
    ...

I am requesting to have available an environment or command-line
override for the binary path, such as one of the following:

    git-crypt --gpg-command=`which gpg2` ...
    GIT_CRYPT_GPG=`which gpg2` git-crypt ...
    git config git-crypt.gpgcmd `which gpg2`

.git-crypt/.gitattributes file should set binary status

Of course when I try to reproduce this, it isn't possible, but in two repositories I have used with git-crypt, when I use git show to display one of the commits created automatically by the git-crypt add-gpg-user ... command, it show garbage text diffs for the .gpg file associated with that user. These are binary files, but as they are fairly short, there is a chance that they might contain enough plausible characters for Git to think they are some kind of 8-bit accented text.

This is a minor niggle (at least until somebody gets extremely unlucky on a Windows system and Git thinks a file is CRLF text and converts that to LF) but if the add-gpg-user command could make the content of the .git-crypt/.gitattributes file mark all GPG files within that directory as binary, it would eliminate even the remote possibility of this minor confusion.

FWIW, here is a transcript of the problem (and my local fix) in my repository; if you need to look at it in detail, I could push to a BitBucket private repo and share that with you.

$ git diff .git-crypt/.gitattributes
$ git show 2c331f3
commit 2c331f3c78259d557362e4585acff7260d8ed142
Author: Alexander Dupuy <[email protected]>
Date:   Tue May 12 14:08:38 2015 +0200

    Add 1 git-crypt collaborator

    New collaborators:

        82A69645 Alexander Dupuy <[email protected]>

diff --git a/.git-crypt/keys/default/0/083382BAC0059BE3D6544C8B0DCF16F482A69645.
new file mode 100644
index 0000000..9d98379
--- /dev/null
+++ b/.git-crypt/keys/default/0/083382BAC0059BE3D6544C8B0DCF16F482A69645.gpg
@@ -0,0 +1,4 @@
+<85>^B^L^C<BB><EF><B5>^<85>_<9E>q^A^O<FE>-<8A>}^Rb<97>KHLOb<C0>^Z<E0>u<C1><97>T
+<8D><81><BC><CB>W'UF<8A>Y_<BB><A5>!^X<CC><EC>an<B0>T<D6><EA>^Y<F8>B<F5>`A<8D>@
+<BA>D<BE>ۤ<D7>X<D6>ȵ|o<C1>^N}<A8>}}yH<CF>︇>^MN_X<D1>=Q4<97><CC>dʱ7E]ʰ<EC>Ԃ^R<88>
+<CD>ru#<U+063D>"Q<F7><F4>ژ<FA><D0>H<D4><CF><D6>0te<FF><D2>w<F3><97><E6><C6><ED>
\ No newline at end of file
$ echo '*.gpg binary' >> .git-crypt/.gitattributes
$ git show 2c331f3commit 2c331f3c78259d557362e4585acff7260d8ed142
Author: Alexander Dupuy <[email protected]>
Date:   Tue May 12 14:08:38 2015 +0200

    Add 1 git-crypt collaborator

    New collaborators:

        82A69645 Alexander Dupuy <[email protected]>

diff --git a/.git-crypt/keys/default/0/083382BAC0059BE3D6544C8B0DCF16F482A69645.
new file mode 100644
index 0000000..9d98379
Binary files /dev/null and b/.git-crypt/keys/default/0/083382BAC0059BE3D6544C8B0

Windows: git unlock using migrated key hangs

I'm using the binary you provided here.

I had a repo with git-crypt initialized already. git-crypt unlock key suggested me to migrate the key, which I did w/ git-crypt migrate-key. git-crypt unlock new-key hangs silently. I'd waited for about 3 minutes before shutting it down.

The output in Process Monitor looks like git-crypt is stuck in loop, polling some system folders which I don't think it supposed to be polling. I could email you the full log, if it helps.

git-crypt smudge failed

After running git-crypt init ~/my.key I've got following error for every file I listed in .gitattributes:

File not encrypted
error: external filter "git-crypt" smudge "/home/chuwy/my.key" failed 1
error: external filter "git-crypt" smudge "/home/chuwy/my.key" failed

I'm using git version 1.8.4.rc3 from Debian backports.

use of sub keys causes problems with git-crypt add-gpg-user

With a key fingerprint list like the following:

uid:-::::1380542123::483DC941B99712E796FEB92806DB709EF656D817::Adam Langley <[email protected]>:
sub:-:4096:1:F5ED32359DF91734:1380542123:1538222123:::::a:
fpr:::::::::8DD5BE5596D69B9858AEBEB3F5ED32359DF91734:
sub:e:4096:1:B91FE4A53C9B219E:1380839607:1412375607:::::e:
fpr:::::::::D6605535A1B8BF9C72ABAB7EB91FE4A53C9B219E:
pub:-:4096:1:8E274100D395EB04:1408454497:1723814497::-:::scaESCA:
fpr:::::::::33C4CC1525CB0B47AD03CE278E274100D395EB04:

the multiple fpr lines for the sub keys cause git-crypt add-gpg-user to fail with "Error: more than one public key matches 'B91FE4A53C9B219E' - please be more specific"

The (sub)key with 'e' (encrypt) capability should be selected.

.gitattributes pattern of `dirname/*` or `dirname/` does not encrypt contents

Any sub-directories within dirname/ e.g. dirname/subdirname/secrets.txt will insulate the contents of that sudir from encryption. A directory tree must be specified fully/explicitly in the .gitattributes pattern, to the lowest level, to ensure encryption. This can lead to plain-text being unintentionally pushed. A git-crypt status command seems critical for positively identifying files to be encrypted and catch pattern typos or syntax misunderstandings in .gitattributes.

Merge and Rebase with remote repo fail

When a encrypted file is changed in a remote repo, I am facing issues with merge and rebase.

Merge

With merge, the issue happens when there is a conflict in a secret file between my repo and a remote repo.
The merge itself succeeds with showing there is a conflict in the secret file.
But I can't see the diffs in the file.
The lines like "<<<<<<< HEAD" are supposed to be in the file.

I did this with commands below.
In this situation, I am in a branch "feature/a" with changes in a secret file.
And "origin/master" also has a change in the secret file

$ git fetch
$ git pull origin master

If there is a change in a secret file in the remote repo but no conflict with my local repo, it succeeds :)

Rebase

Whether there is a conflict or not, if there is a change in a secret file in a remote repo, rebase always fails as follows.

This is a same situation as the merge above.
I did this with commands below.

$ git fetch
$ git rebase origin/master

The rebase seems to succeed but I am getting messages below.

File not encrypted
error: external filter "git-crypt" smudge "key name here" failed 1
error: external filter "git-crypt" smudge "key name here" failed

This message is shown for each secret file that were changed.
Then if I do "git status", it shows the secret file is modified.
But once I got the messages above, I can't do "git stash" or "git reset".
The secret file keeps failing to encrypt and there is no way to turn the file back to encrypted one without just remove the file from the repo and add this again.

Thanks

initial unlock not decrypting under Git 2.2.2 and higher

Context: we're using git-crypt in a team environment, with keys manually shared via PGP (predates the automatic PGP support in git-crypt), and things have been working well.

A colleague tried to unlock a fresh clone and did not end up with decrypted files. I've tracked down resolution to rm -rf areas-which-are-encrypted followed by git checkout areas-which-are-encrypted.

This is with git 2.2.2 and git-crypt 0.4.1 on MacOSX.

It looks as though after an unlock, the initial pass to smudge the encrypted files is failing to do so; what I've seen so far, including reviewing recent git-crypt commits, leads me to suspect a regression in git rather than git-crypt, but I lack the knowledge of git internals and filters to debug this bad interaction sufficiently to file a report upstream, and figure you don't want your users filing error-filled interaction reports on the main lists and causing other git developers to hate on git-crypt, so am filing this report here with you, for further investigation and hopefully filing a more clue-filled report/patch with upstream git.

Improve usability/documentation with untrusted GPG keys

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?

Error messages doen't explain what's actually going on

I'm using the revamp branch to test some GPG encryption stuff to make sure it's ready for production. Setting up a clean repo from scratch went alright but upgrading an old one is giving me conniptions. It turns out some of my confusion was just based on weak error messages.

My first attempt had issues with the git attributes file so it got committed in plain text. After that got straightened out, git-crypt prompted me to commit an encrypted version instead. I obeyed the prompt and it appeared to work. The trouble is that since the smudge filter couldn't compare encrypted and non-encrypted versions of the file it is giving a cryptic error message saying the file is not encrypted:

❯❯❯ git show HEAD
commit 1a7005a
Author: Caleb Maclennan <[email protected]>
Date:   Wed Aug 6 15:02:41 2014 +0300

    add encrypted version of test file

git-crypt: error: file not encrypted
error: external filter "/usr/bin/git-crypt" smudge failed 1
error: external filter "/usr/bin/git-crypt" smudge failed

That's great, but the HEAD version of the file is an encrypted object in git. The error message really needs to say that the previous version was not encrypted and therefor it cannot be diffed (or just work out the smudge routine to pass through plain text data with a warning that there is non-encrypted data in the repo).

git-crypt used along side Atlassian SourceTree reliably breaks

It's pretty easy to reproduce, in a repo that's using git-crypt, use sourcetree to rebase, then watch as none of encrypted files remain so.

Probably more so a problem with sourcetree, thought it wouldn't be a bad idea to bring it up here, also.

Add command to see encrypted files

Hi,
I'm new user of git-crypt, and I really appreciate the git integration that you've made.

Right now, when I git add file.txt I'm not sure this file is encrypted.
I miss a command like git-crypt list-secured-files that could display secured file.

What do you think about it ? Maybe you have an other solution ?

Regards,
Thomas.

Add `edit` command for more security.

Since some third-party GUIs don't play well with the filters, some users have them disabled, and rely on lock/unlock to work with encrypted files. This, however, is error-prone, since it's likely that one will forget to re-encrypt the file again after they're done editing.

I propose a git-crypt edit <filename> command that would decrypt a temporary copy of the file to /tmp/, launch $EDITOR to edit it, and then re-encrypt it back to its original location, with a single command (similar to how ansible-vault does it). This would ensure that users would not forget to re-encrypt their files.

git-crypt and submodules

It looks like git-crypt does not behave well when there are submodules.
Maybe there is a way to prevent this problem by adding some lines in .gitattributes but here is a way to reproduce the problem:

~$ git --version
git version 2.1.4

~$ git-crypt --version
git-crypt 0.4.2

~$ mkdir repo_wsm

~$ cd repo_wsm/

~/repo_wsm$ git init
Initialized empty Git repository in /home/ggueguen/tmp/repo_wsm/.git/

~/repo_wsm$ git-crypt init
Generating key...

~/repo_wsm$ cat - << EOF > .gitattributes
> * filter=git-crypt diff=git-crypt
> .gitattributes !filter !diff
> EOF

~/repo_wsm$ git-crypt status
not encrypted: .gitattributes

~/repo_wsm$ git submodule add https://github.com/AGWA/git-crypt.git
Cloning into 'git-crypt'...
remote: Counting objects: 618, done.
remote: Total 618 (delta 0), reused 0 (delta 0), pack-reused 618
Receiving objects: 100% (618/618), 207.50 KiB | 0 bytes/s, done.
Resolving deltas: 100% (389/389), done.
Checking connectivity... done.

~/repo_wsm$ git-crypt status
not encrypted: .gitattributes
    encrypted: .gitmodules
fatal: git cat-file ede1461563709498d397d8230d233c3d9a25880e: bad file
git-crypt: Error: 'git cat-file' failed - is this a Git repository?

File modes not preserved

Files with 600 permission are being committed to the repo with 644 permission.

Have tried changing the permission to both encrypted and decrypted files to no avail.

Repository is not decrypted upon `git-crypt init key`

When I initially clone an already git-crypted repo, it is encrypted as expected:

ntalbott@joshua:~/tmp$ git clone [email protected]:ntalbott/top-secret.git && cd top-secret/
Cloning into 'top-secret'...
remote: Counting objects: 28, done.
remote: Compressing objects: 100% (21/21), done.
remote: Total 28 (delta 5), reused 22 (delta 2)
Receiving objects: 100% (28/28), done.
Resolving deltas: 100% (5/5), done.

ntalbott@joshua:~/tmp/top-secret$ cat README.md
GITCRYPT?vc{��¬Ú�+ÜµÙ-�?"Ëdñ\Á¥í¥ÅuD�¯hGéË±

However, even after initing the repo with the correct key, things are still encrypted:

ntalbott@joshua:~/tmp/top-secret$ git-crypt init ~/tmp/top-secret.key
HEAD is now at e2b9465 Moar sekrets

ntalbott@joshua:~/tmp/top-secret$ cat README.md
GITCRYPT?vc{��¬Ú�+ÜµÙ-�?"Ëdñ\Á¥í¥ÅuD�¯hGéË±

It's not until I force a re-checkout of the repo that things get decrypted:

ntalbott@joshua:~/tmp/top-secret$ git co -f master .

ntalbott@joshua:~/tmp/top-secret$ cat README.md
top-secret
==========

I'm not sure if the decryption-upon-init is something that git-crypt can handle automatically, or if there should just be a section in the docs that covers what to do when cloning a pre-encrypted repo. Or maybe I'm just doing something stupid that's preventing the decryption happening?

automatic decryption on "git-crypt init" does not work

Hello,

It seems that the automatic decryption for newly checked out repositories is broken. I give an example session, illustrating the problem, below.

My system:

current version of git-crypt compiled from source
(commit 9f20b87)
the git version included with up-to-date Ubuntu
(package version 1:1.8.1.2-1)

To illustrate the problem:

clone a repository with an encrypted file:

voss@automatix [~] git clone test.repo test2
Cloning into 'test2'...
done.
voss@automatix [~] cd test2/
voss@automatix [~/test2] grep GITCRYPT b && echo "file is encrypted"
Binary file b matches
file is encrypted

call "git-crypt init" with the correct key; note that the file "b" stays encrypted:

voss@automatix [~/test2] git-crypt init ~/.git-crypt 
voss@automatix [~/test2] grep GITCRYPT b && echo "file is encrypted"
Binary file b matches
file is encrypted

try to manually call "git checkout":

voss@automatix [~/test2] git checkout -f HEAD -- .
voss@automatix [~/test2] grep GITCRYPT b && echo "file is encrypted"
Binary file b matches
file is encrypted

some failed attempts to get the decrypted version:

voss@automatix [~/test2] grep GITCRYPT b && echo "file is encrypted"
Binary file b matches
file is encrypted
voss@automatix [~/test2] rm b
voss@automatix [~/test2] git checkout b
voss@automatix [~/test2] grep GITCRYPT b && echo "file is encrypted"
Binary file b matches
file is encrypted

the only way I found to get the correct version:

voss@automatix [~/test2] git checkout HEAD^
[...boring note omitted...]
HEAD is now at 066c807... update c
voss@automatix [~/test2] git checkout HEAD
voss@automatix [~/test2] grep GITCRYPT b && echo "file is encrypted"
voss@automatix [~/test2] cat b
Tue Aug  6 19:19:46 BST 2013

I hope this report is helpful. If there is anything I should try, or if I can help in any other way, please let me know.

Many thanks,
Jochen

Consider making `smudge` a public sub-command

Is it possible to use git-show to see encrypted files?

I tried doing so to obtain the old version of a file, but it outputs the encrypted file.

Windows support

I encountered some compilation errors with the latest "windows" branch from unreleased git-crypt v0.4.
It happens when I updated my forked repo with commit 19ea278 (2014-06-03).

So I've made some changes and it now compiles fine on Windows:

commit 164e0a9:
- got the content of your repo as of 2014-06-03 (overwritten my files)
- repository reorganisation (no source change, juste moved to 'src' directory)
commit 3c1a305:
- corrected in order to compile using mingw32

Can you merge changes to the upstream repo please?
Thanks a lot.

'git-crypt status' with the '-f' option to stage an encrypted version fails for me?

git-crypt status tells me about some "staged/comited" files that are NOT encrypted, but should be.

And then tells me to run "Run 'git-crypt status' with the '-f' option to stage an encrypted version."

not encrypted: .git-crypt/.gitattributes
not encrypted: .gitattributes
not encrypted: .gitignore

<cut some lines>

not encrypted: etc/config/uhttpd
    encrypted: etc/config/wireless *** WARNING: staged/committed version is NOT ENCRYPTED! ***
not encrypted: etc/dnsmasq.conf
    encrypted: etc/dropbear/dropbear_dss_host_key *** WARNING: staged/committed version is NOT ENCRYPTED! ***
    encrypted: etc/dropbear/dropbear_rsa_host_key *** WARNING: staged/committed version is NOT ENCRYPTED! ***
not encrypted: etc/firewall.user

<cut some lines>

    encrypted: etc/shadow *** WARNING: staged/committed version is NOT ENCRYPTED! ***
not encrypted: etc/shells
not encrypted: etc/sysctl.conf
not encrypted: etc/sysupgrade.conf
    encrypted: etc/uhttpd.crt *** WARNING: staged/committed version is NOT ENCRYPTED! ***
    encrypted: etc/uhttpd.key *** WARNING: staged/committed version is NOT ENCRYPTED! ***

Warning: one or more files is marked for encryption via .gitattributes but
was staged and/or committed before the .gitattributes file was in effect.
Run 'git-crypt status' with the '-f' option to stage an encrypted version.

git-crypt status -f

it returns with:

Error: etc/config/wireless: still unencrypted even after staging
Error: etc/dropbear/dropbear_dss_host_key: still unencrypted even after staging
Error: etc/dropbear/dropbear_rsa_host_key: still unencrypted even after staging
Error: etc/shadow: still unencrypted even after staging
Error: etc/uhttpd.crt: still unencrypted even after staging
Error: etc/uhttpd.key: still unencrypted even after staging
Unable to stage 6 files.

What now? How do I fix this?

it still could unlock or lock while the GPG key revoked.

it still could unlock or lock while the GPG key revoked, I think it would be better do not lock/unlock while GPG key ware revoked.