Re:Why Package Signing is not the Holy Grail
by pekk on Wednesday July 24, 2013 @10:49AM
(#6096473)
Suppose that 'pip install foo' did not run a setup.py. Now eventually you are going to run some code from foo. If you weren't, why are you installing it? At that time, you could have 'arbitrary code' running on your machine.
[ Parent
| on HN ]
Re:Why Package Signing is not the Holy Grail
by IgorPartola on Wednesday July 24, 2013 @04:06PM
(#6098747)
My point is that you don't even get a chance to review the source before it runs. pip runs in trusted code automatically, without any verification whatsoever. At least when you run 'git clone' that does not happen.
Re:Why Package Signing is not the Holy Grail
by donaldstufft on Wednesday July 24, 2013 @05:57PM
(#6099384)
The recently released pip 1.4 allows you to install from Wheels which does not use setup.py during install and executes no code from the package during install.
Re:Why Package Signing is not the Holy Grail
by IgorPartola on Thursday July 25, 2013 @08:24AM
(#6102039)
Yes, except I have seen very few packages that are not sdist's. Another issue is that unless the package maintainer disables it explicitly on PyPI, pip will go searching over the package's home page for a newer version. This is just broken since even if PyPI was to implement some type of package verification, example.com/~/devfoo/ might not. Often times these pages do not even have HTTPS set up.
As you said, this is a complex problem, but I think the first step is to take care of the easy things. Let me know if you'd like to chat off HN about this.