[Bf-committers] "Security" gets in the way

[Charles Wardlaw]

> File access is part of builtins, you can remove that.
> Even if you try, there's a million of sneaky ways to get it back, like the following:
> 
> [t for t in type(1).__class__.__base__.__subclasses__() if hasattr(t, "write")][0]("/path/to/file", "w").write("my payload")

There're ways around any security measure; even UBISoft's "uncrackable" DRM for their games was cracked this weekend.

> os and sys are not required for file access.

Bad example, but I hope the point was still made.

> Moreover, depending on the platform, they can be built into the interpreter (not external modules).

Aren't all 2.5 versions using an internal Python3.1 distribution that BF controls?  If folks are serious about this, external python in official builds can be disallowed and the internal Python stack can be nerfed.

> Good luck with that.
> Even with an import hook, it's possible to go around such a measure.

Sure, but again, people could get around most of the suggestions that have come up in this thread.  Trying to catch the broadest attempts at security breaches is all anyone can really be tasked with.  At some point someone is going to find a way around the security, and there will be issues.  It's unavoidable.

> Sometimes it's not malicious. It could just be a poorly written script that craps files all over your HD if not run in a certain way.

Which is a very good point, and adds validity to the notion of a central "trusted scripts" repository.  Having a trusted scripts / rigs place online that new users are pointed towards (instead of long BlenderArtists threads) would go much further to solving these issues than adding security layers to the software and inconveniencing long-time power users IMO.

Then again, it needs someone to manage it.
~ C