Revert "git: git-replacement-native: depend on ca-certificate"

This reverts commit 2e99ffda70fd95b5eab3de47048032349cd66f4b.

git-replacement-native is used only to provide a newer version than may
be installed on the system; apart from that, it should work more or less
the same. In particular, it is using the host system's /etc/gitconfig;
it should also use the system CA certificates, otherwise it will break
HTTPS connections in environments that need local certificates, for
example for a corporate HTTP proxy.

Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
---
 meta/recipes-devtools/git/git_2.49.0.bb | 3 ---
 1 file changed, 3 deletions(-)

You shouldn't just revert things like that, without explaining how
this will avoid bringing back the original problem :-/

Alex

On Thu, 20 Mar 2025 at 10:30, Matthias Schiffer via
lists.openembedded.org
<matthias.schiffer=ew.tq-group.com@lists.openembedded.org> wrote:
>
> This reverts commit 2e99ffda70fd95b5eab3de47048032349cd66f4b.
>
> git-replacement-native is used only to provide a newer version than may
> be installed on the system; apart from that, it should work more or less
> the same. In particular, it is using the host system's /etc/gitconfig;
> it should also use the system CA certificates, otherwise it will break
> HTTPS connections in environments that need local certificates, for
> example for a corporate HTTP proxy.
>
> Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
> ---
>  meta/recipes-devtools/git/git_2.49.0.bb | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/meta/recipes-devtools/git/git_2.49.0.bb b/meta/recipes-devtools/git/git_2.49.0.bb
> index 66082d0bde..2ca8711f75 100644
> --- a/meta/recipes-devtools/git/git_2.49.0.bb
> +++ b/meta/recipes-devtools/git/git_2.49.0.bb
> @@ -4,7 +4,6 @@ DESCRIPTION = "Git is a free and open source distributed version control system
>  SECTION = "console/utils"
>  LICENSE = "GPL-2.0-only & GPL-2.0-or-later & BSD-3-Clause & MIT & BSL-1.0 & LGPL-2.1-or-later"
>  DEPENDS = "openssl zlib"
> -DEPENDS:class-native += "ca-certificates"
>
>  PROVIDES:append:class-native = " git-replacement-native"
>
> @@ -97,7 +96,6 @@ perl_native_fixup () {
>
>  REL_GIT_EXEC_PATH = "${@os.path.relpath(libexecdir, bindir)}/git-core"
>  REL_GIT_TEMPLATE_DIR = "${@os.path.relpath(datadir, bindir)}/git-core/templates"
> -REL_GIT_SSL_CAINFO = "${@os.path.relpath(sysconfdir, bindir)}/ssl/certs/ca-certificates.crt"
>
>  do_install:append:class-target () {
>         perl_native_fixup
> @@ -106,7 +104,6 @@ do_install:append:class-target () {
>  do_install:append:class-native() {
>         create_wrapper ${D}${bindir}/git \
>                 GIT_EXEC_PATH='`dirname $''realpath`'/${REL_GIT_EXEC_PATH} \
> -               GIT_SSL_CAINFO='`dirname $''realpath`'/${REL_GIT_SSL_CAINFO} \
>                 GIT_TEMPLATE_DIR='`dirname $''realpath`'/${REL_GIT_TEMPLATE_DIR}
>  }
>
> --
> TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
> Amtsgericht München, HRB 105018
> Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
> https://www.tq-group.com/
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#213375): https://lists.openembedded.org/g/openembedded-core/message/213375
> Mute This Topic: https://lists.openembedded.org/mt/111805445/1686489
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

On Thu, 2025-03-20 at 10:29 +0100, Matthias Schiffer via lists.openembedded.org wrote:
> This reverts commit 2e99ffda70fd95b5eab3de47048032349cd66f4b.
> 
> git-replacement-native is used only to provide a newer version than may
> be installed on the system; apart from that, it should work more or less
> the same. In particular, it is using the host system's /etc/gitconfig;
> it should also use the system CA certificates, otherwise it will break
> HTTPS connections in environments that need local certificates, for
> example for a corporate HTTP proxy.
> 
> Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
> ---
>  meta/recipes-devtools/git/git_2.49.0.bb | 3 ---
>  1 file changed, 3 deletions(-)

This is going to turn into a battle where you and Max both alternate
with revert requests as you're seeing different breakage as far as I
can tell.

The original commit message says:

"""
git is delegating webacces for URLs using TLS to libcurl.
However our native libcurl build does not find a ca-certificate.crt
unless its curl-native work dir still exists and thus git will fail.
If a recipe uses AUTOREV with a git repo using https as its protocol
parsing of that recipe will fail fetching the latest HEAD.

Fix that by depending on ca-certificate and give its location
to libcurl via git's envrironment variable GIT_SSL_CAINFO.
"""

so the question is, does curl-native now use the system certificates?

Cheers,

Richard

On Thu, 2025-03-20 at 09:42 +0000, Richard Purdie wrote:
> 
> On Thu, 2025-03-20 at 10:29 +0100, Matthias Schiffer via lists.openembedded.org wrote:
> > This reverts commit 2e99ffda70fd95b5eab3de47048032349cd66f4b.
> > 
> > git-replacement-native is used only to provide a newer version than may
> > be installed on the system; apart from that, it should work more or less
> > the same. In particular, it is using the host system's /etc/gitconfig;
> > it should also use the system CA certificates, otherwise it will break
> > HTTPS connections in environments that need local certificates, for
> > example for a corporate HTTP proxy.
> > 
> > Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
> > ---
> >  meta/recipes-devtools/git/git_2.49.0.bb | 3 ---
> >  1 file changed, 3 deletions(-)
> 
> This is going to turn into a battle where you and Max both alternate
> with revert requests as you're seeing different breakage as far as I
> can tell.
> 
> The original commit message says:
> 
> """
> git is delegating webacces for URLs using TLS to libcurl.
> However our native libcurl build does not find a ca-certificate.crt
> unless its curl-native work dir still exists and thus git will fail.
> If a recipe uses AUTOREV with a git repo using https as its protocol
> parsing of that recipe will fail fetching the latest HEAD.
> 
> Fix that by depending on ca-certificate and give its location
> to libcurl via git's envrironment variable GIT_SSL_CAINFO.
> """
> 
> so the question is, does curl-native now use the system certificates?
> 
> Cheers,

Ugh, I had thought I had tested this properly, but there is indeed still
something weird going on with curl-native's certificates. Please disregard this
patch for now, I'll have to look into the issue again.

Best,
Matthias




> 
> Richard

Hi

On Thu, 2025-03-20 at 10:53 +0100, Matthias Schiffer wrote:
> On Thu, 2025-03-20 at 09:42 +0000, Richard Purdie wrote:
> > 
> > On Thu, 2025-03-20 at 10:29 +0100, Matthias Schiffer via lists.openembedded.org wrote:
> > > This reverts commit 2e99ffda70fd95b5eab3de47048032349cd66f4b.
> > > 
> > > git-replacement-native is used only to provide a newer version than may
> > > be installed on the system; apart from that, it should work more or less
> > > the same. In particular, it is using the host system's /etc/gitconfig;
> > > it should also use the system CA certificates, otherwise it will break
> > > HTTPS connections in environments that need local certificates, for
> > > example for a corporate HTTP proxy.
> > > 
> > > Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
> > > ---
> > >  meta/recipes-devtools/git/git_2.49.0.bb | 3 ---
> > >  1 file changed, 3 deletions(-)
> > 
> > This is going to turn into a battle where you and Max both alternate
> > with revert requests as you're seeing different breakage as far as I
> > can tell.
> > 
> > The original commit message says:
> > 
> > """
> > git is delegating webacces for URLs using TLS to libcurl.
> > However our native libcurl build does not find a ca-certificate.crt
> > unless its curl-native work dir still exists and thus git will fail.
> > If a recipe uses AUTOREV with a git repo using https as its protocol
> > parsing of that recipe will fail fetching the latest HEAD.
> > 
> > Fix that by depending on ca-certificate and give its location
> > to libcurl via git's envrironment variable GIT_SSL_CAINFO.
> > """
> > 
> > so the question is, does curl-native now use the system certificates?
> > 
> > Cheers,
> 
> Ugh, I had thought I had tested this properly, but there is indeed still
> something weird going on with curl-native's certificates. Please disregard this
> patch for now, I'll have to look into the issue again.
> 
> Best,
> Matthias

I don't really remember the actual set-up I run into the issue which was
solved by the commit.

It for sure involved:
- A Fedora host
- A SRC_URI with git:// using HTTPS AND SRCREV=AUTOREV (which we use for our nightly CI)
- `INHERIT += "rm_work"`in local.conf

Which then failed to retrieve the hash of latest HEAD.

Ping me if you need me to try to get into the failing set-up again and to test
fixes which help both our use cases.

Regards
Max
> 
> 
> 
> 
> > 
> > Richard
>