git non-intrusive clone

git non-intrusive clone

[Luca Di Carlo]

Hey everyone,
I am reading more and more blog posts about job interviews that require the people to git clone a malicious repo with commands executed using git hooks. 
I wonder if we could have a 
`git clone --non-intrusive ...` 
That would disable all git settings set within the repo. 
Maybe by adding a `.nogitconfig` file or something, so that the developers remember that because of this file, he cannot push or fetch, or use any `.git/` defined stuff. 

I hope this is the right channel, sorry if it's not. 

Thank you for all your work,
Kind regards
Luca

Cordialement
Luca Di Carlo 

Re: git non-intrusive clone

[D. Ben Knoble]

I may have misunderstood, but…

On Wed, Oct 7, 2026 at 4:40 AM Luca Di Carlo <luca@dicarlo.email> wrote:
>
> Hey everyone,
> I am reading more and more blog posts about job interviews that require the people to git clone a malicious repo with commands executed using git hooks.

I don't think a _clone_ can ship and enable hooks on its own. (I know
of at least one npm package that wants to install Git hooks when you
run "npm i"/"npm ci", though… turn on "ignore-scripts" for that.) That
is, you should be very careful executing anything from a cloned
repository you don't trust, but I don't think a clone can ship
executable hooks in a meaningful way.

What *can* get you is an archive that includes ".git/", since it can
contain hooks that Git will execute (modulo safe.directory, I think,
but that typically doesn't apply in these situations). So: also be
careful extracting arbitrary archives!

Maybe you had other security flaw in mind, or maybe someone else can
tell me how we fix this beyond "tell folks to be careful" (which I
agree doesn't scale well).

-- 
D. Ben Knoble

Re: git non-intrusive clone

[Luca Di Carlo]

Hey,
You are right, I've re-read the article that I had in mind, he downloads it as zip before, not as clone.
`.git` is not cloned. 
Sorry for that. 
Thanks

On Wed, Oct 7, 2026, at 20:54, D. Ben Knoble wrote:
> I may have misunderstood, but…
> 
> On Wed, Oct 7, 2026 at 4:40 AM Luca Di Carlo wrote:
> >
> > Hey everyone,
> > I am reading more and more blog posts about job interviews that require the people to git clone a malicious repo with commands executed using git hooks.
> 
> I don't think a _clone_ can ship and enable hooks on its own. (I know
> of at least one npm package that wants to install Git hooks when you
> run "npm i"/"npm ci", though… turn on "ignore-scripts" for that.) That
> is, you should be very careful executing anything from a cloned
> repository you don't trust, but I don't think a clone can ship
> executable hooks in a meaningful way.
> 
> What *can* get you is an archive that includes ".git/", since it can
> contain hooks that Git will execute (modulo safe.directory, I think,
> but that typically doesn't apply in these situations). So: also be
> careful extracting arbitrary archives!
> 
> Maybe you had other security flaw in mind, or maybe someone else can
> tell me how we fix this beyond "tell folks to be careful" (which I
> agree doesn't scale well).
> 
> -- 
> D. Ben Knoble
> 

Luca

Re: git non-intrusive clone

[D. Ben Knoble]

On Wed, Oct 7, 2026 at 3:20 PM Luca Di Carlo <luca@dicarlo.email> wrote:
>
> Hey,
> You are right, I've re-read the article that I had in mind, he downloads it as zip before, not as clone.
> `.git` is not cloned.
> Sorry for that.
> Thanks

[we bottom-post here ;)]

No worries! I think in the past Git has said "that's not really part
of our security model", but I don't have any authoritative references.

Still, definitely worth having the conversation, and I'm glad we
figured it out together. I'm still somewhat interested in what we can
do besides "try to tell folks not to blindly trust downloaded files"…
but that's never going to stop being bad advice :)

-- 
D. Ben Knoble

Re: git non-intrusive clone

[Nico Williams]

On Wed, Oct 07, 2026 at 03:50:43PM -0400, D. Ben Knoble wrote:
> Still, definitely worth having the conversation, and I'm glad we
> figured it out together. I'm still somewhat interested in what we can
> do besides "try to tell folks not to blindly trust downloaded files"…
> but that's never going to stop being bad advice :)

There have been horror stories about phishing via fake interviews.
There is no easy way to ascertain the trustworthiness of such code.
Just don't run that code.  Use a hosted VM service for this or insist
that they use a code pad type web application -- that they don't use
those is a red flag.

Nico
--