Re: a problem with git describe

[Carlo Arenas <carenas@gmail.com>]

On Tue, Apr 26, 2022 at 8:43 AM Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>
> Maybe a better idea for the `sudo` scenario would be to make use of
> `SUDO_UID` (assuming that no adversary can gain control over the user's
> environment variables)?

I like this idea, and will prepare a formal patch soon also including DOAS_UID
for anyone that might have used that instead of sudo to elevate their
privileges.

Still think that (since we are already touching this) removing the
restriction to
root owned directories might make sense though, ex the following (unrealistic
example) would work:

  $ mkdir -p r/t
  $ sudo chown root r
  $ cd r && sudo git init
  $ cd t && git status

IMHO any directories above that are owned by root and might have a git
configuration must be safe, and therefore shouldn't need to be
explicitly exempted.

I also think that Taylor's suggestion to ignore and warn instead of
abort might be
a better solution to the "configuration file shouldn't be trusted"
issue which is at
the root of this regression, and obviously doing that would make this
change less
critical (users will just get a warning instead of being prevented to
do what worked
for them before and is a safe use case)

Carlo

PS. yes hardcoding uid 0 as root would be avoided, not sure where yet though