[Python-Dev] doc for new restricted execution design for Python (original) (raw)

Brett Cannon brett at python.org
Thu Jul 6 19:16:37 CEST 2006

On 7/5/06, Ka-Ping Yee <python-dev at zesty.ca> wrote:

On Wed, 5 Jul 2006, Brett Cannon wrote: > On 7/4/06, Ka-Ping Yee <python-dev at zesty.ca> wrote: > > In response to Guido's comment about confusing the words "trusted" and > > "untrusted", how about "empowered" and "restricted"? > > Maybe. I am really starting to lean towards trusted and sandboxed. It can be risky to use words of the form 'trust' when talking about security because 'trust' can have different meanings in different contexts. (Examples: 'X is trusted' might mean 'X is something i feel safe running without restrictions' or 'X is in fact allowed to run without restrictions' or 'i need to run X without restrictions in order to accomplish my task' or 'X is something i am relying on for the security of my system'.) The most common context for 'trusted' that i seem to come across is in the phrase 'trusted computing base' (TCB), which refers to 'the thing that is supposed to be enforcing security restrictions' as opposed to 'something i'm willing to let run unrestricted'. So when i read 'trusted code' what comes to mind is the C implementation of the Python interpreter, and it may be a good idea to reserve that phrase for that purpose, if it's to be used at all. In any case, let's try to nail down clear names for the different pieces we're talking about here, and i gently advise avoiding 'trust' words or using them with very limited meaning.

For the next draft I am going with "trusted" and "sandboxed" just because I have already revised a decent amount and it is what my brain is defaulting to right now, but I can change the wording later.

-Brett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20060706/fa853fe3/attachment.html

More information about the Python-Dev mailing list