Bug 1875639

Summary: git ignores NO_PROXY environment variable inside a container
Product: Red Hat Enterprise Linux 8 Reporter: Adam Kaplan <adam.kaplan>
Component: gitAssignee: Ondřej Pohořelský <opohorel>
Status: CLOSED NOTABUG QA Contact: RHEL CS Apps Subsystem QE <rhel-cs-apps-subsystem-qe>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 8.2CC: pcahyna
Target Milestone: rc   
Target Release: 8.0   
Hardware: x86_64   
OS: Linux   
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-09-14 11:29:04 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 1873327    
Bug Blocks:    

Description Adam Kaplan 2020-09-04 00:41:20 UTC
Description of problem:

git commands ignore the NO_PROXY environment variable if it has been set when run inside a container, such as ubi8.

This breaks most git actions when run behind a proxy, such as those found in many OpenShift deployments. This impacts OpenShift Builds, OpenShift Pipelines, and those who deploy the upstream Tekton project on Kubernetes.

Version-Release number of selected component (if applicable):


How reproducible: Always

Steps to Reproduce:

1. Start a ubi8 container with podman:

$ podman run --rm -it registry.access.redhat.com/ubi8/ubi /bin/bash

2. Install git in the container - `# yum install -y git`
3. Add "bad" _PROXY environment variables:

# export HTTP_PROXY=http://user:pass@bad.proxy
# export HTTPS_PROXY=https://user:pass@bad.proxy

4. Add Github as an ignorable proxy domain:

# export NO_PROXY=github.com

5. Clone a github repo:

# mkdir -p /tmp/clone-test
# cd /tmp/clone-test
# git clone https://github.com/sclorg/nodejs-ex.git
# echo $?

Actual results:

# git clone https://github.com/sclorg/nodejs-ex.git
Cloning into 'nodejs-ex'...
# echo $?

Expected results:

Git clone succeeds, bypassing the proxy.

Additional info:

git version 2.18.4

curl --version
curl 7.61.1 (x86_64-redhat-linux-gnu) libcurl/7.61.1 OpenSSL/1.1.1c zlib/1.2.11 brotli/1.0.6 libidn2/2.2.0 libpsl/0.20.2 (+libidn2/2.0.5) libssh/0.9.0/openssl/zlib nghttp2/1.33.0
Release-Date: 2018-09-05
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp 
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz brotli TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL Metalink

Comment 1 Adam Kaplan 2020-09-04 01:17:36 UTC
Verbose logs do not seem to indicate a problem:

# GIT_CURL_VERBOSE=1 GIT_TRACE=1 git clone https://github.com/sclorg/nodejs-ex.git
01:14:29.997128 git.c:415               trace: built-in: git clone https://github.com/sclorg/nodejs-ex.git
Cloning into 'nodejs-ex'...
01:14:30.005665 run-command.c:643       trace: run_command: git-remote-https origin https://github.com/sclorg/nodejs-ex.git
* Couldn't find host github.com in the .netrc file; using defaults
*   Trying
* Connected to github.com ( port 443 (#0)
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
# echo $?

Comment 2 Ondřej Pohořelský 2020-09-07 14:23:21 UTC
I have tried to replicate this issue in ubi8 container, Fedora container and even full Fedora Workstation installation.
In ubi8 we have git-2.18.4, in Fedora there is git-2.28.0 which is the latest stable release as of today.
Issue seems to be present everywhere. I'll try to investigate further and possibly report this to upstream.

Comment 3 Ondřej Pohořelský 2020-09-11 12:27:27 UTC
I've reported this possible bug to upstream[0]. I'm not completely sure if this behaviour is expected or not.
However I've found a workaround. Add the URL you want to bypass proxy into the .gitconfig.

IOW open ~/.gitconfig and insert these two lines:

[http "https://github.com/"]
        proxy = ""


Comment 4 Ondřej Pohořelský 2020-09-14 11:29:04 UTC
Upstream investigated this issue and it is not a Git bug, but a Curl bug[0].
It has been already reported in Bug 1873327 and fixed by upstream[1].