[bug] encryption of metadata in .git metadata file inside .git folder

[bug] encryption of metadata in .git metadata file inside .git folder

[Krishnamurthy Ganesh B]

hello,

greetings.

i am raising a git security red flag on the.git metadata files storing
git logs, commits, and other metadata inside .git folder not encrypted
using a two way salt or some other way like using a key for a two way
encryption or some method of software encryption internally if /
because the .git folder metadata is not encrypted.

this has been raised to github before but will be raised again via
hackerone security bug and to gitlab and altassian and other git
repository source users if they are using their own internal modified
sources.

most of the errors like these will be directly closed.

https://kondukto.io/blog/git-scm-affected-by-cve-2024-32002

https://socradar.io/critical-security-updates-for-git-scm-cve-2024-32002-cve-2024-32004-lead-to-rce/

https://stackoverflow.com/questions/45578579/what-file-metadata-is-preserved-by-git

even packages like git-crypt do not encrypt metadata.
https://github.com/AGWA/git-crypt

have a nice day.

regards,
ganesh k

RE: [bug] encryption of metadata in .git metadata file inside .git folder

[rsbecker]

On December 23, 2024 7:04 AM, Krishnamurthy Ganesh B wrote:
>i am raising a git security red flag on the.git metadata files storing git logs, commits,
>and other metadata inside .git folder not encrypted using a two way salt or some
>other way like using a key for a two way encryption or some method of software
>encryption internally if / because the .git folder metadata is not encrypted.
>
>this has been raised to github before but will be raised again via hackerone security
>bug and to gitlab and altassian and other git repository source users if they are
>using their own internal modified sources.
>
>most of the errors like these will be directly closed.
>
>https://kondukto.io/blog/git-scm-affected-by-cve-2024-32002
>
>https://socradar.io/critical-security-updates-for-git-scm-cve-2024-32002-cve-
>2024-32004-lead-to-rce/
>
>https://stackoverflow.com/questions/45578579/what-file-metadata-is-
>preserved-by-git
>
>even packages like git-crypt do not encrypt metadata.
>https://github.com/AGWA/git-crypt

Have you explored using disk-level encryption to solve this?  While I understand your
objective to "encrypt anything that might have data in it", there are solutions
independent of git what would cover most use cases. The problem with adding
symmetrical encryption to git is that it opens git up to export limitations and
related CVEs. It would also cause adoption issues with many organizations
who may have restrictions on whatever techniques git adopts to solve this.
My preferential solution is using COTS hardware encryption to solve protecting
data-at-rest content.

--Randall

Re: [bug] encryption of metadata in .git metadata file inside .git folder

[Krishnamurthy Ganesh B]

hello,

[apologies, not sure why my emails are bouncing due to the html
version even when sent as text].

@randall (i am sure we may have interacted before or probably same
name someone else): my answers for your quote below:

- disk encryption has nothing to do with .git storage. local access by
access provided users will always be there.
- disk encryption solves the challenge of modification access in the
server by devops professionals not manipulation intent
- disk encryption solves the challenge of modification access in the
server by devops professionals not any code injection and remote
incorrectly executed issues
- disk encryption solves the challenge of modification access in the
server by devops professionals not any code injection and automated
code drive incorrectly executed issues and access to memory and or
.git folder when appropriate chmod rights are provided
- "opens git up to export limitations" may not be a great reason to
avoid for the same. the object folder inside .git seems encoded if not
a binary store and can be reverse engineered via code
- "opens git up to export limitations" may not be a great reason to
avoid the same. load issues for speed are not that great reason when
tmp cache options can be a viable option. probably, you can work with
optionally encrypt the .git folder option.
- "opens git up to export limitations" may not be a great reason to
avoid the same. what other export limitations and CVEs are limiting
the need?
- symmetrical encryption: i am recommending a personal user provided
or default salt or key based based encryption for the .git folder
- you may wish to take feedback for the organization using git-scm in
their organizations. a bug bounty has been raised for gitlab, github,
and atlassian that are the most rigorous for the number of users in
the domain. i can also raise a bug bounty to azure, aws, google,
oracle, and other networked providers if needed shamelessly to get
this feature enabled (probably using an option to encrypt .git folder
while creating a repository)

"Have you explored using disk-level encryption to solve this?  While I
understand your
objective to "encrypt anything that might have data in it", there are solutions
independent of git what would cover most use cases. The problem with adding
symmetrical encryption to git is that it opens git up to export limitations and
related CVEs. It would also cause adoption issues with many organizations
who may have restrictions on whatever techniques git adopts to solve this.
My preferential solution is using COTS hardware encryption to solve protecting
data-at-rest content.

