Re: [Python-Dev] PEP 594: Removing dead batteries from the standard library
Fra: Python-Dev [mailto:python-dev-bounces+ajm=flonidan.dk@python.org] På vegne af Christian Heimes
* The removed modules will be available through PyPI.
Will they? That's not the impression I got from the PEP. regards, Anders
On 21/05/2019 14.06, Anders Munch wrote:
Fra: Python-Dev [mailto:python-dev-bounces+ajm=flonidan.dk@python.org] På vegne af Christian Heimes
* The removed modules will be available through PyPI.
Will they? That's not the impression I got from the PEP.
It's all open source. It's up to the Python community to adopt packages and provide them on PyPI. Python core will not maintain and distribute the packages. I'll merely provide a repository with packages to help kick-starting the process. Christian
That seems entirely reasonable. I wonder if the larger community could somehow form an organization (the Dead Parrot SIG?) that would at least curate and monitor efforts to ensure their continued utility? On Tue, May 21, 2019 at 1:40 PM Christian Heimes <christian@python.org> wrote:
On 21/05/2019 14.06, Anders Munch wrote:
Fra: Python-Dev [mailto:python-dev-bounces+ajm=flonidan.dk@python.org] På vegne af Christian Heimes
* The removed modules will be available through PyPI.
Will they? That's not the impression I got from the PEP.
It's all open source. It's up to the Python community to adopt packages and provide them on PyPI.
Python core will not maintain and distribute the packages. I'll merely provide a repository with packages to help kick-starting the process.
Christian _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve%40holdenweb.com
On Tue, 21 May 2019 at 13:50, Steve Holden <steve@holdenweb.com> wrote:
That seems entirely reasonable. I wonder if the larger community could somehow form an organization (the Dead Parrot SIG?) that would at least curate and monitor efforts to ensure their continued utility?
I have no idea whether there is enough community support to make this work, but regardless, I strongly support a SIG by that name. It may actually be even *more* amusing if it doesn't have enough members to make it viable :-) Paul
Good point! On Tue, May 21, 2019 at 2:01 PM Paul Moore <p.f.moore@gmail.com> wrote:
On Tue, 21 May 2019 at 13:50, Steve Holden <steve@holdenweb.com> wrote:
That seems entirely reasonable. I wonder if the larger community could
somehow form an organization (the Dead Parrot SIG?) that would at least curate and monitor efforts to ensure their continued utility?
I have no idea whether there is enough community support to make this work, but regardless, I strongly support a SIG by that name. It may actually be even *more* amusing if it doesn't have enough members to make it viable :-)
Paul
On 5/21/19 8:37 AM, Christian Heimes wrote:
On 21/05/2019 14.06, Anders Munch wrote:
Fra: Python-Dev [mailto:python-dev-bounces+ajm=flonidan.dk@python.org] På vegne af Christian Heimes
* The removed modules will be available through PyPI. Will they? That's not the impression I got from the PEP. It's all open source. It's up to the Python community to adopt packages and provide them on PyPI.
Python core will not maintain and distribute the packages. I'll merely provide a repository with packages to help kick-starting the process.
This statement should be in the PEP in some form. For example: "The modules could be made available on PyPI. The Python core team will not publish or maintain the packages." --Ned.
Christian Heimes writes:
It's all open source. It's up to the Python community to adopt packages and provide them on PyPI.
Python core will not maintain and distribute the packages. I'll merely provide a repository with packages to help kick-starting the process.
This looks to me like an opening to a special class of supply chain attacks. I realize that PyPI is not yet particularly robust to such attacks, and we have seen "similar name" attacks (malware uploaded under a name similar to a popular package). ISTM that this approach to implementing the PEP will enable "identical name" attacks. (By download count, stdlib packages are as popular as Python. :-) It now appears that there's been substantial pushback against removing packages that could be characterized as "obsolete and superseded but still in use", so this may not be a sufficient great risk to be worth addressing. I guess this post is already a warning to those who are taking care of the "similar name" malware that this class of attacks will be opened up. One thing we *could* do that would require moderate effort would be to put them up on PyPI ourselves, and require that would-be maintainers be given a (light) vetting before handing over the keys. (Maybe just require that they be subscribers to the Dead Parrot SIG? :-) Steve
This vector exists today for all new stdlib modules: once added, any existing dependency could include that name to cater it to be imported on prior python versions. Rob On Wed, 22 May 2019, 17:03 Stephen J. Turnbull, < turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Christian Heimes writes:
It's all open source. It's up to the Python community to adopt packages and provide them on PyPI.
Python core will not maintain and distribute the packages. I'll merely provide a repository with packages to help kick-starting the process.
This looks to me like an opening to a special class of supply chain attacks. I realize that PyPI is not yet particularly robust to such attacks, and we have seen "similar name" attacks (malware uploaded under a name similar to a popular package). ISTM that this approach to implementing the PEP will enable "identical name" attacks. (By download count, stdlib packages are as popular as Python. :-)
It now appears that there's been substantial pushback against removing packages that could be characterized as "obsolete and superseded but still in use", so this may not be a sufficient great risk to be worth addressing. I guess this post is already a warning to those who are taking care of the "similar name" malware that this class of attacks will be opened up.
One thing we *could* do that would require moderate effort would be to put them up on PyPI ourselves, and require that would-be maintainers be given a (light) vetting before handing over the keys. (Maybe just require that they be subscribers to the Dead Parrot SIG? :-)
Steve _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/robertc%40robertcollins.n...
On Wed, May 22, 2019 at 01:59:59PM +0900, Stephen J. Turnbull wrote:
This looks to me like an opening to a special class of supply chain attacks. [...]
One thing we *could* do that would require moderate effort would be to put them up on PyPI ourselves, and require that would-be maintainers be given a (light) vetting before handing over the keys. (Maybe just require that they be subscribers to the Dead Parrot SIG? :-)
Because black hat hackers don't know how to subscribe to a SIG? *wink* I'm just gonna leave this here... https://www.ietf.org/rfc/rfc3514.txt Python is open source, anyone can fork any module from the std lib for any purposes. We can't stop that. But your earlier point about supply chain attacks is very valid. Modules we shift out of the stdlib become more vulnerable to supply chain attacks, because more people will have to download them, giving more opportunity for typo-squatter attacks. -- Steven
On 22/05/2019 06.59, Stephen J. Turnbull wrote:
Christian Heimes writes:
It's all open source. It's up to the Python community to adopt packages and provide them on PyPI.
Python core will not maintain and distribute the packages. I'll merely provide a repository with packages to help kick-starting the process.
This looks to me like an opening to a special class of supply chain attacks. I realize that PyPI is not yet particularly robust to such attacks, and we have seen "similar name" attacks (malware uploaded under a name similar to a popular package). ISTM that this approach to implementing the PEP will enable "identical name" attacks. (By download count, stdlib packages are as popular as Python. :-)
I don't consider this an argument against my proposal, but an argument in favor of improving PyPI. <sarcasm> I propose a deal: If you get PEP 453 (ensurepip) revoked, ensurepip removed from the standard library, and the recommendation for the requests package on urllib.request replaced with a big, fat security warning, then I'll reconsider my proposal to recommend PyPI. </sarcasm> :) My PEP acts in good faith. As long as CPython's stdlib ships pip and embraces PyPI, I don't see any reason to distrust PyPI. Yes, PyPI is not Fort Knox. In my humble opinion it's more than secure enough for my proposal. Christian
participants (8)
-
Anders Munch -
Christian Heimes -
Ned Batchelder -
Paul Moore -
Robert Collins -
Stephen J. Turnbull -
Steve Holden -
Steven D'Aprano