On 7/23/06, Phillip J. Eby <pje at telecommunity.com> wrote: > > At 11:07 PM 7/23/2006 +0100, David Hopwood wrote: > >Phillip J. Eby wrote: [snip] Brett's securing_python.txt don't refer to or cite Zope in any way, but > rather relies on broad and unsupported assertions about what can or can't > be done with Python. I hope he isn't doing the same in his thesis, as > this > is rather like writing about one's new theory of how to have a worldwide > ball-kicking contest without making any reference as to how one's theory > compares with the World Cup. The design doc is not meant to be taken as any sort of draft of my thesis. I did read that link you sent me, Philip, but it was hard to follow. So I used Google to find another reference that explained it to me much more clearly. securing_python.txt is meant to explain what I am planning to python-dev so that if someone sees some fatal flaw they can speak up and let me know, not as a thorough comparison of why my approach is better than anyone other one. I'm not saying Zope is better or worse. I'm simply saying that in a > business context, a failure to compare and contrast a proposed "build" > solution to show how it would be better than a well-established available > "buy" solution would be called something like "lack of due diligence". I > think in the academic context it might be called something like "failure > to > cite", but the general idea is the same, i.e., not doing your > homework. :) > > In other words, if the solution being proposed is better than what Zope > does, the appropriate thing in business is to show the reasons why, and > the > appropriate thing in science is to state a hypothesis regarding the > differences, and then perform an experiment to either prove or disprove > it. I am not going to write out a blow-by-blow comparison right now. It will come with the thesis. And I am not expecting my approach or code to be checked in blindly anyway. >In any case, Zope's sandboxing is not capability-based. > > You're right: you haven't done a review of it. :) If you had, you'd know > that one proxy plus one namechecker equals one capability. In other > words, > you could take the restricted interpreter, the proxy mechanism, and the > namechecker and leave most of the rest alone, and you'd have your > capability system. Then you could focus more time and attention on the > parts of the problem that Zope *doesn't* solve, instead of reinventing the > ones that it already does. Right, but I am trying to remove the need for a namechecker which makes it an object-capabilities system. Now, if Brett believes that changing the Python language is a *better* way > to implement capabilities than using proxies to implement them, then > great. His paper should explain why, and (presumably) include > experimental > results to show that they're either better or worse than Zope's approach > based on some criteria. The same information is relevant to Python-Dev as > to what is an appropriate approach to support sandboxing in CPython. What > are the advantages of a built-in approach versus an add-on approach? Are > there interpreter facilities that could be added to shore up any awkward > aspects of Zope's approach? (Whatever those might be.) I think people are starting to lose sight of the purpose of the doc I wrote. It was to explain what I was doing for people to see if there was any fatal flaw and to keep people updated on what I am planning on doing. It is not meant to convince anyone that my way is the best way yet. I am not even going to attempt that until I have working code. For example, one part of Zope's approach uses a custom compiler and custom > builtins in order to redefine how attribute access works in certain > cases. Could these customizations be replaced with options built into the > Python compiler and interpreter? What improvements would that result in? Part of my point is to help alleviate the need for custom anything. Simply handwaving all of these questions away, however, with broad > assertions of superiority and without even attempting to compare the new > work to Zope's existing work is really not acceptable for academia OR > Python development. > > For the record: I have no personal interest in Zope's security system. I > didn't develop it and haven't had the need to use it, myself. I once > reviewed some of the code and offered some minor suggestions, mainly > regarding performance improvement. My only axe to grind in this matter is > what I've already stated: I think it would be crazy (in the "monumental > waste of resources" sense) to consider putting *any* sandboxing system > into > CPython without tapping the Zope team's experiences. For example: having > implemented such a system, what compiler or interpreter changes would've > made the job easier? > > Meanwhile, what Brett does or doesn't put in his thesis is between him and > his advisor, but what gets put into Python shouldn't be based on ignoring > the existing field experience and state of the art. There is no ignoring of anything. I understand their basic approach and I want to try another one. I like the fundemental design difference of object-capabilities and so I am going to give it a shot and see how it works out. If Zope's proxies are better, then fine, get them to contribute to the core so that we have security again. No one is proposing blind acceptance of my approach. But as it stands now, Guido likes my initial ideas (including the possible changes to the language), I like my approach, and my supervisor is willing to let me give it a shot, so that is good enough for me to move forward. There will be a thorough discussion I am sure once the code is finished and ready to be proposed for possible inclusion in CPython. Until then, though, just consider it my little experiment that I am just keeping people abreast of. -Brett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20060723/bd0f74ea/attachment.htm
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4