Re: [RFC PATCH 0/2] Allow adding .git files and directories

> On Sat, 22 Aug 2020 18:53:07 +0000
> "brian m. carlson" <sandals@crustytoothpaste.net> wrote:
>
> > On 2020-08-22 at 14:21:52, Lukas Straub wrote:
> > > On Fri, 21 Aug 2020 22:52:37 +0000
> > > "brian m. carlson" <sandals@crustytoothpaste.net> 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.