GNU bug report logs - #79050
vc-git incorrectly treats git-crypt encrypted files as binary, even when unlocked

Previous Next

To reply to this bug, email your comments to 79050 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: James Cherti <contact <at> jamescherti.com>
To: bug-gnu-emacs <at> gnu.org
Subject: vc-git incorrectly treats git-crypt encrypted files as binary, even
 when unlocked
Date: Sat, 19 Jul 2025 13:59:40 -0400

When using vc-diff in a Git repository where all files are
encrypted with git-crypt https://github.com/AGWA/git-crypt
the output does not reflect actual changes. Modified files
appear unaltered, regardless of edits made. (vc-diff appears
to compare the encrypted binary representations of the files,
rather than their decrypted contents.)

It appears that vc-diff does not take .gitattributes into
account, even though Git itself uses it to determine how to
handle diff filters. As a result, while git diff correctly
shows textual diffs for git-crypt encrypted files (once the
repository is unlocked), Emacs vc-diff treats them as binary
and fails to display the actual changes.

Instead of showing a textual diff, vc-diff reports:
  diff --git a/file b/file
  index a134576..8b24729 100644
  Binary files a/file and b/file differ

Steps to Reproduce:
-------------------
1. Initialize a Git repository and enable git-crypt.
     Create the repo:
     ----------------
     mkdir -p repo
     cd repo
     git init
     git-crypt init
     echo test > README.md

     Create the .gitattributes file:
     -------------------------------
     ** filter=git-crypt diff=git-crypt
     .gitattributes !filter !diff

     Commit:
     -------
     git add .
     git commit -m 'Init'
2. Open the README.md file in Emacs and modify it.
3. Run: M-x vc-diff

Expected Behavior
-----------------
vc-diff should display a textual diff showing the modified lines.

Actual Behavior
---------------
vc-diff reports the file as a binary difference with no
line-level changes, even though the repository is unlocked
and git diff in the terminal shows the correct diff.

Environment:
------------
- Emacs version: 31 (3b2bfdfef63f051a36f4043c32596458ccae605f)
                 2025-07-19 13:05:05 +0300
- OS: Arch Linux

--
James Cherti
GitHub: https://github.com/jamescherti
Website: https://www.jamescherti.com/

Message #8 received at 79050 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: James Cherti <contact <at> jamescherti.com>
Cc: 79050 <at> debbugs.gnu.org
Subject: Re: bug#79050: vc-git incorrectly treats git-crypt encrypted files
 as binary, even when unlocked
Date: Sun, 20 Jul 2025 11:45:32 +0100

Hello James,

Is this enough to fix it?

