Re: [PATCH] hooks: propose repository owner configured hooks

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Mon, Jun 21 2021, Jonathan Tan wrote:

[Most of this I've replied to in
https://lore.kernel.org/git/87k0mn2dd3.fsf@evledraar.gmail.com/; or
that's a better jump-off point to discuss, just replying to leftover
bits here]

>> It's also just un-git-y in *requiring* a remote. A .mailmap,
>> .gitattributes etc. all work with a repo you find on-disk, why does
>> config & hooks need to be different?
>
> Why is a remote required? The purpose of this proposal is for remotes to
> suggest hooks, but that doesn't mean that the existing hooks mechanism
> will no longer work.

As a general matter because Git is a distributed VCS, so we should think
about how new proposed features can integrate properly with distributed
models of development.

If we make distributed development a second-class feature set we're
responsible from e.g. guiding open source projects away from distributed
repos and patch application etc. to centralized hosting.

We are also talking about exposing users to some manner of "do you trust
this thingy?" UI from day 1.

Given the points about training users to accept insecure patterns from
others on this topic in past discussions I don't we can just say we'll
worry about the distributed aspect later, as that means e.g. someone who
interacts with N forks of a repo in GitHub being encouraged to add N
trusted remotes if they want their linting of PRs to work properly.

>> > This seems like an OK alternative to allow-listing based on remote,
>> > but are you expecting users to add a GPG key to their .gitconfig?
>> 
>> That instead of saying you trust https://github.com/git/git your primary
>> means of interaction with this feature would be saying you, as an
>> example, trust Junio's GPG key.
>
> I think this feature can be extended to trusting GPG keys later. Do you
> think that we should move to a model of trusting a key *instead of* (not
> "in addition to") a URL?
>
> [snip until summary paragraph]

I think we should trust content, GPG keys are one way of getting
there. But even a magic URL implementation can be based on trusting
advertised content with what I'd think are fairly small
changes. E.g. you'd clone a branch, it has hooks, you'd diff the
relevant thing against your trusted remote's version, it's the same it
passes.