GIT_CONFIG_PARAMETERS does not work

GIT_CONFIG_PARAMETERS does not work

[Chen, Qi]

[-- Attachment #1: Type: text/plain, Size: 1831 bytes --]

Hi Ross & Richard,

I'm building hardknott on host with git 2.36.0. And gnulib do_install fails with git unsafe repo error.
The same error could be reproduced by reverting Khem's fix for gnulib do_install and building gnulib against master.

| fatal: unsafe repository ('/ala-lpggp72/qichen/Yocto/builds/build-master/tmp/work/core2-64-poky-linux/gnulib/2018-03-07.03-r0/git' is owned by someone else)
| To add an exception for this directory, call:
|
|       git config --global --add safe.directory /ala-lpggp72/qichen/Yocto/builds/build-master/tmp/work/core2-64-poky-linux/gnulib/2018-03-07.03-r0/git


I can see that we have already been trying to use the GIT_CONFIG_PARAMETERS to solve this issue. Related changes are:
"""
+# Treat all directories are safe, as during fakeroot tasks git will run as
+# root so recent git releases (eg 2.30.3) will refuse to work on repositories. See
+# https://github.com/git/git/commit/8959555cee7ec045958f9b6dd62e541affb7e7d9 for
+# further details.
+export GIT_CONFIG_PARAMETERS="'safe.directory=*'"
"""

However, following the link above and I can see that the commit message says:
"""
    The `safe.directory` config setting is only respected in the system and
    global configs, not from repository configs or via the command-line, and
can have multiple values to allow for multiple shared repositories.
"""

If I understand it correctly, this means that the command line environment variables have no effect.
Also, I figure if some user could set his/her own environment variable to bypass this security check, then this security check does not make much sense.

So I think we should use the intercept script approach and add back the following line.
PATH:prepend:task-install = "${COREBASE}/scripts/git-intercept:"

What do you think?

Regards,
Qi

[-- Attachment #2: Type: text/html, Size: 5152 bytes --]

Re: GIT_CONFIG_PARAMETERS does not work

[Ross Burton]

[-- Attachment #1: Type: text/plain, Size: 2705 bytes --]

Yes, I was actually going to send the patch for this today. :)

Ross
________________________________
From: Chen, Qi <Qi.Chen@windriver.com>
Sent: Friday, May 6, 2022 4:44:32 AM
To: openembedded-core@lists.openembedded.org <openembedded-core@lists.openembedded.org>
Cc: Ross Burton <Ross.Burton@arm.com>; richard.purdie@linuxfoundation.org <richard.purdie@linuxfoundation.org>; raj.khem@gmail.com <raj.khem@gmail.com>
Subject: GIT_CONFIG_PARAMETERS does not work


Hi Ross & Richard,



I’m building hardknott on host with git 2.36.0. And gnulib do_install fails with git unsafe repo error.

The same error could be reproduced by reverting Khem’s fix for gnulib do_install and building gnulib against master.



| fatal: unsafe repository ('/ala-lpggp72/qichen/Yocto/builds/build-master/tmp/work/core2-64-poky-linux/gnulib/2018-03-07.03-r0/git' is owned by someone else)

| To add an exception for this directory, call:

|

|       git config --global --add safe.directory /ala-lpggp72/qichen/Yocto/builds/build-master/tmp/work/core2-64-poky-linux/gnulib/2018-03-07.03-r0/git





I can see that we have already been trying to use the GIT_CONFIG_PARAMETERS to solve this issue. Related changes are:

“””

+# Treat all directories are safe, as during fakeroot tasks git will run as

+# root so recent git releases (eg 2.30.3) will refuse to work on repositories. See

+# https://github.com/git/git/commit/8959555cee7ec045958f9b6dd62e541affb7e7d9 for

+# further details.

+export GIT_CONFIG_PARAMETERS="'safe.directory=*'"

“””



However, following the link above and I can see that the commit message says:

“””

    The `safe.directory` config setting is only respected in the system and

    global configs, not from repository configs or via the command-line, and

can have multiple values to allow for multiple shared repositories.

“””



If I understand it correctly, this means that the command line environment variables have no effect.

Also, I figure if some user could set his/her own environment variable to bypass this security check, then this security check does not make much sense.



So I think we should use the intercept script approach and add back the following line.

PATH:prepend:task-install = "${COREBASE}/scripts/git-intercept:"



What do you think?



Regards,

Qi

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

[-- Attachment #2: Type: text/html, Size: 5126 bytes --]

Re: [OE-core] GIT_CONFIG_PARAMETERS does not work

[Richard Purdie]

On Fri, 2022-05-06 at 03:44 +0000, Chen Qi wrote:
> Hi Ross & Richard,
>  
> I’m building hardknott on host with git 2.36.0. And gnulib do_install fails
> with git unsafe repo error.
> The same error could be reproduced by reverting Khem’s fix for gnulib
> do_install and building gnulib against master.
>  
> | fatal: unsafe repository ('/ala-lpggp72/qichen/Yocto/builds/build-
> master/tmp/work/core2-64-poky-linux/gnulib/2018-03-07.03-r0/git' is owned by
> someone else)
> | To add an exception for this directory, call:
> |
> |       git config --global --add safe.directory /ala-
> lpggp72/qichen/Yocto/builds/build-master/tmp/work/core2-64-poky-
> linux/gnulib/2018-03-07.03-r0/git
>  
>  
> I can see that we have already been trying to use the GIT_CONFIG_PARAMETERS to
> solve this issue. Related changes are:
> “””
> +# Treat all directories are safe, as during fakeroot tasks git will run as
> +# root so recent git releases (eg 2.30.3) will refuse to work on
> repositories. See
> +# https://github.com/git/git/commit/8959555cee7ec045958f9b6dd62e541affb7e7d9
> for
> +# further details.
> +export GIT_CONFIG_PARAMETERS="'safe.directory=*'"
> “””
>  
> However, following the link above and I can see that the commit message says:
> “””
>     The `safe.directory` config setting is only respected in the system and
>     global configs, not from repository configs or via the command-line, and
> can have multiple values to allow for multiple shared repositories.
> “””
>  
> If I understand it correctly, this means that the command line environment
> variables have no effect.
> Also, I figure if some user could set his/her own environment variable to
> bypass this security check, then this security check does not make much sense.
>  
> So I think we should use the intercept script approach and add back the
> following line.
> PATH:prepend:task-install = "${COREBASE}/scripts/git-intercept:"
>  
> What do you think?

That patch isn't enough, we'll need the global intercept approach I had in later
patches.

Cheers,

Richard