As per the following commit, `ftp_proxy`, `http_proxy`, `https_proxy`, and `no_proxy` are filtered from the environment that portage is called from https://gitweb.gentoo.org/proj/portage.git/commit/bin/save-ebuild-env.sh?id=2410f8d7dde2ac12de4ec040696bcbb51e09ce9f I believe that this is the wrong choice: 1. In restrictive environments it may be useful to temporarily set this to enable a fetch via a particular proxy, e.g.: ``` doas su -c 'https_proxy=localhost:3128 ebuild warewulf-4.4.1.ebuild manifest' ``` 2. this is inconsistent with other portage configuration, which may come from the calling environment, e.g. 'USE', 'FEATURES', 'GENTOO_MIRRORS', MAKEOPTS, etc, which override make.conf. ``` doas su -c 'https_proxy=localhost:3128 ebuild warewulf-4.4.1.ebuild manifest' >>> Downloading 'https://mirror.aarnet.edu.au/pub/gentoo/distfiles/layout.conf' --2023-09-05 13:13:44-- https://mirror.aarnet.edu.au/pub/gentoo/distfiles/layout.conf Resolving MY_WORK_PROXY... WORK_PROXY_IP Connecting to MY_WORK_PROXY|WORK_PROXY_IP|:80... connected. Proxy request sent, awaiting response... 200 OK ``` This is bad UX :( 3. Users should not be calling portage from a polluted environment anyway (i.e. 'sudo su -; emerge ... @world'), while filtering these variables provides effective footgun protection it also enables terrible habits that we _already_ document and explicitly tell users not to do. Reproducible: Always
