git safe.directory

git safe.directory

[Mark Wielaard]

Hi,

Earlier this week git got upgraded on sourceware to include support
for safe.directory. Joel noticed an issue with the gdbadmin cron job
for the binutils-gdb.git repo. It would complain with:

fatal: detected dubious ownership in repository at
'/sourceware1/projects/src-home/binutils-gdb.git'

Given this repo is shared between different projects and users it is
"expected" that the git directory/config might be writable by someone
else in this case. We believe that doing the following for the
gdbadmin user is the appropriate workaround for now:

  git config --global --add safe.directory \
    /sourceware1/projects/src-home/binutils-gdb.git

I looked over other repos, cron jobs and hooks, but couldn't find any
other issue with this new "feature". The git operations executed on
them either don't use the config file or the operations are only
executed by the actual user "owning" the git repo config file.

But if you notice any 'detected dubious ownership' of any git
operations please report and/or check the dir/config file ownership
and/or add a 'safe.directory' workaround for the affected user.

Of course you can also move some operations to the separate
snapshots.sourceware.org server if it doesn't require access to the
repo directly.

Cheers,

Mark

Re: git safe.directory

[Mark Wielaard]

Hi,

On Sun, 2023-05-21 at 19:21 +0200, Mark Wielaard via Overseers wrote:
> Earlier this week git got upgraded on sourceware to include support
> for safe.directory. Joel noticed an issue with the gdbadmin cron job
> for the binutils-gdb.git repo. It would complain with:
> 
> fatal: detected dubious ownership in repository at
> '/sourceware1/projects/src-home/binutils-gdb.git'
> 
> Given this repo is shared between different projects and users it is
> "expected" that the git directory/config might be writable by someone
> else in this case. We believe that doing the following for the
> gdbadmin user is the appropriate workaround for now:
> 
>   git config --global --add safe.directory \
>     /sourceware1/projects/src-home/binutils-gdb.git
> 
> I looked over other repos, cron jobs and hooks, but couldn't find any
> other issue with this new "feature". The git operations executed on
> them either don't use the config file or the operations are only
> executed by the actual user "owning" the git repo config file.

I missed the gcc-wwwdocs post-receive hook.
Tobias noticed that commits don't update the website anymore.
And the /www/gcc/update.log do indeed contains:
fatal: detected dubious ownership in repository at
'/sourceware1/www/gcc/wwwdocs-checkout'

For now I have added as a workaround to /etc/gitconfig:

[safe]
	directory = /sourceware1/www/gcc/wwwdocs-checkout

Which should make it possible for anybody to run the post-receive hook
again. But I think it would be better if we change things so that only
gccadmin (who owns the wwwdocs-checkout repo) would do the updates
(from a cronjob?)

Note, I didn't try to replay the last few failing commits, so someone
should still do that to get the gcc.gnu.org website updated.

> But if you notice any 'detected dubious ownership' of any git
> operations please report and/or check the dir/config file ownership
> and/or add a 'safe.directory' workaround for the affected user.
> 
> Of course you can also move some operations to the separate
> snapshots.sourceware.org server if it doesn't require access to the
> repo directly.

Cheers,

Mark

Re: git safe.directory

[Mark Wielaard]

Hi,

On Mon, May 22, 2023 at 06:13:37PM +0200, Mark Wielaard via Overseers wrote:
> I missed the gcc-wwwdocs post-receive hook.
> Tobias noticed that commits don't update the website anymore.
> And the /www/gcc/update.log do indeed contains:
> fatal: detected dubious ownership in repository at
> '/sourceware1/www/gcc/wwwdocs-checkout'
> 
> For now I have added as a workaround to /etc/gitconfig:
> 
> [safe]
> 	directory = /sourceware1/www/gcc/wwwdocs-checkout
> 
> Which should make it possible for anybody to run the post-receive hook
> again. But I think it would be better if we change things so that only
> gccadmin (who owns the wwwdocs-checkout repo) would do the updates
> (from a cronjob?)
> 
> Note, I didn't try to replay the last few failing commits, so someone
> should still do that to get the gcc.gnu.org website updated.

I now looked and processed the following 3 commits, which didn't auto
update:

commit 4013044e02d0b04430531bb604ddb201c51cb238
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Mon May 22 10:49:27 2023 +0200

    Mention 11 branch is frozen.

commit 6196747803d192744097590d6703a94def0030f4
Author: Tobias Burnus <tobias@codesourcery.com>
Date:   Mon May 22 10:08:14 2023 +0200

    git.html: Move OG12 to OG13, briefly mention old branches

commit fd86c2b52a4fa69ac5a7755b55934c6a9c3e7cd7
Author: Gerald Pfeifer <gerald@pfeifer.com>
Date:   Sun May 21 20:40:19 2023 +0200

    readings: Adjust link to Arm architectures

Which effectively was just calling /www/gcc/bin/preprocess on
readings.html, git.html and index.html.

Cheers,

Mark