On 5 May 2017 at 09:41, Bruno Rocha <rochacbr...@gmail.com> wrote: > Hi, > > I just read this on reddit[0], a thread asking if PyPI packages are audited > and somebody pointed the `python-nation`[1] which is a harmful and useless > module, installing itself and sending the `/etc/passwd` content to external > endpoint. > > The app receiving the data is hosted at http://python-nation.herokuapp.com
Advertising
This is something that Jacob Kaplan-Moss wrote for a PyCon Australia security lightning talk a few years back: https://www.youtube.com/watch?list=PLs4CJRBY5F1KDIN6pv6daYWN_RnFOYvt0&feature=player_detailpage&v=daVHCUHtOZ4#t=1819s That talk was prompted by a similar social engineering exercise carried out in the Ruby community: http://blog.honeybadger.io/stop-using-rubygemsorg-in-production/ > and as the PSF mission [2] says > > The mission of the Python Software Foundation is to promote, protect, and > advance the Python programming language > > I wonder if there are some workgroup at PSF to handle this? and not only the > specific case of `python-nation` which should be deleted and the user banned > maybe, python-nation does not violate PyPI's Terms of Service. However, it does provide a useful reminder to end users that mistakenly view PyPI as a restricted app store rather than as an open publication platform akin to the web itself that "pip install <arbitrary-component>" is essentially no safer than "curl <arbitrary-script-url> | sh" (although it does offer greater assurances that if you pin your dependencies to particular versions, future downloads will either get you the same thing, or else fail outright). > But also to handle the audit of other packages? When people and organisations want security audits of open source software, they either have to do them themselves, pay someone else to do them on their behalf, or else rely on one of the volunteer-driven collaborative software auditing projects more commonly known as "community Linux distributions" (accepting the couple of orders of magnitude reduction in available components that comes from that last choice). Most large organisations will end up relying on some combination of the three (e.g. it's not uncommon for a RHEL-hosted application to include commercially audited packages from Red Hat and certified partners, community audited packages from EPEL, IUS, Fedora COPR, and/or softwarecollection.org, and team audited packages directly from PyPI, and we see the same kinds of layered architectures showing up regardless of which distro or platform people target). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ PSF-Community mailing list PSF-Community@python.org https://mail.python.org/mailman/listinfo/psf-community