Regards,
Ganesh

On Wed, Dec 25, 2024 at 12:01 PM Krishnamurthy Ganesh B
<ganeshsurfs@gmail.com> wrote:
>
> hello,
>
> [apologies, not sure why my emails are bouncing due to the html version even when sent as text].
>
> @randall (i am sure we may have interacted before or probably same name someone else): my answers for your quote below:
>
> - disk encryption has nothing to do with .git storage. local access by access provided users will always be there.
> - disk encryption solves the challenge of modification access in the server by devops professionals not manipulation intent
> - disk encryption solves the challenge of modification access in the server by devops professionals not any code injection and remote incorrectly executed issues
> - disk encryption solves the challenge of modification access in the server by devops professionals not any code injection and automated code drive incorrectly executed issues and access to memory and or .git folder when appropriate chmod rights are provided
> - "opens git up to export limitations" may not be a great reason to avoid for the same. the object folder inside .git seems encoded if not a binary store and can be reverse engineered via code
> - "opens git up to export limitations" may not be a great reason to avoid the same. load issues for speed are not that great reason when tmp cache options can be a viable option. probably, you can work with optionally encrypt the .git folder option.
> - "opens git up to export limitations" may not be a great reason to avoid the same. what other export limitations and CVEs are limiting the need?
> - symmetrical encryption: i am recommending a personal user provided or default salt or key based based encryption for the .git folder
> - you may wish to take feedback for the organization using git-scm in their organizations. a bug bounty has been raised for gitlab, github, and atlassian that are the most rigorous for the number of users in the domain. i can also raise a bug bounty to azure, aws, google, oracle, and other networked providers if needed shamelessly to get this feature enabled (probably using an option to encrypt .git folder while creating a repository)
>
> "Have you explored using disk-level encryption to solve this?  While I understand your
> objective to "encrypt anything that might have data in it", there are solutions
> independent of git what would cover most use cases. The problem with adding
> symmetrical encryption to git is that it opens git up to export limitations and
> related CVEs. It would also cause adoption issues with many organizations
> who may have restrictions on whatever techniques git adopts to solve this.
> My preferential solution is using COTS hardware encryption to solve protecting
> data-at-rest content.
>
> Regards,
> Ganesh
>
>
> On Mon, Dec 23, 2024 at 7:58 PM <rsbecker@nexbridge.com> wrote:
> >
> > On December 23, 2024 7:04 AM, Krishnamurthy Ganesh B wrote:
> > >i am raising a git security red flag on the.git metadata files storing git logs, commits,
> > >and other metadata inside .git folder not encrypted using a two way salt or some
> > >other way like using a key for a two way encryption or some method of software
> > >encryption internally if / because the .git folder metadata is not encrypted.
> > >
> > >this has been raised to github before but will be raised again via hackerone security
> > >bug and to gitlab and altassian and other git repository source users if they are
> > >using their own internal modified sources.
> > >
> > >most of the errors like these will be directly closed.
> > >
> > >https://kondukto.io/blog/git-scm-affected-by-cve-2024-32002
> > >
> > >https://socradar.io/critical-security-updates-for-git-scm-cve-2024-32002-cve-
> > >2024-32004-lead-to-rce/
> > >
> > >https://stackoverflow.com/questions/45578579/what-file-metadata-is-
> > >preserved-by-git
> > >
> > >even packages like git-crypt do not encrypt metadata.
> > >https://github.com/AGWA/git-crypt
> >
> > Have you explored using disk-level encryption to solve this?  While I understand your
> > objective to "encrypt anything that might have data in it", there are solutions
> > independent of git what would cover most use cases. The problem with adding
> > symmetrical encryption to git is that it opens git up to export limitations and
> > related CVEs. It would also cause adoption issues with many organizations
> > who may have restrictions on whatever techniques git adopts to solve this.
> > My preferential solution is using COTS hardware encryption to solve protecting
> > data-at-rest content.
> >
> > --Randall
> >
>
>

Re: [bug] encryption of metadata in .git metadata file inside .git folder

[Krishnamurthy Ganesh B]

hello,

@randall: adding a point: While I understand your objective to
"encrypt anything that might have data in it", there are solutions
independent of git what would cover most use cases.

