From: Albert Cui <email@example.com> To: Derrick Stolee <firstname.lastname@example.org> Cc: "Ævar Arnfjörð Bjarmason" <email@example.com>, "brian m. carlson" <firstname.lastname@example.org>, "Albert Cui via GitGitGadget" <email@example.com>, firstname.lastname@example.org Subject: Re: [PATCH v2] hooks: propose project configured hooks Date: Wed, 7 Apr 2021 11:40:34 -0700 [thread overview] Message-ID: <CAMbkP-QDzCQbekBf7tdN6zccDU8xnXdYFAuSZSbsdS6hSumghA@mail.gmail.com> (raw) In-Reply-To: <email@example.com> On Wed, Apr 7, 2021 at 6:09 AM Derrick Stolee <firstname.lastname@example.org> wrote: > > 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). > To Ævar's point, maybe it would help to separate the two user bases of project configured hooks. (1) Employee working at BigCorp. They are cloning from a trusted remote on company machines where the company controls what gets installed and how Git is configured. Their motivation is to make changes to their local clone and submit changes to a central repository. (2) Git user cloning from any remote e.g. GitHub. They could have many motivations: to make changes, to inspect the code, to simply just build. I agree that this feature should not get in the way of users (2), or expose them to new attack surfaces, users who may have no desire to have project configured hooks. That said, I think we can still get into a world that better serves users (1). I proposed this upthread and would like feedback on it (I realize these examples still assume one config for every branch, but you get the gist): Case 1. Opt-into clone setup via config ``` #~/.gitconfig [hook] allowCloneInstallFromRemote = $REMOTE ``` IFF $REMOTE matches the config, then `git clone $REMOTE --setup-hooks` works: ``` $ git clone $remote --setup-hooks The following hooks were installed from `origin` ($ORIGIN_URL): pre-push: $GIT_ROOT/pre_push.sh ``` Case 2. Without the config opt-in for clone setup ``` $ git clone $remote # using --setup-hooks here wouldn't change behavior since there's no config opt-in Remote `origin` ($ORIGIN_URL) suggests the following hooks: pre-push: $GIT_ROOT/pre_push.sh If you wish to install them, run `git hook setup origin`. To always ignore hooks from `origin`, run `git hook ignore origin`. ``` Case 3. Opting into updates You could imagine a similar config, e.g. allowAutoUpdateFromRemote that allows Git to prompt users to consent to auto-updating hooks on "git checkout" with this type of behavior: .... $ git checkout The following hooks were updated from remote `origin` ($ORIGIN_URL): pre-push: $GIT_ROOT/pre_push.sh If you wish to install them, run `git hook setup origin`. # The below only appears if allowAutoUpdateFromRemote is set for $ORIGIN_URL If you wish to always accept hooks from `origin`, run `git hook setup --always origin`. You should only do this if you trust code changes from origin. To always ignore hooks from `origin`, run `git hook ignore origin`. .... > 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 want to separate the requirement from the implementation. What I'm hearing is that "users should have a chance to inspect the suggested hook before consenting to installing it." That doesn't necessarily require the configuration to be in HEAD. Again, that's reasonable for users (2) but doesn't seem necessary for users (1) if we have the correct opt-ins. > 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. > A `git lint` command would cover a lot of the use cases, but to your point, there are others. Thanks, Albert
next prev parent reply other threads:[~2021-04-07 18:40 UTC|newest] Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-18 22:03 [PATCH] hooks: propose repository owner " 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 2021-04-07 18:40 ` Albert Cui [this message] 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=CAMbkP-QDzCQbekBf7tdN6zccDU8xnXdYFAuSZSbsdS6hSumghA@mail.gmail.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH v2] hooks: propose project configured hooks' \ /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
Code repositories for project(s) associated with this 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).