--8<---------------cut here---------------start------------->8---
diff --git a/lisp/vc/vc-git.el b/lisp/vc/vc-git.el
index f462fb1959f..9d351797bef 100644
--- a/lisp/vc/vc-git.el
+++ b/lisp/vc/vc-git.el
@@ -1829,7 +1829,7 @@ vc-git-diff
                (if async 'async 1)
                files
                command
-               "--exit-code"
+               "--exit-code" "--textconv"
                (append (vc-switches 'git 'diff)
                        (list "-p" (or rev1 "HEAD") rev2 "--")))
       (vc-git-command (or buffer "*vc-diff*") 1 files
--8<---------------cut here---------------end--------------->8---

-- 
Sean Whitton

Message #11 received at 79050 <at> debbugs.gnu.org (full text, mbox):

From: James Cherti <contact <at> jamescherti.com>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 79050 <at> debbugs.gnu.org
Subject: Re: bug#79050: vc-git incorrectly treats git-crypt encrypted files as
 binary, even when unlocked
Date: Sun, 20 Jul 2025 14:28:20 -0400

Hello Sean,

Yes, adding `--textconv` resolves the issue.

--
James Cherti
GitHub: https://github.com/jamescherti
Website: https://www.jamescherti.com/

On 2025-07-20 06:45, Sean Whitton wrote:
> Hello James,
> 
> Is this enough to fix it?
> 
> --8<---------------cut here---------------start------------->8---
> diff --git a/lisp/vc/vc-git.el b/lisp/vc/vc-git.el
> index f462fb1959f..9d351797bef 100644
> --- a/lisp/vc/vc-git.el
> +++ b/lisp/vc/vc-git.el
> @@ -1829,7 +1829,7 @@ vc-git-diff
>                  (if async 'async 1)
>                  files
>                  command
> -               "--exit-code"
> +               "--exit-code" "--textconv"
>                  (append (vc-switches 'git 'diff)
>                          (list "-p" (or rev1 "HEAD") rev2 "--")))
>         (vc-git-command (or buffer "*vc-diff*") 1 files
> --8<---------------cut here---------------end--------------->8---
> 

Message #16 received at 79050-done <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: James Cherti <contact <at> jamescherti.com>
Cc: 79050-done <at> debbugs.gnu.org
Subject: Re: bug#79050: vc-git incorrectly treats git-crypt encrypted files
 as binary, even when unlocked
Date: Mon, 21 Jul 2025 09:27:14 +0100

Version: 31.1

Hello,

On Sun 20 Jul 2025 at 02:28pm -04, James Cherti wrote:

> Hello Sean,
>
> Yes, adding `--textconv` resolves the issue.

Thanks for testing.  Installed that change, and closing the bug.

-- 
Sean Whitton

Message #19 received at 79050 <at> debbugs.gnu.org (full text, mbox):

From: James Cherti <contact <at> jamescherti.com>
To: 79050 <at> debbugs.gnu.org, spwhitton <at> spwhitton.name
Subject: Re: bug#79050: vc-git incorrectly treats git-crypt encrypted files as
 binary, even when unlocked
Date: Mon, 21 Jul 2025 11:36:59 -0400

Thank you for resolving this issue promptly, Sean.

I have tested your fix, and it functions as expected.

--
James Cherti
GitHub: https://github.com/jamescherti
Website: https://www.jamescherti.com/

On 2025-07-21 04:27, Sean Whitton wrote:
> Version: 31.1
> 
> Hello,
> 
> On Sun 20 Jul 2025 at 02:28pm -04, James Cherti wrote:
> 
>> Hello Sean,
>>
>> Yes, adding `--textconv` resolves the issue.
> 
> Thanks for testing.  Installed that change, and closing the bug.
> 

Message #22 received at 79050 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 79050 <at> debbugs.gnu.org, James Cherti <contact <at> jamescherti.com>
Subject: Re: bug#79050: vc-git incorrectly treats git-crypt encrypted files
 as binary, even when unlocked
Date: Tue, 22 Jul 2025 09:45:09 +0300

> Is this enough to fix it?
>
> @@ -1829,7 +1829,7 @@ vc-git-diff
>                 (if async 'async 1)
>                 files
>                 command
> -               "--exit-code"
> +               "--exit-code" "--textconv"

Thanks for adding "--textconv".  Before this change I used

  (with-eval-after-load 'vc-git
    (add-to-list 'vc-git-diff-switches "--textconv" t))

that worked on `git diff` but failed on `git diff-index` with

  (error "Failed (status 128): git diff-index --textconv -p 1234567890  -- .")

But maybe this was in an old git version since it's not reproducible now.

Also I remember a minor inconvenience that "--textconv" makes `git diff`
too slow on encrypted files.  Most of the time there is no need
to see decrypted text in diff output.  So I prefered to add "--textconv"
only occasionally: mostly to verify the encrypted content before committing
changes, but not when viewing logs with diff.

Would it be possible to enable this optionally?
Maybe a simple variable would suffice.

Message #25 received at 79050 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Juri Linkov <juri <at> linkov.net>
Cc: control <at> debbugs.gnu.org, 79050 <at> debbugs.gnu.org,
 James Cherti <contact <at> jamescherti.com>
Subject: Re: bug#79050: vc-git incorrectly treats git-crypt encrypted files
 as binary, even when unlocked
Date: Tue, 22 Jul 2025 11:36:20 +0100

tag 79050 + notabug
notfixed 79050 31.1
thanks

Hello,

On Tue 22 Jul 2025 at 09:45am +03, Juri Linkov wrote:

> Also I remember a minor inconvenience that "--textconv" makes `git diff`
> too slow on encrypted files.  Most of the time there is no need
> to see decrypted text in diff output.  So I prefered to add "--textconv"
> only occasionally: mostly to verify the encrypted content before committing
> changes, but not when viewing logs with diff.

Interesting.

> Would it be possible to enable this optionally?
> Maybe a simple variable would suffice.

Another problem is that you can't commit changes from *vc-diff* buffers
with --textconv, and if you try to do so anyway, it might break things
in your repository, without you realising.

Therefore I think that users should have to add this to
vc-git-diff-switches themselves if they want this.  I'll revert the
change.

-- 
Sean Whitton

Message #32 received at 79050 <at> debbugs.gnu.org (full text, mbox):

From: James Cherti <contact <at> jamescherti.com>
To: Sean Whitton <spwhitton <at> spwhitton.name>, Juri Linkov <juri <at> linkov.net>
Cc: control <at> debbugs.gnu.org, 79050 <at> debbugs.gnu.org
Subject: Re: bug#79050: vc-git incorrectly treats git-crypt encrypted files as
 binary, even when unlocked
Date: Tue, 22 Jul 2025 09:27:03 -0400

On 2025-07-22 06:36, Sean Whitton wrote:
> tag 79050 + notabug
> notfixed 79050 31.1
> thanks
> 
> Hello,
> 
> On Tue 22 Jul 2025 at 09:45am +03, Juri Linkov wrote:
> 
>> Also I remember a minor inconvenience that "--textconv" makes `git diff`
>> too slow on encrypted files.  Most of the time there is no need
>> to see decrypted text in diff output.  So I prefered to add "--textconv"
>> only occasionally: mostly to verify the encrypted content before committing
>> changes, but not when viewing logs with diff.
> 
> Interesting.

That's a fair point, but I would argue that the default
behavior should favor clarity and discoverability,
especially for users who aren't already aware of the
interaction between git-crypt and --textconv.

While --textconv may introduce some overhead when decrypting
large files during git diff, the benefit of getting
intelligible output, rather than opaque binary diffs, is
significant in most real-world workflows. Users encountering
unreadable diffs are unlikely to immediately suspect the
absence of --textconv; they're more likely to assume
something is broken in Emacs or in a package they are using
(e.g., diff-hl).

>> Would it be possible to enable this optionally?
>> Maybe a simple variable would suffice.

This is a much better alternative than simply reverting the
change.

> Another problem is that you can't commit changes from *vc-diff* buffers
> with --textconv, and if you try to do so anyway, it might break things
> in your repository, without you realising.

Out of curiosity, how can I reproduce the issue that occurs
when committing from a vc-diff buffer with --textconv?

> Therefore I think that users should have to add this to
> vc-git-diff-switches themselves if they want this.  I'll revert the
> change.

If the change is simply reverted, some users may not
discover that their issue can be addressed by using the
--textconv option.

Providing this behavior as an optional, user-configurable
variable would make its existence visible through the
docstring. This could help reduce confusion and the time
users spend investigating why vc-diff appears broken or
why tools like diff-hl fail to work correctly in
repositories that use git-crypt:
https://github.com/dgutov/diff-hl/issues/244#issuecomment-3102297241

--
James Cherti
GitHub: https://github.com/jamescherti
Website: https://www.jamescherti.com/

Message #35 received at 79050 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: James Cherti <contact <at> jamescherti.com>
Cc: 79050 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#79050: vc-git incorrectly treats git-crypt encrypted files
 as binary, even when unlocked
Date: Tue, 22 Jul 2025 20:37:25 +0100

Hello,

On Tue 22 Jul 2025 at 09:27am -04, James Cherti wrote:

>> Another problem is that you can't commit changes from *vc-diff* buffers
>> with --textconv, and if you try to do so anyway, it might break things
>> in your repository, without you realising.
>
> Out of curiosity, how can I reproduce the issue that occurs
> when committing from a vc-diff buffer with --textconv?

I believe that if you try to use C-x v v in a diff buffer that's
textconv'd, it'll try to apply the plain text diff to the binary file.

>> Therefore I think that users should have to add this to
>> vc-git-diff-switches themselves if they want this.  I'll revert the
>> change.
>
> If the change is simply reverted, some users may not
> discover that their issue can be addressed by using the
> --textconv option.
>
> Providing this behavior as an optional, user-configurable
> variable would make its existence visible through the
> docstring. This could help reduce confusion and the time
> users spend investigating why vc-diff appears broken or
> why tools like diff-hl fail to work correctly in
> repositories that use git-crypt:
> https://github.com/dgutov/diff-hl/issues/244#issuecomment-3102297241

The thing is, you could make an argument like this for all the other
optional arguments that git-diff{,-index} have.  One point of having
vc-git-diff-switches is to avoid having a separate Emacs option for each
individual optional argument.

-- 
Sean Whitton

Message #38 received at 79050 <at> debbugs.gnu.org (full text, mbox):

From: James Cherti <contact <at> jamescherti.com>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 79050 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#79050: vc-git incorrectly treats git-crypt encrypted files as
 binary, even when unlocked
Date: Tue, 22 Jul 2025 21:47:41 -0400

On 2025-07-22 15:37, Sean Whitton wrote:
> Hello,
> 
> On Tue 22 Jul 2025 at 09:27am -04, James Cherti wrote:
> 
>>> Another problem is that you can't commit changes from *vc-diff* buffers
>>> with --textconv, and if you try to do so anyway, it might break things
>>> in your repository, without you realising.
>>
>> Out of curiosity, how can I reproduce the issue that occurs
>> when committing from a vc-diff buffer with --textconv?
> 
> I believe that if you try to use C-x v v in a diff buffer that's
> textconv'd, it'll try to apply the plain text diff to the binary file.

Thanks for the explanation, Sean.

Just a quick note:
- with --textconv: I tried committing a git-crypt
  encrypted file using C-x v v after viewing its diff, and
  although the operation failed, it didn’t seem to cause any
  actual harm to the repository (with --textconv activated):
    vc-do-command: Failed (status 1): git --no-pager apply
    --cached /tmp/ git-patchncypZR .

- Without --textconv, using C-x v v has no effect, it simply
  displays "No next file" in the minibuffer and does not stage
  or commit the changes.

>>> Therefore I think that users should have to add this to
>>> vc-git-diff-switches themselves if they want this.  I'll revert the
>>> change.
>>
>> If the change is simply reverted, some users may not
>> discover that their issue can be addressed by using the
>> --textconv option.
>>
>> Providing this behavior as an optional, user-configurable
>> variable would make its existence visible through the
>> docstring. This could help reduce confusion and the time
>> users spend investigating why vc-diff appears broken or
>> why tools like diff-hl fail to work correctly in
>> repositories that use git-crypt:
>> https://github.com/dgutov/diff-hl/issues/244#issuecomment-3102297241
> 
> The thing is, you could make an argument like this for all the other
> optional arguments that git-diff{,-index} have.  One point of having
> vc-git-diff-switches is to avoid having a separate Emacs option for each
> individual optional argument.

That's a fair point, I agree that duplicating each Git diff
option into its own Emacs variable would be defeat the purpose
of vc-git-diff-switches.

At least this discussion now exists, so users facing similar
issues are more likely to come across it when searching for
solutions.

--
James Cherti
GitHub: https://github.com/jamescherti
Website: https://www.jamescherti.com/

Message #41 received at 79050 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: James Cherti <contact <at> jamescherti.com>
Cc: 79050 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#79050: vc-git incorrectly treats git-crypt encrypted files
 as binary, even when unlocked
Date: Thu, 24 Jul 2025 13:10:05 +0100

Hello,

On Tue 22 Jul 2025 at 09:47pm -04, James Cherti wrote:

> Just a quick note:
> - with --textconv: I tried committing a git-crypt
>   encrypted file using C-x v v after viewing its diff, and
>   although the operation failed, it didn’t seem to cause any
>   actual harm to the repository (with --textconv activated):
>     vc-do-command: Failed (status 1): git --no-pager apply
>     --cached /tmp/ git-patchncypZR .
>
> - Without --textconv, using C-x v v has no effect, it simply
>   displays "No next file" in the minibuffer and does not stage
>   or commit the changes.

I'm being cautious about this because I don't know the full range of
uses for textconv filters, and because after reading the manpages
regarding --textconv it does make it sound like there are textconv
filters where with --no-textconv you'd get a diff that could be applied
to files even if it is less human-readable.  That might not be true for
git-crypt(1), but that's just one case.

Would you happen to know about any other uses for textconv filters
besides git-crypt(1)?

-- 
Sean Whitton

Message #44 received at 79050 <at> debbugs.gnu.org (full text, mbox):

From: James Cherti <contact <at> jamescherti.com>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 79050 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#79050: vc-git incorrectly treats git-crypt encrypted files as
 binary, even when unlocked
Date: Thu, 24 Jul 2025 10:32:19 -0400

On 2025-07-24 08:10, Sean Whitton wrote:
> Hello,
> 
> On Tue 22 Jul 2025 at 09:47pm -04, James Cherti wrote:
> 
>> Just a quick note:
>> - with --textconv: I tried committing a git-crypt
>>    encrypted file using C-x v v after viewing its diff, and
>>    although the operation failed, it didn’t seem to cause any
>>    actual harm to the repository (with --textconv activated):
>>      vc-do-command: Failed (status 1): git --no-pager apply
>>      --cached /tmp/ git-patchncypZR .
>>
>> - Without --textconv, using C-x v v has no effect, it simply
>>    displays "No next file" in the minibuffer and does not stage
>>    or commit the changes.
> 
> I'm being cautious about this because I don't know the full range of
> uses for textconv filters, and because after reading the manpages
> regarding --textconv it does make it sound like there are textconv
> filters where with --no-textconv you'd get a diff that could be applied
> to files even if it is less human-readable.  That might not be true for
> git-crypt(1), but that's just one case.
> 
> Would you happen to know about any other uses for textconv filters
> besides git-crypt(1)?

I agree, Sean, it's reasonable to be cautious here and let
the user choose if they want to add --textconv to their
configuration.

--
James Cherti
GitHub: https://github.com/jamescherti
Website: https://www.jamescherti.com/

Message #47 received at 79050 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 79050 <at> debbugs.gnu.org, James Cherti <contact <at> jamescherti.com>
Subject: Re: bug#79050: vc-git incorrectly treats git-crypt encrypted files
 as binary, even when unlocked
Date: Thu, 24 Jul 2025 19:28:54 +0300

> Would you happen to know about any other uses for textconv filters
> besides git-crypt(1)?

I'm using textconv filters for Rails credentials.  The command
`rails credentials:diff --enroll` adds more lines to these files:

.gitattributes:
config/credentials/*.yml.enc diff=rails_credentials

.git/config:
[diff "rails_credentials"]
  textconv = rails credentials:show

The problem is that the textconv filter command
`rails credentials:show` is very very slow
that makes diff viewing experience too frustrating.

So I add the --textconv switch very rarely,
only when there is a real need to check the contents
of the encrypted files.

But I'm not opposed to adding this switch by default,
provided there is a way to remove it.

Message #50 received at 79050 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Juri Linkov <juri <at> linkov.net>
Cc: 79050 <at> debbugs.gnu.org, James Cherti <contact <at> jamescherti.com>
Subject: Re: bug#79050: vc-git incorrectly treats git-crypt encrypted files
 as binary, even when unlocked
Date: Thu, 24 Jul 2025 21:27:28 +0100

Hello,

On Thu 24 Jul 2025 at 07:28pm +03, Juri Linkov wrote:

>> Would you happen to know about any other uses for textconv filters
>> besides git-crypt(1)?
>
> I'm using textconv filters for Rails credentials.  The command
> `rails credentials:diff --enroll` adds more lines to these files:
>
> .gitattributes:
> config/credentials/*.yml.enc diff=rails_credentials
>
> .git/config:
> [diff "rails_credentials"]
>   textconv = rails credentials:show
>
> The problem is that the textconv filter command
> `rails credentials:show` is very very slow
> that makes diff viewing experience too frustrating.
>
> So I add the --textconv switch very rarely,
> only when there is a real need to check the contents
> of the encrypted files.
>
> But I'm not opposed to adding this switch by default,
> provided there is a way to remove it.

Thanks.  One option, btw, is to add it to the default value for
vc-git-diff-switches.  But for now I think we should probably leave it
out.

-- 
Sean Whitton

Message #53 received at 79050 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: James Cherti <contact <at> jamescherti.com>
Cc: 79050 <at> debbugs.gnu.org
Subject: Re: bug#79050: vc-git incorrectly treats git-crypt encrypted files as
 binary, even when unlocked
Date: Mon, 28 Jul 2025 22:24:11 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > When using vc-diff in a Git repository where all files are
  > encrypted with git-crypt https://github.com/AGWA/git-crypt
  > the output does not reflect actual changes.

What is the use case of git-crypt?  Why put code in a public repo
and make it impossible for the public to see?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Message #56 received at 79050 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Richard Stallman <rms <at> gnu.org>
Cc: 79050 <at> debbugs.gnu.org, James Cherti <contact <at> jamescherti.com>
Subject: Re: bug#79050: vc-git incorrectly treats git-crypt encrypted files
 as binary, even when unlocked
Date: Tue, 29 Jul 2025 09:14:51 +0100

Hello,

On Mon 28 Jul 2025 at 10:24pm -04, Richard Stallman wrote:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > When using vc-diff in a Git repository where all files are
>   > encrypted with git-crypt https://github.com/AGWA/git-crypt
>   > the output does not reflect actual changes.
>
> What is the use case of git-crypt?  Why put code in a public repo
> and make it impossible for the public to see?

I maintain something similar: git-remote-gcrypt[1]

In short, Git repos don't have to be public.
I keep everything in Git, in many private repositories.

[1]  https://spwhitton.name/tech/code/git-remote-gcrypt/

-- 
Sean Whitton

Message #59 received at 79050 <at> debbugs.gnu.org (full text, mbox):

From: James Cherti <contact <at> jamescherti.com>
To: Sean Whitton <spwhitton <at> spwhitton.name>, Richard Stallman <rms <at> gnu.org>
Cc: 79050 <at> debbugs.gnu.org
Subject: Re: bug#79050: vc-git incorrectly treats git-crypt encrypted files as
 binary, even when unlocked
Date: Tue, 29 Jul 2025 11:17:10 -0400

On 2025-07-29 04:14, Sean Whitton wrote:
> Hello,
> 
> On Mon 28 Jul 2025 at 10:24pm -04, Richard Stallman wrote:
> 
>> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>> [[[ whether defending the US Constitution against all enemies,     ]]]
>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>
>>    > When using vc-diff in a Git repository where all files are
>>    > encrypted with git-crypt https://github.com/AGWA/git-crypt
>>    > the output does not reflect actual changes.
>>
>> What is the use case of git-crypt?  Why put code in a public repo
>> and make it impossible for the public to see?
> 
> I maintain something similar: git-remote-gcrypt[1]
> 
> In short, Git repos don't have to be public.
> I keep everything in Git, in many private repositories.
> 
> [1]  https://spwhitton.name/tech/code/git-remote-gcrypt/

Hello Sean and Richard,

The git-remote-gcrypt tool sounds interesting.
I'll take a closer look at it.

Tools such as git-crypt are relevant for:
- Infrastructure-as-code repositories containing secrets
  (e.g., sensitive credentials or API keys in configuration
  files).
- Personal knowledge bases, journals, internal
  research, etc.
- Prototypes not intended for public distribution.
- And many other similar scenarios.

In such contexts, placing code or data in an internal or
a semi-public Git repository (e.g., hosted on a private
GitLab/GitHub instance, corporate Git server, or a
self-hosted server) does not imply that its contents should
be readable by everyone. The goal is availability,
traceability, and collaboration, not necessarily universal
readability.

From a security standpoint, this is not merely about privacy
but about reducing risk. Repositories, even private ones,
may be exposed through misconfigurations, insider threats,
or breaches. If data is encrypted using tools like git-crypt,
then even if an unauthorized party gains access to the
repository, the sensitive content remains protected.

It is important to note that git-crypt only encrypts file
contents, it does not encrypt file names or commit metadata.

--
James Cherti
GitHub: https://github.com/jamescherti
Website: https://www.jamescherti.com/

Message #62 received at 79050 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 79050 <at> debbugs.gnu.org, contact <at> jamescherti.com
Subject: Re: bug#79050: vc-git incorrectly treats git-crypt encrypted files as
 binary, even when unlocked
Date: Fri, 01 Aug 2025 22:46:37 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > What is the use case of git-crypt?  Why put code in a public repo
  > > and make it impossible for the public to see?

  > I maintain something similar: git-remote-gcrypt[1]

  > In short, Git repos don't have to be public.
  > I keep everything in Git, in many private repositories.

I don't follow the reasoning of this.  If a repo is private,
why encrupt its contents?  Some files on my disk are private too,
but I mostly don't encrypt them.

Is there a point that isn't clear to me?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Message #65 received at 79050 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Richard Stallman <rms <at> gnu.org>
Cc: 79050 <at> debbugs.gnu.org, contact <at> jamescherti.com
Subject: Re: bug#79050: vc-git incorrectly treats git-crypt encrypted files
 as binary, even when unlocked
Date: Sun, 03 Aug 2025 13:53:19 +0100

Hello,

On Fri 01 Aug 2025 at 10:46pm -04, Richard Stallman wrote:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > > What is the use case of git-crypt?  Why put code in a public repo
>   > > and make it impossible for the public to see?
>
>   > I maintain something similar: git-remote-gcrypt[1]
>
>   > In short, Git repos don't have to be public.
>   > I keep everything in Git, in many private repositories.
>
> I don't follow the reasoning of this.  If a repo is private,
> why encrupt its contents?  Some files on my disk are private too,
> but I mostly don't encrypt them.
>
> Is there a point that isn't clear to me?

So you can push to a remote server you don't fully control.

-- 
Sean Whitton

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.