- encrypting everything or all data on .git metadata folder may not be
the point you wish to address in the point along with the export
solutions. the data of the git repository is not being addressed here.
we are discussing the .git metadata folder not the repository here.
- there are no solutions in the market that encrypts all data within
the .git metadata folder. again,  the data of the git repository is
not being addressed here. we are discussing the .git metadata folder.
-  "opens git up to export limitations" is not needed for .git
metadata folder. a few milliseconds of speed into cache with caching
read-write speeding options

ps: .git folder being referred to for the .git metadata folder (not
referring to git repository but hidden .git metadata folder)

[apologies, not sure why my emails are bouncing due to the html
version even when sent as text].

@randall (i am sure we may have interacted before or probably same
name someone else): my answers for your quote below:

- disk encryption has nothing to do with .git storage. local access by
access provided users will always be there.
- disk encryption solves the challenge of modification access in the
server by devops professionals not manipulation intent
- disk encryption solves the challenge of modification access in the
server by devops professionals not any code injection and remote
incorrectly executed issues
- disk encryption solves the challenge of modification access in the
server by devops professionals not any code injection and automated
code drive incorrectly executed issues and access to memory and or
.git folder when appropriate chmod rights are provided
- "opens git up to export limitations" may not be a great reason to
avoid for the same. the object folder inside .git seems encoded if not
a binary store and can be reverse engineered via code
- "opens git up to export limitations" may not be a great reason to
avoid the same. load issues for speed are not that great reason when
tmp cache options can be a viable option. probably, you can work with
optionally encrypt the .git folder option.
- "opens git up to export limitations" may not be a great reason to
avoid the same. what other export limitations and CVEs are limiting
the need?
- symmetrical encryption: i am recommending a personal user provided
or default salt or key based based encryption for the .git folder
- you may wish to take feedback for the organization using git-scm in
their organizations. a bug bounty has been raised for gitlab, github,
and atlassian that are the most rigorous for the number of users in
the domain. i can also raise a bug bounty to azure, aws, google,
oracle, and other networked providers if needed shamelessly to get
this feature enabled (probably using an option to encrypt .git folder
while creating a repository)

"Have you explored using disk-level encryption to solve this?  While I
understand your objective to "encrypt anything that might have data in
it", there are solutions independent of git what would cover most use
cases. The problem with adding symmetrical encryption to git is that
it opens git up to export limitations and related CVEs. It would also
cause adoption issues with many organizations who may have
restrictions on whatever techniques git adopts to solve this.

My preferential solution is using COTS hardware encryption to solve
protecting data-at-rest content.

Regards,
Ganesh B

