From: Johannes Schindelin <Johannes.Schindelin@gmx.de> To: Lukas Straub <firstname.lastname@example.org> Cc: "brian m. carlson" <email@example.com>, Jeff King <firstname.lastname@example.org>, Junio C Hamano <email@example.com>, "Randall S. Becker" <firstname.lastname@example.org>, 'git' <email@example.com>, 'Elijah Newren' <firstname.lastname@example.org>, 'Brandon Williams' <email@example.com> Subject: Re: [RFC PATCH 0/2] Allow adding .git files and directories Date: Mon, 24 Aug 2020 15:52:28 +0200 (CEST) [thread overview] Message-ID: <nycvar.QRO.firstname.lastname@example.org> (raw) In-Reply-To: <20200822211250.59a8b351@luklap> Hi Lukas, On Sat, 22 Aug 2020, Lukas Straub wrote: > On Sat, 22 Aug 2020 18:53:07 +0000 > "brian m. carlson" <email@example.com> wrote: > > > On 2020-08-22 at 14:21:52, Lukas Straub wrote: > > > On Fri, 21 Aug 2020 22:52:37 +0000 > > > "brian m. carlson" <firstname.lastname@example.org> wrote: > > > > > > > On 2020-08-21 at 12:39:41, Lukas Straub wrote: > > > > > The downsides we discussed don't apply in this usecase. These are mostly > > > > > personal files, so I wont upload them to any hosting site (not even private > > > > > ones). There is no security impact as I only sync with trusted devices. > > > > > > > > I realize this works for you, but in general Git's security model does > > > > not permit untrusted configuration files or hooks. Configuration can > > > > have numerous different commands that Git may execute and it is not, in > > > > general, safe to share across users. This is why Git does not provide a > > > > way to sync whole repositories, only the objects within them. > > > > > > > > Adding the ability to transport configuration through a repository is a > > > > security problem because it allows an attacker to potentially execute > > > > arbitrary code on the user's machine, and I can tell you that many, many > > > > people do clone untrusted repositories. Just because you are aware of > > > > the risks, are comfortable with them, and are the only user in this > > > > scenario does not mean that this feature is a prudent one to add to Git. > > > > It violates our own security model, and as such, isn't a feature we're > > > > going to want to add. > > > > > > I don't understand. If the attacker gets the user to set git config options, > > > then all hope is lost anyways, no? > > > > When you can embed repositories in other repositories like you're > > proposing, those embedded repositories can have configuration files in > > them (e.g., .git/config), which leads to the security problem. > > Yes, I understand that, but the user has to actively allow this via the > allowDotGit config option, which I'll implement in the next patch version. > So the attacker has to get the user to set the option. If the user does this, > the attacker could get the user to set any other option (like core.gitProxy) > anyway and gain remote execution regardless of this patch. Even if your patches were perfect, and even if unrelated patches in the future would never weaken this via an unintended consequence, it is _still_ too easy for users to get this wrong, or to forget about a config option they set. Having addressed my share of CVEs in Git, I am pretty firmly against weakening Git's security model in the way you propose. Ciao, Johannes P.S.: Besides, your patch would violate a the principle that unchanged entities do not cause changes in the objects' hashes. And if you even so much as `git repack` in one of those repositories you want to check in, the hashes will change, even if there are no actual changes. It's much like checking in gzipped files which then delta super badly. And in any case, the proposed functionality is definitely in conflict with Git's design.
next prev parent reply other threads:[~2020-08-24 13:53 UTC|newest] Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-08-19 16:43 Lukas Straub 2020-08-19 16:43 ` [RFC PATCH 1/2] dir/read-cache: " Lukas Straub 2020-08-19 16:43 ` [RFC PATCH 2/2] dir: Recurse into nested git repos if they aren't submodules Lukas Straub 2020-08-19 18:03 ` [RFC PATCH 0/2] Allow adding .git files and directories Junio C Hamano 2020-08-19 18:47 ` Randall S. Becker 2020-08-19 19:09 ` Junio C Hamano 2020-08-19 19:23 ` Randall S. Becker 2020-08-19 20:17 ` Jeff King 2020-08-19 20:32 ` Junio C Hamano 2020-08-19 20:38 ` Jeff King 2020-08-19 21:56 ` Randall S. Becker 2020-08-20 10:16 ` Johannes Schindelin 2020-08-20 11:34 ` Lukas Straub 2020-08-20 13:01 ` Jeff King 2020-08-21 12:39 ` Lukas Straub 2020-08-21 13:11 ` Randall S. Becker 2020-08-21 22:52 ` brian m. carlson 2020-08-22 14:21 ` Lukas Straub 2020-08-22 18:53 ` brian m. carlson 2020-08-22 19:12 ` Lukas Straub 2020-08-24 13:52 ` Johannes Schindelin [this message] 2020-08-20 12:37 ` Lukas Straub 2020-08-20 13:08 ` Jeff King 2020-08-19 19:22 ` Lukas Straub 2020-08-19 18:47 ` Lukas Straub 2020-08-19 19:16 ` Randall S. Becker 2020-08-20 11:46 ` Lukas Straub
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=nycvar.QRO.email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [RFC PATCH 0/2] Allow adding .git files and directories' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).