Re: [Distutils] Malicious packages on PyPI

I suggested on one of those issues to try to auto-blacklist common 404s as that should pose a negligible usability hit. I'd like to start by logging them to collect data, but I'm confused nowadays as to if that should go into pypa/warehouse or pypa/pypi-legacy. How long until warehouse is where

Re: [Distutils] Malicious packages on PyPI

I was more pushing for the transitive trust element than signing. That being said, any signing at all would be progress. On Jun 1, 2017 9:07 PM, "Donald Stufft" wrote: On Jun 1, 2017, at 8:15 PM, Matt Joyce wrote: Or start doing signed pgp for package

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

> On Jun 1, 2017, at 9:40 PM, Jeremy Stanley wrote: > > On 2017-06-01 21:09:57 -0400 (-0400), Donald Stufft wrote: > [...] >> I think a separate tool for each of these roles is somewhat user >> unfriendly TBH. > [...] > > I'll do my best not to be offended that you don't

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

> On Jun 1, 2017, at 6:09 PM, Donald Stufft wrote: > > I sometimes wonder if we should be folding twine into pip itself Yes please. WTB `pip upload`. -g___ Distutils-SIG maillist - Distutils-SIG@python.org

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On 2017-06-01 21:09:57 -0400 (-0400), Donald Stufft wrote: [...] > I think a separate tool for each of these roles is somewhat user > unfriendly TBH. [...] I'll do my best not to be offended that you don't consider me a user (or representative of some broader class of users). ;) At any rate, I

Re: [Distutils] Malicious packages on PyPI

> On Jun 1, 2017, at 8:15 PM, Matt Joyce wrote: > > Or start doing signed pgp for package maintainers and build a transitive > trust model. > PGP is not useful for our use case except as a generic crypto primitive, and there are better generic crypto primitives out

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

> On Jun 1, 2017, at 7:53 PM, Jeremy Stanley wrote: > > On 2017-06-01 20:45:53 + (+), Brett Cannon wrote: > [...] >> I think *twine* is the tool that needs a way to specify how to >> produce an sdist. If we want to view twine as the tool to upload >> artifacts to PyPI

Re: [Distutils] Malicious packages on PyPI

Force packages to match their higher level import namespace in future major Python versions and PEP it. On Jun 1, 2017 7:37 PM, "Noah Kantrowitz" wrote: > > > On Jun 1, 2017, at 4:00 PM, Nick Timkovich > wrote: > > > > This issue was also brought

Re: [Distutils] Malicious packages on PyPI

Or start doing signed pgp for package maintainers and build a transitive trust model. On Jun 1, 2017 8:14 PM, wrote: Force packages to match their higher level import namespace in future major Python versions and PEP it. On Jun 1, 2017 7:37 PM, "Noah Kantrowitz" wrote: >

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On 2017-06-01 20:45:53 + (+), Brett Cannon wrote: [...] > I think *twine* is the tool that needs a way to specify how to > produce an sdist. If we want to view twine as the tool to upload > artifacts to PyPI then we need twine to know how to produce sdists > and wheels in a PEP 517 world,

Re: [Distutils] Malicious packages on PyPI

> On Jun 1, 2017, at 4:00 PM, Nick Timkovich wrote: > > This issue was also brought up in January at > https://github.com/pypa/pypi-legacy/issues/585 then just as after the initial > "typosquatting PyPI" report (June 2016) it's met with resounding silence. >

Re: [Distutils] Malicious packages on PyPI

A couple of pieces of prior art: In Django, where we supply a command to let users create a new project or application, we ask the user to supply a name. And then as a quick check before proceeding, attempt to import the supplied name; if the import succeeds, the startapp/startproject command

Re: [Distutils] Malicious packages on PyPI

> On Jun 1, 2017, at 6:20 PM, Jannis Gebauer wrote: > >> This makes me remember >> https://hackernoon.com/building-a-botnet-on-pypi-be1ad280b8d6 >> on a related >> note. > > > Yep, that’s basically the same

Re: [Distutils] Malicious packages on PyPI

On Thu, Jun 1, 2017 at 3:20 PM, Jannis Gebauer wrote: > This makes me remember > https://hackernoon.com/building-a-botnet-on-pypi-be1ad280b8d6 on a related > note. > > > Yep, that’s basically the same thing. Instead of using package names of > builtins, the attacker is using a

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

> On Jun 1, 2017, at 6:28 PM, Paul Moore wrote: > > On 1 June 2017 at 23:14, Thomas Kluyver wrote: >> On Thu, Jun 1, 2017, at 10:49 PM, Paul Moore wrote: >>> pip also needs a way to deal with "pip install . In >>> this case, pip (under its current

Re: [Distutils] Malicious packages on PyPI

> This makes me remember > https://hackernoon.com/building-a-botnet-on-pypi-be1ad280b8d6 > on a related > note. Yep, that’s basically the same thing. Instead of using package names of builtins, the attacker is using a

Re: [Distutils] Malicious packages on PyPI

On 2 June 2017 at 09:00, Nick Timkovich wrote: > This issue was also brought up in January at https://github.com/pypa/pypi- > legacy/issues/585 then just as after the initial "typosquatting PyPI" > report (June 2016) it's met with resounding silence. Attacking the >

Re: [Distutils] Malicious packages on PyPI

