no_proxy=::1 is not honored by curl in Bionic and earlier versions

Bug #1908136 reported by Balint Reczey
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Auto Package Testing
Fix Released
Undecided
Unassigned
curl (Ubuntu)
Fix Released
Undecided
Unassigned
Xenial
New
Undecided
Unassigned
Bionic
New
Undecided
Unassigned
Focal
Fix Released
Undecided
Unassigned

Bug Description

Bionic:

env no_proxy=::1 http_proxy=http://foo:8080 curl -v http://[::1]:80/bar.html
* Could not resolve proxy: foo
* Closing connection 0
curl: (5) Could not resolve proxy: foo

Focal:

$ env no_proxy=::1 http_proxy=http://foo:8080 curl -v http://[::1]:80/bar.html
* Uses proxy env variable no_proxy == '::1'
* Trying ::1:80...
* TCP_NODELAY set
* Immediate connect fail for ::1: Network is unreachable
* Closing connection 0
curl: (7) Couldn't connect to server

Related branches

Revision history for this message
Balint Reczey (rbalint) wrote :
Changed in curl (Ubuntu Focal):
status: New → Fix Released
Changed in curl (Ubuntu):
status: New → Fix Released
Revision history for this message
Balint Reczey (rbalint) wrote :

Recently the autopkgtest infrastructure configuration has been changed to add ::1 to no_proxy. This works on Focal and up, but breaks unknown number of tests in Bionic and earlier releases.

commit f3679e7609b2f03d59aca28fe7329e4228350200
Author: Steve Langasek <email address hidden>
Date: Fri Dec 4 12:00:02 2020 -0800

    Include ipv6 localhost in the list of addresses not to use the proxy for.

    This fixes schleuder autopkgtest failure on armhf, which tries to connect
    to [::1]:4443 and fails because it's routed to the proxy.

    This failure does not affect the VM-based autopkgtest runners because
    containers also have some strangeness regarding binding to ::1 being treated
    as bindv6only=1, and schleuder's test only requires that ipv4 *or* ipv6
    succeeds; but the change is appropriate across all architectures.

 lxc-slave-admin/setup-adt-lxc.commands | 2 +-
 tools/armhf-lxd-slave.userdata | 2 +-
 worker-config-production/worker-bos01-arm64.conf | 2 +-
 worker-config-production/worker-bos01-ppc64el.conf | 2 +-
 worker-config-production/worker-bos01-s390x.conf | 2 +-
 worker-config-production/worker-bos01.conf | 2 +-
 worker-config-production/worker-bos02-arm64.conf | 2 +-
 worker-config-production/worker-bos02-ppc64el.conf | 2 +-
 worker-config-production/worker-bos02-s390x.conf | 2 +-
 worker-config-production/worker-canonistack.conf | 2 +-
 worker-config-production/worker-lxd.conf | 2 +-
 worker-config-production/worker.conf | 2 +-
 12 files changed, 12 insertions(+), 12 deletions(-)

Balint Reczey (rbalint)
summary: - no_proxy=::1 is not honored in Bionic and earlier versions
+ no_proxy=::1 is not honored by curl in Bionic and earlier versions
Balint Reczey (rbalint)
tags: added: rls-bb-incoming rls-x-incoming
Revision history for this message
Steve Langasek (vorlon) wrote :

While there is a curl bug here that older versions do not honor ipv6 addresses in no_proxy, there's no information here that explains why you think this caused a *regression* in autopkgtests. Tests attempting to use the http proxy to connect to ::1 will fail with or without adding ::1 to no_proxy. So how does having it listed in no_proxy cause a regression?

Revision history for this message
Balint Reczey (rbalint) wrote :

Maybe it was just a coincidence, but those regressions disappeared immediately when reverting the ::1 addition:

LP: #1907959
https://autopkgtest.ubuntu.com/packages/s/samtools/bionic/amd64

LP: #1907955
https://autopkgtest.ubuntu.com/packages/r/ruby2.5/bionic/amd64

Since you are around would you be so kind and address @laney's more than wone yeare old comments in the following MR so the cowboy deployed can be dropped and does not make extra work for @laney to land fixes?
https://code.launchpad.net/~ubuntu-release/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/376587

Iain Lane (laney)
Changed in auto-package-testing:
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.