git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Taylor Blau <me@ttaylorr.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Philip Oakley <philipoakley@iee.email>,
	Johannes Schindelin <johannes.schindelin@gmx.de>,
	Guy Maurel <guy.j@maurel.de>,
	git@vger.kernel.org
Subject: Re: a problem with git describe
Date: Mon, 25 Apr 2022 21:52:50 -0400	[thread overview]
Message-ID: <YmdQcrl/uu7HFBlc@nand.local> (raw)
In-Reply-To: <xmqqczh73hns.fsf@gitster.g>

On Sat, Apr 23, 2022 at 09:09:59AM -0700, Junio C Hamano wrote:
> Philip Oakley <philipoakley@iee.email> writes:
>
> >> guy@renard ~/Software/uncrustify $ sudo git describe --always --dirty
> > ...
> > There has also been added an escape hatch of allowing "*" for the
> > permitted safe directories. but do check the updated manuals, and the
> > git mailing list archive (update the search in the above link).
>
> In this particular case, I do not think '*' is needed, but you need
> to be careful here.  Whose configuration are you suggesting to add
> such an entry?  Yourself?  ~root/.gitconfig?
>
> I wonder if we should loosen "the same owner" check somewhat to
> cover this situation better.  I expect people also run the
> installation in repositories they own with "sudo make install",
> and complaining "euid does not own that repository" when it is
> merely because they are running as root (and their real identity
> is still in ruid) feels a bit too strict to be useful.

I was thinking about this today and realized that my original train of
thought along the lines of "ignore the new safety check when the current
user has higher permissions than the user who owns the repository we're
working in" was misguided.

What about loosening the check in a different way? Instead of causing
Git to abort early, what if we:

  - skipped reading the repository's configuration and hooks (unless
    safe.directory includes $CWD)
  - emit a warning (which goes away when safe.directory contains $CWD)
  - otherwise continue executing as normal

That would unbreak the case of $(git describe ...) in our Makefile in
this instance, without opening ourselves up to execution-via-config.

Though I think we'd have to be slightly more careful than that, since
we definitely _do_ want to read repository format extensions.

I'm hesitant to recommend reading some parts of the configuration
without others, though this is slightly different than that. Instead of
saying "read every entry of config except core.editor, core.pager,
core.alternateRefsCommand, core.fsmonitor" and so on, this says "when
operating in a repository not owned by the current user (or the
repository is in our global safe.directory list) only read repository
format extensions, but ignore everything else in config and hooks".

> Dscho, what do you think?

I'd be curious to hear what Johannes thinks of your original mail as
well as my own.

Thanks,
Taylor

  parent reply	other threads:[~2022-04-26  1:52 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-23  9:12 a problem with git describe Guy Maurel
2022-04-23 11:27 ` Philip Oakley
2022-04-23 16:09   ` Junio C Hamano
2022-04-23 23:44     ` Junio C Hamano
2022-04-25  2:01       ` Carlo Marcelo Arenas Belón
2022-04-25  5:05         ` SZEDER Gábor
2022-04-25  6:03           ` Carlo Marcelo Arenas Belón
2022-04-25  6:39         ` Junio C Hamano
2022-04-25  7:02           ` Carlo Marcelo Arenas Belón
2022-04-25  8:40             ` Carlo Marcelo Arenas Belón
2022-04-25 15:11               ` Guy Maurel
2022-04-26 15:43               ` Johannes Schindelin
2022-04-26 15:56                 ` rsbecker
2022-04-26 16:35                 ` Carlo Arenas
2022-04-26 16:46                   ` Junio C Hamano
2022-04-26 17:15                     ` Carlo Arenas
2022-04-26 15:45       ` Johannes Schindelin
2022-04-26 16:25         ` Junio C Hamano
2022-04-26  1:52     ` Taylor Blau [this message]
2022-04-26 15:41       ` Johannes Schindelin
2022-04-26 15:50         ` Taylor Blau
2022-04-26 15:30     ` Johannes Schindelin
2022-04-26 15:36       ` Junio C Hamano

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YmdQcrl/uu7HFBlc@nand.local \
    --to=me@ttaylorr.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=guy.j@maurel.de \
    --cc=johannes.schindelin@gmx.de \
    --cc=philipoakley@iee.email \
    /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.
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 NNTP newsgroup(s).