<br><br><div><span class="gmail_quote">On 7/23/06, <b class="gmail_sendername">Armin Rigo</b> <<a href="mailto:arigo@tunes.org">arigo@tunes.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi David, hi Brett,<br><br>On Sun, Jul 23, 2006 at 02:18:48AM +0100, David Hopwood wrote:<br>> If I understand correctly, the proposal is that any incompatible changes<br>> to the language would apply only in "sandboxed" interpreters. So there is
<br>> no reason why support for these couldn't go into the main branch.<br><br>That's what I originally thought too, but Brett writes:<br><br> Implementation Details<br> ========================<br><br> An important point to keep in mind when reading about the
<br> implementation details for the security model is that these are<br> general changes and are not special to any type of interpreter,<br> sandboxed or otherwise. That means if a change to a built-in type is<br>
suggested and it does not involve a proxy, that change is meant<br> Python-wide for *all* interpreters.<br><br>So that's why I'm starting to worry that Brett is proposing to change<br>the regular Python language too.
</blockquote><div><br>Yes, I am proposing changing some constructors and methods on some built-in types for the regular languages. That's it. No new keywords or major semantic changes and such. If I make changes just for sandboxed interpreters it changes the general approach of the security model by then requiring an identity check to see if the interpreter is sandboxed or not.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> However, Brett, you also say somewhere<br>else that backward compatibility is not an issue. So I'm a bit confused
<br>actually...</blockquote><div><br>Since this is my Ph.D. dissertation first and foremost, I am not going to tie my hands in such a way that I have to make too much of a compromise in order for this to work. I obviously don't want to change the feel of Python, but if I have to remove the constructor for code objects to prevent evil bytecode or __subclasses__() from object to prevent poking around stuff, then so be it. For this project, security is trumpeting backwards-compatibility when the latter is impossible in order to have the former. I will obviously try to minimize it, but something that works at such a basic level of the language is just going to require some changes for it to work.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Also, I hate to sound self-centered, but I should point out somewhere<br>that PyPy was started by people who no longer wanted to maintain a fork
<br>of CPython, and preferred to work on building CPython-like variants<br>automatically. Many of the security features you list would be quite<br>easier to implement and maintain in PyPy than CPython -- also from a<br>security perspective: it is easier to be sure that some protection is
<br>complete, and remains complete over time, if it is systematically<br>generated instead of hand-patched in a dozen places.</blockquote><div><br>It doesn't sound self-centered. =) Problem is that my knowledge base is obviously all in CPython so my startup costs are much lower than if I tried this in PyPy. Plus there is the point of embedding this into Firefox (possibly) eventually. Does PyPy support embedding yet at the C level?
<br><br>-Brett</div></div>