Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bugzilla DB migration completed. Please report issues to Infra team via email via infra@gentoo.org or IRC
Bug 659746 - sys-apps/portage Key refresh and authenticating proxy
Summary: sys-apps/portage Key refresh and authenticating proxy
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal major (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 650144
  Show dependency tree
 
Reported: 2018-07-01 08:52 UTC by Pierre-Yves Bonnetain-Nesterenko
Modified: 2020-06-08 17:52 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pierre-Yves Bonnetain-Nesterenko 2018-07-01 08:52:45 UTC
Hello,

We are behind an authenticating proxy for web browsing and the like. The /etc/portage/make.conf file contains the proper http_proxy and https_proxy variables definitions, so sources and patches downloading has been working for several years.

With the new 'tree verify' feature (using portage 2.3.24-r1), the portage tree sync always fails, the key refresh ending on timeout trying to refresh the keys without going through the proxy.

$ eix-sync
 * Running emerge --sync
>>> Syncing repository 'gentoo' into '/usr/portage'...
 * Using keys from /usr/share/openpgp-keys/gentoo-release.asc
 * Refreshing keys from keyserver ...OpenPGP keyring refresh failed:
gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net
gpg: keyserver refresh failed: Connection timed out

[... several failures ...]

!!! Manifest verification impossible due to keyring problem:
OpenPGP keyring refresh failed:
gpg: refreshing 4 keys from hkps://hkps.pool.sks-keyservers.net
gpg: keyserver refresh failed: Connection timed out

q: Updating ebuild cache in /usr/portage ...
q: Finished 36643 entries in 0.127503 seconds
 * emerge --sync failed

On the router, packets are (properly) blocked :

Jul  1 10:40:10 local/ext: IN=enp5s0 OUT=ppp0 MAC=<MACHINE MAC ADDR> SRC=<MACHINE IP> DST=193.164.133.100 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=47948 DF PROTO=TCP SPT=58146 DPT=443 WINDOW=29200 RES=0x00 SYN URGP=0 

If, before running eix-sync, we *manually* define/export http_proxy and https_proxy variables, the key test/refresh works and eix-sync does its job.

veterini ~ $ export http_proxy="http://account:password@proxy"
veterini ~ $ export https_proxy="http://account:password@proxy"
veterini ~ $ eix-sync 
 * Running emerge --sync
>>> Syncing repository 'gentoo' into '/usr/portage'...
 * Using keys from /usr/share/openpgp-keys/gentoo-release.asc
 * Refreshing keys from keyserver ...                          [ ok ]
>>> Starting rsync with rsync://192.168.1.51/gentoo-portage...
>>> Checking server timestamp ...
receiving incremental file list
timestamp.chk

...

sent 165.20K bytes  received 19.55M bytes  1.07M bytes/sec
total size is 218.02M  speedup is 11.06
 * Manifest timestamp: 2018-06-30 23:38:27 UTC
 * Valid OpenPGP signature found:
 * - primary key: DCD05B71EAB94199527F44ACDB6B8C1F96D8BF6D
 * - subkey: E1D6ABB63BFCFB4BA02FDF1CEC590EEAC9189250
 * - timestamp: 2018-06-30 23:38:27 UTC
 * Verifying /usr/portage ...                                  [ ok ]
=== Sync completed for gentoo
q: Updating ebuild cache in /usr/portage ... 
q: Finished 35526 entries in 0.150853 seconds

So it seems the key refresh does not get the proxy configuration.


Reproducible: Always

Steps to Reproduce:
1. Be behind an authenticating web proxy
2. And a 'deny all' router for any packet not coming from the proxy
3. Make.conf has http_proxy, https_proxy defined
4. Run eix-sync
Actual Results:  
The key refresh fails to use the http_proxy, https_proxy varenv from make.conf, key refresh fails and eix-sync fails.

Expected Results:  
Key refresh should go through the proxy.

sys-app/portage 2.3.40-r1
Comment 1 Zac Medico gentoo-dev 2020-06-08 17:52:55 UTC
Maybe a duplicate of bug 649642.