Nick Coghlan writes: > In that context, the problem is the old "batteries that leak acid > everywhere can be worse than no batteries at all" one: we know from > painful experience with the SSL module that the standard library's > typical release and adoption cycle can be seriously problematic when > it comes to network security related modules.
In that context, SSL is a somewhat special case because of its dependence on OpenSSL and because of Apple's U+1F4A9-headed attitude toward fixing something they distribute. If pyoic is pure Python, I would expect as many releases as we have branches supporting it within 6-12 weeks. Less time, if a truly nasty security bug. No? Sure, that's problematic for any sites that haven't yet approved a Python version with pyoic in it, but they're problematic period. > 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.) Steve _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
