Stefan Behnel wrote:
this is really getting off-topic, BTW.
David Lyon wrote:
On Fri, 19 Jun 2009 07:24:21 +0200, Stefan Behnel wrote:
Leonardo Santagada wrote:
The biggest problem I see is security, but if people are really interested in this we could at least try it no?
Security certainly is a major issue here. Anyone can upload packages to PyPI, so you can run arbitrary code on tons of machines, just by pushing some well-forged setup.py script there.
Doesn't a chroot jail stop this? (on unix anyway)
Stop it from running arbitrary code? How would it do that?
Imagine your setup.py downloads Seti@Home jobs from a web site and calculates them. You can't really ban web access, as the setup.py script may use setuptools to download dependencies. You can't really stop it from doing calculations, as it might actually be doing real build stuff like source code generation. You can kill it after, say, an hour (or a half if you think that no build should take longer than that), but I guess I can do a lot of calculations in that time, on a lot of your computers. And if you ban my package, I'll just upload a different one with a different name. And if you ban my PyPI account, I'll grab a new one. And if you ban web access from your machines, well, I'll just upload a package that contains the tasks in the archive. And if you use hash codes to check for malicious packages, well, I'll just start obfuscating my code and my data. And be assured that what I'm really doing is not calculating Seti@Home jobs.
There's really no way you can stop someone from misusing your infrastructure if you go for building any arbitrary package that gets uploaded to PyPI.
Forbidding any network access from the vm used to build would solve most of those problems. Controlling CPU/memory can be done from the host OS. I would be surprised if the openSuse build system worked in a fundamentally different way: rpm .spec files can also execute arbitrary code.