Re: [RFC PATCH 0/2] MVP implementation of remote-suggested hooks

> On Wed, Jun 16 2021, Jonathan Tan wrote:
> 
> > This is a continuation of the work from [1]. That work described the
> > reasons, possible features, and possible workflows, but not the
> > implementation in detail. This patch set has an MVP implementation, and
> > my hope is that having a concrete implementation to look at makes it
> > easier to discuss matters of implementation.
> 
> My C on this RFC is:
> 
> 1) A request that someone reply (there or here would do) to my comments
>    on the last iteration of this at:
>    https://lore.kernel.org/git/874kghk906.fsf@evledraar.gmail.com/

> > Design choices:
> >
> >  1. Where should the suggested hooks be in the remote repo? A branch,
> >     a non-branch ref, a config? I think that a branch is best - it is
> >     relatively well-understood and any hooks there can be
> >     version-controlled (and its history is independent of the other
> >     branches).
> 
> First, unlike brian I don't (I hope I'm fairly summarizing his view
> here) disagree mostly or entirely with the existence of such a feature
> at all. I mean, I get the viewpoint that git shouldn't bless what
> amounts to an active RCE from the remote.
> 
> I just think that we could probably do a better job of it than what
> people are doing in practice, and I've seen people do stuff like have
> build systems setup permanent symlinks to git-hooks/<some-name> in the
> tracked dir. We could at least envision a git-native implementation
> asking the user "do you want this hook update? <shows diff>".
> 
> I just find this design approach completely bizarre as noted (probably
> in less blunt words) in the linked E-Mail.

> We have Emily's series to convert hooks to be config driven that we hope
> to land in some form, at that point they won't be any more of a special
> snowflake than any other config.
> 
> And then, instead of doing what I'd think would be the natural result of
> that: Simply supporting an in-repo top-level ".gitconfig" file. We're
> still going to seemingly forever have them be an even more special
> snowflake with this facility, and the reason seems to be mostly/entirely
> to do with working around some aspect or restriction of Google's
> internal infrastructure.

> I think it's just un-git-y to have a meta-branch that in some way drives
> not only all other branches, but all other revisions of all branches,
> ever.
> 
> It breaks expectations around git in lots of different ways, you can't
> fetch a single branch and get its hooks,

> I think I get why you want to do it that way, I just don't get why, as
> mostly noted in those earlier rounds why it wouldn't be a better
> approach / more straightforward / more git-y to:
> 
> 1. Work on getting hooks driven by config <this is happening with
>    Emily's series / my split-out "base" topic>
> 2. Have a facility to read an in-repo '.gitconfig'; have lots of safety
>    valves etc. around this, I suggested starting with a whitelist of the
>    N least dangerous config options, e.g. some diff viewing options, or
>    a suggested sendemail.to or whatever.

> 3. Work our way up to trusting that for more dangerous stuff, eventually
>    hooks. Most of the legitimate concerns from others with this is
>    having some UX where our users won't be trained to just blindly say
>    "yes" to an alias/hook config that "rm -rf's /" or whatever.
> 
>    If we start experimenting with that with aliases or hooks that can
>    run arbitrary code it's like handing a toddlder a shotgun, let's at
>    least start with a sharp fork or something (less dangerous config) :)
> 
> 4. People who want this "I want my hooks to apply to all revisions ever"
>    could probably get 99% or 100% of what they want if their hook is
>    just a stub that does the equivalent of:
> 
>        sh `curl https://git.google.com/$reponame/hooks/$hookname`
> 
>    You'd then simply forbid on your servers any changes to a .gitconfig
>    that did anything with the hook.* namespace.

> With such an implementation you don't need a magic
> "refs/remotes/origin/suggested-hooks" refs, just some state machine (I
> suggested e.g. GPG signing chains as an eventual end-state, but "show a
> diff every time" would also do) that keeps track of what config (and
> hooks are just one such case) has been OK'd, and which has not.

> you could even clone some random person's fork
> of a "blessed" project, because the hooks would be the same `sh $(curl
> <url I already trust>)`. That validation could even be a system-level
> in-config hook on your laptop, thus bringing the whole thing full
> circle...