On 17 November 2016 at 11:12, Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
However, when it comes to draconian security policies, *transitive recommendations have power*: if CPython is approved, and python-dev collectively says "we recommend pip, virtualenv, and requests", then folks in locked down environments can use that as evidence to suggest that those other modules are also trustworthy (particularly when there are commercial software vendors shipping them).
I understand that argument, but I can assure you that my employer does not. Its security policies tend to be both draconian and ineffective. Is the "python-dev and RHEL recommend it" evidence all that effective for "most" sites with "software must be approved before installing" policies? (This argument could easily go against me, if "draconian" sites tend to drag on approving Python point releases as well as on "new" PyPI modules.)
In my experience, it's not so much "draconian" policies that cause the issues, as "not interested" policies. You get the standard build because that's what the default install gave, before the application-specific stack was added. If the application in question isn't built with Python (e.g., you use Python for automation, system management, or whatever) then you stand no chance of finding anyone to even *ask* for permission to go beyond the "out of the box" build. At best, on Windows systems, you get to say "we need you to run the following installers for our support tools" once, and likely once only. No internet access, no "please can we have X added", you get what you thought to ask for on day 1, and that's it. Paul