{"thread":{"id":"62686","subject":"[bug] encryption of metadata in .git metadata file inside .git folder","startedAt":"2024-12-23T12:03:56Z","lastAt":"2025-01-13T06:37:44Z","messageCount":4,"participants":["Krishnamurthy Ganesh B","rsbecker@nexbridge.com"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"509520","messageId":"CAMmT1pJ0ReaX+g2_gFQ2oLUrzhR5wCXGvCj_WwDMXcfG2DNG_g@mail.gmail.com","threadId":"62686","inReplyTo":"CAMmT1pJnZxxD3wFikiDRCqZZMxO8P6EgVHe9mJEsfA8PK4-OfA@mail.gmail.com","subject":"[bug] encryption of metadata in .git metadata file inside .git folder","fromName":"Krishnamurthy Ganesh B","fromEmail":"ganeshsurfs@gmail.com","sentAt":"2024-12-23T12:03:44Z","receivedAt":"2024-12-23T12:03:56Z","isPatch":false,"sender":{"key":"ganeshsurfs@gmail.com","avatar":null},"body":"hello,\n\ngreetings.\n\ni am raising a git security red flag on the.git metadata files storing\ngit logs, commits, and other metadata inside .git folder not encrypted\nusing a two way salt or some other way like using a key for a two way\nencryption or some method of software encryption internally if /\nbecause the .git folder metadata is not encrypted.\n\nthis has been raised to github before but will be raised again via\nhackerone security bug and to gitlab and altassian and other git\nrepository source users if they are using their own internal modified\nsources.\n\nmost of the errors like these will be directly closed.\n\nhttps://kondukto.io/blog/git-scm-affected-by-cve-2024-32002\n\nhttps://socradar.io/critical-security-updates-for-git-scm-cve-2024-32002-cve-2024-32004-lead-to-rce/\n\nhttps://stackoverflow.com/questions/45578579/what-file-metadata-is-preserved-by-git\n\neven packages like git-crypt do not encrypt metadata.\nhttps://github.com/AGWA/git-crypt\n\nhave a nice day.\n\nregards,\nganesh k\n"},{"id":"509523","messageId":"000a01db5546$f034b7a0$d09e26e0$@nexbridge.com","threadId":"62686","inReplyTo":"CAMmT1pJ0ReaX+g2_gFQ2oLUrzhR5wCXGvCj_WwDMXcfG2DNG_g@mail.gmail.com","subject":"RE: [bug] encryption of metadata in .git metadata file inside .git folder","fromName":"","fromEmail":"rsbecker@nexbridge.com","sentAt":"2024-12-23T14:28:24Z","receivedAt":"2024-12-23T14:28:33Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On December 23, 2024 7:04 AM, Krishnamurthy Ganesh B wrote:\n>i am raising a git security red flag on the.git metadata files storing git logs, commits,\n>and other metadata inside .git folder not encrypted using a two way salt or some\n>other way like using a key for a two way encryption or some method of software\n>encryption internally if / because the .git folder metadata is not encrypted.\n>\n>this has been raised to github before but will be raised again via hackerone security\n>bug and to gitlab and altassian and other git repository source users if they are\n>using their own internal modified sources.\n>\n>most of the errors like these will be directly closed.\n>\n>https://kondukto.io/blog/git-scm-affected-by-cve-2024-32002\n>\n>https://socradar.io/critical-security-updates-for-git-scm-cve-2024-32002-cve-\n>2024-32004-lead-to-rce/\n>\n>https://stackoverflow.com/questions/45578579/what-file-metadata-is-\n>preserved-by-git\n>\n>even packages like git-crypt do not encrypt metadata.\n>https://github.com/AGWA/git-crypt\n\nHave you explored using disk-level encryption to solve this?  While I understand your\nobjective to \"encrypt anything that might have data in it\", there are solutions\nindependent of git what would cover most use cases. The problem with adding\nsymmetrical encryption to git is that it opens git up to export limitations and\nrelated CVEs. It would also cause adoption issues with many organizations\nwho may have restrictions on whatever techniques git adopts to solve this.\nMy preferential solution is using COTS hardware encryption to solve protecting\ndata-at-rest content.\n\n--Randall\n\n"},{"id":"509555","messageId":"CAMmT1pJpKct+zV_WV_QXKCL_A0cGURNbKZDKGzbATCDN3cQDsw@mail.gmail.com","threadId":"62686","inReplyTo":"CAMmT1pLszvmQN06eUdnhZHpqDLrF2aaXFxdniumLt1x9MSdKfQ@mail.gmail.com","subject":"Re: [bug] encryption of metadata in .git metadata file inside .git folder","fromName":"Krishnamurthy Ganesh B","fromEmail":"ganeshsurfs@gmail.com","sentAt":"2024-12-25T06:34:26Z","receivedAt":"2024-12-25T06:34:37Z","isPatch":false,"sender":{"key":"ganeshsurfs@gmail.com","avatar":null},"body":"hello,\n\n[apologies, not sure why my emails are bouncing due to the html\nversion even when sent as text].\n\n@randall (i am sure we may have interacted before or probably same\nname someone else): my answers for your quote below:\n\n- disk encryption has nothing to do with .git storage. local access by\naccess provided users will always be there.\n- disk encryption solves the challenge of modification access in the\nserver by devops professionals not manipulation intent\n- disk encryption solves the challenge of modification access in the\nserver by devops professionals not any code injection and remote\nincorrectly executed issues\n- disk encryption solves the challenge of modification access in the\nserver by devops professionals not any code injection and automated\ncode drive incorrectly executed issues and access to memory and or\n.git folder when appropriate chmod rights are provided\n- \"opens git up to export limitations\" may not be a great reason to\navoid for the same. the object folder inside .git seems encoded if not\na binary store and can be reverse engineered via code\n- \"opens git up to export limitations\" may not be a great reason to\navoid the same. load issues for speed are not that great reason when\ntmp cache options can be a viable option. probably, you can work with\noptionally encrypt the .git folder option.\n- \"opens git up to export limitations\" may not be a great reason to\navoid the same. what other export limitations and CVEs are limiting\nthe need?\n- symmetrical encryption: i am recommending a personal user provided\nor default salt or key based based encryption for the .git folder\n- you may wish to take feedback for the organization using git-scm in\ntheir organizations. a bug bounty has been raised for gitlab, github,\nand atlassian that are the most rigorous for the number of users in\nthe domain. i can also raise a bug bounty to azure, aws, google,\noracle, and other networked providers if needed shamelessly to get\nthis feature enabled (probably using an option to encrypt .git folder\nwhile creating a repository)\n\n\"Have you explored using disk-level encryption to solve this?  While I\nunderstand your\nobjective to \"encrypt anything that might have data in it\", there are solutions\nindependent of git what would cover most use cases. The problem with adding\nsymmetrical encryption to git is that it opens git up to export limitations and\nrelated CVEs. It would also cause adoption issues with many organizations\nwho may have restrictions on whatever techniques git adopts to solve this.\nMy preferential solution is using COTS hardware encryption to solve protecting\ndata-at-rest content.\n\nRegards,\nGanesh\n\nOn Wed, Dec 25, 2024 at 12:01 PM Krishnamurthy Ganesh B\n<ganeshsurfs@gmail.com> wrote:\n>\n> hello,\n>\n> [apologies, not sure why my emails are bouncing due to the html version even when sent as text].\n>\n> @randall (i am sure we may have interacted before or probably same name someone else): my answers for your quote below:\n>\n> - disk encryption has nothing to do with .git storage. local access by access provided users will always be there.\n> - disk encryption solves the challenge of modification access in the server by devops professionals not manipulation intent\n> - disk encryption solves the challenge of modification access in the server by devops professionals not any code injection and remote incorrectly executed issues\n> - 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\n> - \"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\n> - \"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.\n> - \"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?\n> - symmetrical encryption: i am recommending a personal user provided or default salt or key based based encryption for the .git folder\n> - 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)\n>\n> \"Have you explored using disk-level encryption to solve this?  While I understand your\n> objective to \"encrypt anything that might have data in it\", there are solutions\n> independent of git what would cover most use cases. The problem with adding\n> symmetrical encryption to git is that it opens git up to export limitations and\n> related CVEs. It would also cause adoption issues with many organizations\n> who may have restrictions on whatever techniques git adopts to solve this.\n> My preferential solution is using COTS hardware encryption to solve protecting\n> data-at-rest content.\n>\n> Regards,\n> Ganesh\n>\n>\n> On Mon, Dec 23, 2024 at 7:58 PM <rsbecker@nexbridge.com> wrote:\n> >\n> > On December 23, 2024 7:04 AM, Krishnamurthy Ganesh B wrote:\n> > >i am raising a git security red flag on the.git metadata files storing git logs, commits,\n> > >and other metadata inside .git folder not encrypted using a two way salt or some\n> > >other way like using a key for a two way encryption or some method of software\n> > >encryption internally if / because the .git folder metadata is not encrypted.\n> > >\n> > >this has been raised to github before but will be raised again via hackerone security\n> > >bug and to gitlab and altassian and other git repository source users if they are\n> > >using their own internal modified sources.\n> > >\n> > >most of the errors like these will be directly closed.\n> > >\n> > >https://kondukto.io/blog/git-scm-affected-by-cve-2024-32002\n> > >\n> > >https://socradar.io/critical-security-updates-for-git-scm-cve-2024-32002-cve-\n> > >2024-32004-lead-to-rce/\n> > >\n> > >https://stackoverflow.com/questions/45578579/what-file-metadata-is-\n> > >preserved-by-git\n> > >\n> > >even packages like git-crypt do not encrypt metadata.\n> > >https://github.com/AGWA/git-crypt\n> >\n> > Have you explored using disk-level encryption to solve this?  While I understand your\n> > objective to \"encrypt anything that might have data in it\", there are solutions\n> > independent of git what would cover most use cases. The problem with adding\n> > symmetrical encryption to git is that it opens git up to export limitations and\n> > related CVEs. It would also cause adoption issues with many organizations\n> > who may have restrictions on whatever techniques git adopts to solve this.\n> > My preferential solution is using COTS hardware encryption to solve protecting\n> > data-at-rest content.\n> >\n> > --Randall\n> >\n>\n>\n"},{"id":"510389","messageId":"CAMmT1pJO7t2vyanDko_0ed1VZOP_TOfpJe1JNjN5EpoRbRVByQ@mail.gmail.com","threadId":"62686","inReplyTo":"CAMmT1pJpKct+zV_WV_QXKCL_A0cGURNbKZDKGzbATCDN3cQDsw@mail.gmail.com","subject":"Re: [bug] encryption of metadata in .git metadata file inside .git folder","fromName":"Krishnamurthy Ganesh B","fromEmail":"ganeshsurfs@gmail.com","sentAt":"2025-01-13T06:37:36Z","receivedAt":"2025-01-13T06:37:44Z","isPatch":false,"sender":{"key":"ganeshsurfs@gmail.com","avatar":null},"body":"hello,\n\n@randall: adding a point: While I understand your objective to\n\"encrypt anything that might have data in it\", there are solutions\nindependent of git what would cover most use cases.\n\n- encrypting everything or all data on .git metadata folder may not be\nthe point you wish to address in the point along with the export\nsolutions. the data of the git repository is not being addressed here.\nwe are discussing the .git metadata folder not the repository here.\n- there are no solutions in the market that encrypts all data within\nthe .git metadata folder. again,  the data of the git repository is\nnot being addressed here. we are discussing the .git metadata folder.\n-  \"opens git up to export limitations\" is not needed for .git\nmetadata folder. a few milliseconds of speed into cache with caching\nread-write speeding options\n\nps: .git folder being referred to for the .git metadata folder (not\nreferring to git repository but hidden .git metadata folder)\n\n[apologies, not sure why my emails are bouncing due to the html\nversion even when sent as text].\n\n@randall (i am sure we may have interacted before or probably same\nname someone else): my answers for your quote below:\n\n- disk encryption has nothing to do with .git storage. local access by\naccess provided users will always be there.\n- disk encryption solves the challenge of modification access in the\nserver by devops professionals not manipulation intent\n- disk encryption solves the challenge of modification access in the\nserver by devops professionals not any code injection and remote\nincorrectly executed issues\n- disk encryption solves the challenge of modification access in the\nserver by devops professionals not any code injection and automated\ncode drive incorrectly executed issues and access to memory and or\n.git folder when appropriate chmod rights are provided\n- \"opens git up to export limitations\" may not be a great reason to\navoid for the same. the object folder inside .git seems encoded if not\na binary store and can be reverse engineered via code\n- \"opens git up to export limitations\" may not be a great reason to\navoid the same. load issues for speed are not that great reason when\ntmp cache options can be a viable option. probably, you can work with\noptionally encrypt the .git folder option.\n- \"opens git up to export limitations\" may not be a great reason to\navoid the same. what other export limitations and CVEs are limiting\nthe need?\n- symmetrical encryption: i am recommending a personal user provided\nor default salt or key based based encryption for the .git folder\n- you may wish to take feedback for the organization using git-scm in\ntheir organizations. a bug bounty has been raised for gitlab, github,\nand atlassian that are the most rigorous for the number of users in\nthe domain. i can also raise a bug bounty to azure, aws, google,\noracle, and other networked providers if needed shamelessly to get\nthis feature enabled (probably using an option to encrypt .git folder\nwhile creating a repository)\n\n\"Have you explored using disk-level encryption to solve this?  While I\nunderstand your objective to \"encrypt anything that might have data in\nit\", there are solutions independent of git what would cover most use\ncases. The problem with adding symmetrical encryption to git is that\nit opens git up to export limitations and related CVEs. It would also\ncause adoption issues with many organizations who may have\nrestrictions on whatever techniques git adopts to solve this.\n\nMy preferential solution is using COTS hardware encryption to solve\nprotecting data-at-rest content.\n\nRegards,\nGanesh B\n\nOn Wed, Dec 25, 2024 at 12:04 PM Krishnamurthy Ganesh B\n<ganeshsurfs@gmail.com> wrote:\n>\n> hello,\n>\n> [apologies, not sure why my emails are bouncing due to the html\n> version even when sent as text].\n>\n> @randall (i am sure we may have interacted before or probably same\n> name someone else): my answers for your quote below:\n>\n> - disk encryption has nothing to do with .git storage. local access by\n> access provided users will always be there.\n> - disk encryption solves the challenge of modification access in the\n> server by devops professionals not manipulation intent\n> - disk encryption solves the challenge of modification access in the\n> server by devops professionals not any code injection and remote\n> incorrectly executed issues\n> - disk encryption solves the challenge of modification access in the\n> server by devops professionals not any code injection and automated\n> code drive incorrectly executed issues and access to memory and or\n> .git folder when appropriate chmod rights are provided\n> - \"opens git up to export limitations\" may not be a great reason to\n> avoid for the same. the object folder inside .git seems encoded if not\n> a binary store and can be reverse engineered via code\n> - \"opens git up to export limitations\" may not be a great reason to\n> avoid the same. load issues for speed are not that great reason when\n> tmp cache options can be a viable option. probably, you can work with\n> optionally encrypt the .git folder option.\n> - \"opens git up to export limitations\" may not be a great reason to\n> avoid the same. what other export limitations and CVEs are limiting\n> the need?\n> - symmetrical encryption: i am recommending a personal user provided\n> or default salt or key based based encryption for the .git folder\n> - you may wish to take feedback for the organization using git-scm in\n> their organizations. a bug bounty has been raised for gitlab, github,\n> and atlassian that are the most rigorous for the number of users in\n> the domain. i can also raise a bug bounty to azure, aws, google,\n> oracle, and other networked providers if needed shamelessly to get\n> this feature enabled (probably using an option to encrypt .git folder\n> while creating a repository)\n>\n> \"Have you explored using disk-level encryption to solve this?  While I\n> understand your\n> objective to \"encrypt anything that might have data in it\", there are solutions\n> independent of git what would cover most use cases. The problem with adding\n> symmetrical encryption to git is that it opens git up to export limitations and\n> related CVEs. It would also cause adoption issues with many organizations\n> who may have restrictions on whatever techniques git adopts to solve this.\n> My preferential solution is using COTS hardware encryption to solve protecting\n> data-at-rest content.\n>\n> Regards,\n> Ganesh\n>\n> On Wed, Dec 25, 2024 at 12:01 PM Krishnamurthy Ganesh B\n> <ganeshsurfs@gmail.com> wrote:\n> >\n> > hello,\n> >\n> > [apologies, not sure why my emails are bouncing due to the html version even when sent as text].\n> >\n> > @randall (i am sure we may have interacted before or probably same name someone else): my answers for your quote below:\n> >\n> > - disk encryption has nothing to do with .git storage. local access by access provided users will always be there.\n> > - disk encryption solves the challenge of modification access in the server by devops professionals not manipulation intent\n> > - disk encryption solves the challenge of modification access in the server by devops professionals not any code injection and remote incorrectly executed issues\n> > - 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\n> > - \"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\n> > - \"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.\n> > - \"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?\n> > - symmetrical encryption: i am recommending a personal user provided or default salt or key based based encryption for the .git folder\n> > - 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)\n> >\n> > \"Have you explored using disk-level encryption to solve this?  While I understand your\n> > objective to \"encrypt anything that might have data in it\", there are solutions\n> > independent of git what would cover most use cases. The problem with adding\n> > symmetrical encryption to git is that it opens git up to export limitations and\n> > related CVEs. It would also cause adoption issues with many organizations\n> > who may have restrictions on whatever techniques git adopts to solve this.\n> > My preferential solution is using COTS hardware encryption to solve protecting\n> > data-at-rest content.\n> >\n> > Regards,\n> > Ganesh\n> >\n> >\n> > On Mon, Dec 23, 2024 at 7:58 PM <rsbecker@nexbridge.com> wrote:\n> > >\n> > > On December 23, 2024 7:04 AM, Krishnamurthy Ganesh B wrote:\n> > > >i am raising a git security red flag on the.git metadata files storing git logs, commits,\n> > > >and other metadata inside .git folder not encrypted using a two way salt or some\n> > > >other way like using a key for a two way encryption or some method of software\n> > > >encryption internally if / because the .git folder metadata is not encrypted.\n> > > >\n> > > >this has been raised to github before but will be raised again via hackerone security\n> > > >bug and to gitlab and altassian and other git repository source users if they are\n> > > >using their own internal modified sources.\n> > > >\n> > > >most of the errors like these will be directly closed.\n> > > >\n> > > >https://kondukto.io/blog/git-scm-affected-by-cve-2024-32002\n> > > >\n> > > >https://socradar.io/critical-security-updates-for-git-scm-cve-2024-32002-cve-\n> > > >2024-32004-lead-to-rce/\n> > > >\n> > > >https://stackoverflow.com/questions/45578579/what-file-metadata-is-\n> > > >preserved-by-git\n> > > >\n> > > >even packages like git-crypt do not encrypt metadata.\n> > > >https://github.com/AGWA/git-crypt\n> > >\n> > > Have you explored using disk-level encryption to solve this?  While I understand your\n> > > objective to \"encrypt anything that might have data in it\", there are solutions\n> > > independent of git what would cover most use cases. The problem with adding\n> > > symmetrical encryption to git is that it opens git up to export limitations and\n> > > related CVEs. It would also cause adoption issues with many organizations\n> > > who may have restrictions on whatever techniques git adopts to solve this.\n> > > My preferential solution is using COTS hardware encryption to solve protecting\n> > > data-at-rest content.\n> > >\n> > > --Randall\n> > >\n> >\n> >\n"}]}