On Wed, Dec 25, 2024 at 12:04 PM Krishnamurthy Ganesh B
<ganeshsurfs@gmail.com> wrote:
>
> hello,
>
> [apologies, not sure why my emails are bouncing due to the html
> version even when sent as text].
>
> @randall (i am sure we may have interacted before or probably same
> name someone else): my answers for your quote below:
>
> - disk encryption has nothing to do with .git storage. local access by
> access provided users will always be there.
> - disk encryption solves the challenge of modification access in the
> server by devops professionals not manipulation intent
> - disk encryption solves the challenge of modification access in the
> server by devops professionals not any code injection and remote
> incorrectly executed issues
> - disk encryption solves the challenge of modification access in the
> server by devops professionals not any code injection and automated
> code drive incorrectly executed issues and access to memory and or
> .git folder when appropriate chmod rights are provided
> - "opens git up to export limitations" may not be a great reason to
> avoid for the same. the object folder inside .git seems encoded if not
> a binary store and can be reverse engineered via code
> - "opens git up to export limitations" may not be a great reason to
> avoid the same. load issues for speed are not that great reason when
> tmp cache options can be a viable option. probably, you can work with
> optionally encrypt the .git folder option.
> - "opens git up to export limitations" may not be a great reason to
> avoid the same. what other export limitations and CVEs are limiting
> the need?
> - symmetrical encryption: i am recommending a personal user provided
> or default salt or key based based encryption for the .git folder
> - you may wish to take feedback for the organization using git-scm in
> their organizations. a bug bounty has been raised for gitlab, github,
> and atlassian that are the most rigorous for the number of users in
> the domain. i can also raise a bug bounty to azure, aws, google,
> oracle, and other networked providers if needed shamelessly to get
> this feature enabled (probably using an option to encrypt .git folder
> while creating a repository)
>
> "Have you explored using disk-level encryption to solve this?  While I
> understand your
> objective to "encrypt anything that might have data in it", there are solutions
> independent of git what would cover most use cases. The problem with adding
> symmetrical encryption to git is that it opens git up to export limitations and
> related CVEs. It would also cause adoption issues with many organizations
> who may have restrictions on whatever techniques git adopts to solve this.
> My preferential solution is using COTS hardware encryption to solve protecting
> data-at-rest content.
>
> Regards,
> Ganesh
>
> On Wed, Dec 25, 2024 at 12:01 PM Krishnamurthy Ganesh B
> <ganeshsurfs@gmail.com> wrote:
> >
> > hello,
> >
> > [apologies, not sure why my emails are bouncing due to the html version even when sent as text].
> >
> > @randall (i am sure we may have interacted before or probably same name someone else): my answers for your quote below:
> >
> > - disk encryption has nothing to do with .git storage. local access by access provided users will always be there.
> > - disk encryption solves the challenge of modification access in the server by devops professionals not manipulation intent
> > - disk encryption solves the challenge of modification access in the server by devops professionals not any code injection and remote incorrectly executed issues
> > - disk encryption solves the challenge of modification access in the server by devops professionals not any code injection and automated code drive incorrectly executed issues and access to memory and or .git folder when appropriate chmod rights are provided
> > - "opens git up to export limitations" may not be a great reason to avoid for the same. the object folder inside .git seems encoded if not a binary store and can be reverse engineered via code
> > - "opens git up to export limitations" may not be a great reason to avoid the same. load issues for speed are not that great reason when tmp cache options can be a viable option. probably, you can work with optionally encrypt the .git folder option.
> > - "opens git up to export limitations" may not be a great reason to avoid the same. what other export limitations and CVEs are limiting the need?
> > - symmetrical encryption: i am recommending a personal user provided or default salt or key based based encryption for the .git folder
> > - you may wish to take feedback for the organization using git-scm in their organizations. a bug bounty has been raised for gitlab, github, and atlassian that are the most rigorous for the number of users in the domain. i can also raise a bug bounty to azure, aws, google, oracle, and other networked providers if needed shamelessly to get this feature enabled (probably using an option to encrypt .git folder while creating a repository)
> >
> > "Have you explored using disk-level encryption to solve this?  While I understand your
> > objective to "encrypt anything that might have data in it", there are solutions
> > independent of git what would cover most use cases. The problem with adding
> > symmetrical encryption to git is that it opens git up to export limitations and
> > related CVEs. It would also cause adoption issues with many organizations
> > who may have restrictions on whatever techniques git adopts to solve this.
> > My preferential solution is using COTS hardware encryption to solve protecting
> > data-at-rest content.
> >
> > Regards,
> > Ganesh
> >
> >
> > On Mon, Dec 23, 2024 at 7:58 PM <rsbecker@nexbridge.com> wrote:
> > >
> > > On December 23, 2024 7:04 AM, Krishnamurthy Ganesh B wrote:
> > > >i am raising a git security red flag on the.git metadata files storing git logs, commits,
> > > >and other metadata inside .git folder not encrypted using a two way salt or some
> > > >other way like using a key for a two way encryption or some method of software
> > > >encryption internally if / because the .git folder metadata is not encrypted.
> > > >
> > > >this has been raised to github before but will be raised again via hackerone security
> > > >bug and to gitlab and altassian and other git repository source users if they are
> > > >using their own internal modified sources.
> > > >
> > > >most of the errors like these will be directly closed.
> > > >
> > > >https://kondukto.io/blog/git-scm-affected-by-cve-2024-32002
> > > >
> > > >https://socradar.io/critical-security-updates-for-git-scm-cve-2024-32002-cve-
> > > >2024-32004-lead-to-rce/
> > > >
> > > >https://stackoverflow.com/questions/45578579/what-file-metadata-is-
> > > >preserved-by-git
> > > >
> > > >even packages like git-crypt do not encrypt metadata.
> > > >https://github.com/AGWA/git-crypt
> > >
> > > Have you explored using disk-level encryption to solve this?  While I understand your
> > > objective to "encrypt anything that might have data in it", there are solutions
> > > independent of git what would cover most use cases. The problem with adding
> > > symmetrical encryption to git is that it opens git up to export limitations and
> > > related CVEs. It would also cause adoption issues with many organizations
> > > who may have restrictions on whatever techniques git adopts to solve this.
> > > My preferential solution is using COTS hardware encryption to solve protecting
> > > data-at-rest content.
> > >
> > > --Randall
> > >
> >
> >