[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: pybuild and proxies -- could we make "prohibition" optional?



On 21 July 2015 at 20:17, Yaroslav Halchenko <debian@onerussian.com> wrote:
> talking about this ;-) :
>
> $> grep -A3 http_proxy pybuild
>     if 'http_proxy' not in env:
>         env['http_proxy'] = 'http://127.0.0.1:9/'
>     if 'https_proxy' not in env:
>         env['https_proxy'] = 'https://127.0.0.1:9/'
>
> which is overall GREAT since now I can drop off all those manual http*_proxy
> exports in debian/rules where I know that the application has nothing to do
> with the network.  BUT such settings forbid e.g. running any tests even if
> those start/use local server specifically initiated for testing.  This is not
> forbidden AFAIK by the policy and the only concern is our buildd farm which
> says that even local interface might not be available.  Some
> tools/libraries are smart enough to not try accessing proxy if http_proxy is
> set but empty, but some don't.
>
> So, long story short... would it be ok if I propose/commit a change like
>
> diff --git a/pybuild b/pybuild
> index d7bd35a..4edc175 100755
> --- a/pybuild
> +++ b/pybuild
> @@ -50,10 +50,12 @@ def main(cfg):
>      env = environ.copy()
>      if 'LC_ALL' not in env:
>          env['LC_ALL'] = 'C.UTF-8'
> -    if 'http_proxy' not in env:
> -        env['http_proxy'] = 'http://127.0.0.1:9/'
> -    if 'https_proxy' not in env:
> -        env['https_proxy'] = 'https://127.0.0.1:9/'
> +
> +    if environ.get('PYBUILD_FAKE_PROXY', '1') == '1':
> +        if 'http_proxy' not in env:
> +            env['http_proxy'] = 'http://127.0.0.1:9/'
> +        if 'https_proxy' not in env:
> +            env['https_proxy'] = 'https://127.0.0.1:9/'
>
>      if cfg.system:
>          certainty = 99
>
> to enable testing when it is feasible to do it without external interactions
> etc?

In practice however we do allow accessing debian ftp archive and
localhost services, thus:

no_proxy=localhost,*.debian.org

would probably be better imho for the balance of "don't allow general
network access", "yet allow sensible networking test-suites to run".

-- 
Regards,

Dimitri.


Reply to: