On 24Aug2017 1241, James Powell wrote:

Like, we're inevitably going to
have people trying to use 'spython' to replace their normal python
'because it's more secure' and stuff like that. Would it make sense to
call it something else, like 'tpython' (for 'transparent'), or
'stdemo-python' (to emphasize that it's more intended as an example and
starting point rather than a useful product)?

This is an important point. It's going to be critical that we appropriately convey what 
"security transparency" means. I believe we can do this.

Many of the convenience features (e.g., Windows-specific integrations like ETW) 
attached to this project should be made generally available. We should 
encourage users to deploy spython only where security transparency truly makes 
sense, and discourage its deployment where users just want access to some 
integration feature.

(Note that it may not even make sense to deploy spython for work that requires 
ctypes or cffi or numpy or pywin32 or any other library that could allow raw 
memory access.)

Agreed. This is the point of the Recommendations section, and specifically the recommendation to not distribute any spython build outside of your own network (I explicitly said that python.org won't distribute builds, and it's up to any other distributors to make their own call).

If you build from source, you'll get spython, but currently I don't think it'll install from source (I certainly didn't change anything to make that work). That's the way I expect it to stay.

I think platform specific functionality should be kept separate, if only because testing and maintaining it is so much more difficult. Ideally security vendors will offer their own versions that organizations can build upon which integrate with their tools (and Microsoft certainly falls into this category for OS functionality like DeviceGuard and ETW), but I don't want our volunteers to have to worry about configuring test machines on their free time just to make sure it doesn't break (or to get caught up in liability disputes if someone relies on it when they really should have done due diligence).

Also, integration into things like the logging module (for ETW on Windows) are totally unrelated to this PEP. All it takes is someone to write the extension module and ship it on PyPI.


As an aside, one of Microsoft's top security guys saw a tweet about this and posted some screenshots of Python payloads in actual malware:

https://twitter.com/JohnLaTwC/statuses/900807173495771140

My favourite part is the Python 2.x and 3.x compatibility in the MacOS path of the first one :) (the Windows path in that one uses PowerShell).

Cheers,
Steve

_______________________________________________
Security-SIG mailing list
Security-SIG@python.org
https://mail.python.org/mailman/listinfo/security-sig

Reply via email to