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@xxxxxxxxx> 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@xxxxxxxxxxxxx> 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 > > > >
