git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Derrick Stolee <stolee@gmail.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"brian m. carlson" <sandals@crustytoothpaste.net>
Cc: Albert Cui <albertqcui@gmail.com>,
	Albert Cui via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org
Subject: Re: [PATCH v2] hooks: propose project configured hooks
Date: Wed, 7 Apr 2021 09:09:20 -0400	[thread overview]
Message-ID: <9af3770f-204b-253b-d7f2-c9d5e7cf2fdb@gmail.com> (raw)
In-Reply-To: <87tuoijzsy.fsf@evledraar.gmail.com>

On 4/7/2021 3:53 AM, Ævar Arnfjörð Bjarmason wrote:
> 
> On Wed, Apr 07 2021, brian m. carlson wrote:
>>
>> I continue to have serious reservations about this series and approach,
>> and I'm not sure that any proposal we can adopt here will address the
>> security concerns.  To be frank, I don't think this proposal should move
>> forward in its current state or otherwise, since I think the security
>> problems are inherent in this approach and fundamentally can't be fixed.
>>
>> This is, as should be obvious from my email address, my personal
>> opinion, despite my reference to my employer above.  Unless otherwise
>> stated, I don't speak for my employer and they don't speak for me.
> 
> I agree with pretty much every word you said, in particular the social
> engineering aspect of this. In past mails I've referred to elsewhere
> I've proposed some Emacs-like "ask" facility for git, but you've
> convinced me that that default would be a bad idea for the "user just
> clicks yes no matter what" reasons you noted.

These replies definitely speak from a perspective common to mine.
This is very dangerous territory and should be handled carefully.

There is also a legitimate user need to use hooks _to contribute_
to some repositories. Hooks are not needed to read the repositories
or interact with them as a document.

The current mechanisms require ad-hoc approaches that are custom to
each project, so there would be value in creating a standard inside
the Git client itself. I think the proposal goes too far in making
this an automatic configuration, either because it assumes trust or
assumes sufficient skepticism on behalf of the users. Either is not
acceptable for the Git project.

Here are the hard lines I draw:

1. This should not happen in "git clone" (other than maybe a message
   over stderr that hooks are available to be configured through a
   different command).

2. Hooks should not update in "git checkout" (other than a message
   that hooks have updated).

3. Whatever document triggers a hook configuration should live at
   HEAD and should not be configured or updated until HEAD has been
   updated by one Git command (git clone, git checkout), time
   passes for the user to inspect the worktree, then _another_
   command (git hooks?) is run manually to reconfigure the hooks.

I think there is a potential way forward if these items are followed.

But I'd like to ask a different question: What problems are these
custom hooks solving, and can Git solve those problems in-core?

If we care about checking commits for format or something, is that
a common enough problem that we could implement it in Git itself and
enable it through a Git config option? It might be interesting to
pursue this direction and maybe we'll solve 80% of the need with
extensions like that.

I'm aware of some hooks that insert things like a Gerrit change-id
that would probably not be appropriate for such an in-core change.

There is always the extreme option of requiring users to use a
specific fork of Git in order to work with your repository. That
has its own pains, believe me. But, it does allow for the ultimate
flexibility in how these things are done. Optional config can be
enabled by default. Hooks can be replaced with in-core functionality.

Thanks,
-Stolee

  reply	other threads:[~2021-04-07 13:09 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-18 22:03 [PATCH] hooks: propose repository owner configured hooks Albert Cui via GitGitGadget
2021-03-18 22:29 ` Junio C Hamano
2021-03-18 23:45   ` Albert Cui
2021-03-19  1:28 ` brian m. carlson
2021-03-19 10:27 ` Ævar Arnfjörð Bjarmason
2021-04-06  0:35   ` Albert Cui
2021-04-07 22:47     ` Ævar Arnfjörð Bjarmason
2021-06-21 19:36       ` Jonathan Tan
2021-06-21 20:35         ` Ævar Arnfjörð Bjarmason
2021-03-26  1:43 ` [PATCH v2] hooks: propose project " Albert Cui via GitGitGadget
2021-03-29 23:20   ` Emily Shaffer
2021-04-01 20:02     ` Albert Cui
2021-03-30 15:24   ` Derrick Stolee
2021-04-05 22:45     ` Albert Cui
2021-04-05 23:09       ` Junio C Hamano
2021-04-05 23:40         ` Albert Cui
2021-04-06  0:13           ` Junio C Hamano
2021-04-06  0:27             ` Albert Cui
2021-04-06 23:15       ` brian m. carlson
2021-04-07  7:53         ` Ævar Arnfjörð Bjarmason
2021-04-07 13:09           ` Derrick Stolee [this message]
2021-04-07 18:40             ` Albert Cui
2021-04-07 20:02               ` Junio C Hamano
2021-04-07 22:23                 ` Ævar Arnfjörð Bjarmason
2021-04-15 16:52             ` Ed Maste
2021-04-15 19:41               ` Junio C Hamano
2021-04-15 20:37                 ` Ed Maste
2021-04-15 20:50                   ` Junio C Hamano
2021-04-15 22:28                   ` brian m. carlson
2021-04-02  9:59   ` Ævar Arnfjörð Bjarmason
2021-04-05 23:42     ` Albert Cui
2021-04-02 10:30   ` Ævar Arnfjörð Bjarmason
2021-04-03  0:58     ` Albert Cui
2021-04-24  1:38   ` [PATCH v3] " Albert Cui via GitGitGadget
2021-04-28  2:48     ` Junio C Hamano
2021-05-05 19:11     ` [PATCH v4] " Albert Cui via GitGitGadget
2021-06-03  3:31       ` Jonathan Tan
2021-06-03 20:16         ` Albert Cui
2021-06-03 22:10           ` Jonathan Tan

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=9af3770f-204b-253b-d7f2-c9d5e7cf2fdb@gmail.com \
    --to=stolee@gmail.com \
    --cc=albertqcui@gmail.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=sandals@crustytoothpaste.net \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public 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).