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