This issue was also brought up in January at https://github.com/pypa/pypi-legacy/issues/585 then just as after the initial "typosquatting PyPI" report (June 2016) it's met with resounding silence. Attacking the messenger doesn't seem like a winning move from a security standpoint. Can we come up

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On 1 June 2017 at 23:14, Thomas Kluyver wrote: > On Thu, Jun 1, 2017, at 10:49 PM, Paul Moore wrote: >> pip also needs a way to deal with "pip install . In >> this case, pip (under its current model) copies that directory to a >> working area. In that area, it runs the build

Re: [Distutils] Malicious packages on PyPI

On 2 June 2017 at 03:40, Thomas Kluyver wrote: > On Thu, Jun 1, 2017, at 06:32 PM, Matt Joyce wrote: > There *appear* to be, but I checked several of the names listed there, and > they're not on PyPI: > > https://pypi.python.org/pypi/tkinter >

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On Thu, Jun 1, 2017, at 10:49 PM, Paul Moore wrote: > pip also needs a way to deal with "pip install . In > this case, pip (under its current model) copies that directory to a > working area. In that area, it runs the build command to create a > wheel, and proceeds from there. In principle,

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On 1 June 2017 at 21:45, Brett Cannon wrote: > And so I think in a very wordy way, I just said we need to stop saying "pip > needs a standardized way to produce an sdist" and instead start saying > "twine needs a way to produce an sdist". And that leads to the question > about

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On Wed, 31 May 2017 at 14:14 Thomas Kluyver wrote: > On Wed, May 31, 2017, at 09:16 PM, Donald Stufft wrote: > > How you build the release-quality sdist isn’t really of concern of PEP 517 > any more than building a release quality wheel is, it’s up to the build > tool to

Re: [Distutils] Malicious packages on PyPI

I mean the easy attack vector is find a package where the package name does not match the import namespace. If the import namespace has no corresponding package in pypi... register it. Anyone who blind tries to grab a dependency will grab your module instead of the one they want. Horrible to

Re: [Distutils] Malicious packages on PyPI

This makes me remember https://hackernoon.com/building-a-botnet-on-pypi-be1ad280b8d6 on a related note. On Thu, Jun 1, 2017 at 7:40 PM, Thomas Kluyver wrote: > On Thu, Jun 1, 2017, at 06:32 PM, Matt Joyce wrote: > > It's basically a test dummy package that reports users

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On Thu, Jun 1, 2017 at 1:22 PM, Donald Stufft wrote: > > On Jun 1, 2017, at 2:12 PM, C Anthony Risinger > wrote: > > Because the build itself can output additional source files, that may be > desirable to include in an sdist later, I honestly don't

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

> On Jun 1, 2017, at 2:12 PM, C Anthony Risinger > wrote: > > Because the build itself can output additional source files, that may be > desirable to include in an sdist later, I honestly don't think you can pass > through a "proper" sdist before a wheel. I think

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On 2017-05-31 20:08:51 -0400 (-0400), Donald Stufft wrote: [...] > Both {name} and {version} MUST have any - characters escaped to a > _ to match the escaping done by Wheel. Thus a sdist for a project > named foo-bar with version 1.0-2 which is using a .tar.gz > container for the sdist would

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On Thu, Jun 1, 2017 at 5:34 AM, Donald Stufft wrote: > > On Jun 1, 2017, at 3:44 AM, Paul Moore wrote: > > On 1 June 2017 at 01:08, Donald Stufft wrote: > > A sdist is a .tar.gz or a .zip file with a directory structure like (along >

Re: [Distutils] Malicious packages on PyPI

On Thu, Jun 1, 2017, at 06:32 PM, Matt Joyce wrote: > It's basically a test dummy package that reports users who have ran > that package template. That's what I thought, but all the code to do the upload seems to have been removed before s/he built those packages. Now it's just a harmless warning,

Re: [Distutils] Malicious packages on PyPI

https://github.com/fate0/cookiecutter-evilpy-package/tree/master/%7B%7Bcookiecutter.package_name%7D%7D that's the package repo on github. It's basically a test dummy package that reports users who have ran that package template. the site referenced lists the package name that the user ran to

Re: [Distutils] Malicious packages on PyPI

On closer examination, those packages do not actually appear to upload any information - they seem to be empty packages placed there to serve as a warning. It's not clear to me whether the data on the fatezero.org website is from other packages which really do upload data, or if it's fake. On

[Distutils] Malicious packages on PyPI

Are we aware of this? http://evilpackage.fatezero.org/ I recall there were a couple of these before which were taken down, but someone appears to have made a cookiecutter template so you can very easily claim names on PyPI, and anyone who installs that package will submit their information to

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On Wed, May 31, 2017 at 08:08:51PM -0400, Donald Stufft wrote: > I think this should cover the case of actually making the project pip > installable (assuming of course the setup.py or build backend doesn’t do > something silly like always sys.exit(1) instead of produce the expected > outcome) My

Re: [Distutils] Installation problem

Got it, thanks! I fixed it. On Wed, May 31, 2017 at 9:19 AM Robert T. McGibbon wrote: > This isn't actually the right place to ask for installation help, Aneesh. > Your best bet would be the python-list or python-help mailing list. > > -Robert > > On Tue, May 30, 2017 at 7:24

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

> On Jun 1, 2017, at 3:44 AM, Paul Moore wrote: > > On 1 June 2017 at 01:08, Donald Stufft wrote: >> A sdist is a .tar.gz or a .zip file with a directory structure like (along >> with whatever additional files the project needs in the sdist): > [...] > >

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

On 1 June 2017 at 01:08, Donald Stufft wrote: > A sdist is a .tar.gz or a .zip file with a directory structure like (along > with whatever additional files the project needs in the sdist): [...] I'm confused. Isn't this basically what PEP 517 says already? You've added some