Mailman 3 March 2003 - Python-Dev

[ot] offline
by Samuele Pedroni March 23, 2003

March 23, 2003

I will be essentially offline for the next 2 weeks. regards.

1 0

Weekly Python Bug/Patch Summary
by Skip Montanaro March 23, 2003

March 23, 2003

Bug/Patch Summary ----------------- 372 open / 3479 total bugs (+23) 133 open / 2033 total patches (+11) New Bugs -------- ncurses/curses on solaris (2003-03-10) http://python.org/sf/700780 Compiler Limits (indentation) (2003-03-10) http://python.org/sf/700827 WINDOW in py_curses.h needs ncurses-devel (2003-03-11) http://python.org/sf/701751 configure option --enable-shared make problems (2003-03-11) http://python.org/sf/701823 Thread running (os.system or popen#) (2003-03-11) http://… [View More]

1 0

Icon for Python RSS Feed?
by Tino Lange March 22, 2003

March 22, 2003

Hi! Can you add an nice icon for the news XML RDF resource http://www.python.org/channews.rdf for example in http://www.python.org/favicon.ico? I think this is the standard location - at least for my KNewsTicker. Then your news will be clearly marked as Python News in the Newsticker :-) Thanks and have a nice day! Tino

1 0

New Module? Tiger Hashsum
by Tino Lange March 21, 2003

March 21, 2003

Hi! Today I suddenly needed the tiger hashsums from python - it's not included in the standard distribution and I couldn't find it somewhere. So I thought that's it's maybe time again to contribute :-) It was a quite straight forward task to write a wrapper that is able to calculate such hash-sums from Python, besides the tiger.c/tiger.h it's only a few lines of code. It runs perfect under Linux with distutils - I guess someone who knows windows better has to look for a windows port beacuse … [View More]

3 3

Re: [Python-Dev] socket timeouts fail w/ makefile()
by Skip Montanaro March 21, 2003

March 21, 2003

Guido> Again, I won't have time to do this until after I'm back from Guido> Python UK, so I'd appreciate it if someone helped with this, Guido> e.g. by filing a patch. Skip> I'll take a look. I attached a patch to http://www.python.org/sf/707074 which makes the socket wrapper unconditional, and added a new test case (test_urllibnet.py - requires the 'network' resource) which fails before applying the patch and succeeds afterward. Would someone else like to take a look … [View More]

1 0

socket timeouts fail w/ makefile()
by Skip Montanaro March 21, 2003

March 21, 2003

I discovered much to my chagrin today that the socket module's new timeout capability doesn't play well with file objects as returned by a socket's makefile method. Tim O'Malley's timeoutsocket module avoids this problem by implementing a simple file-like object directly on top of the socket without calling makefile(). Is there some reason this approach wasn't adopted when adding timeouts to the socket module? I would think the greatest use of timeouts would be using higher-level line-… [View More]

2 4

csv package stitched into CVS hierarchy
by Skip Montanaro March 21, 2003

March 21, 2003

The csv package is now in the main branch of the CVS hierarchy. I will leave the structure in the sandbox for a few days before "cvs remove"ing it in case I missed something. Skip

3 2

capability-mediated modules (was: python-dev Summary for 2003-03-01 through 2003-03-15)
by Zooko March 20, 2003

March 20, 2003

brett(a)python.org wrote: > > Security with capabilities is done based on possession; if you hold a > reference to an object you can use that object. Note that you can use capabilities as your sole access control mechanism if every resource that you want to protect is identifiable with a Python reference. For example, suppose you want to control the ability to listen on sockets for network traffic. If there is a reference (e.g., to an object) that represents the privilege of … [View More]listening on sockets, then you can give such a reference to one object, allowing that object it to listen on sockets, while withholding it from another object, thus preventing that one from listening on sockets. The only part of Python that isn't already well-matched with capabilities is the way that authority is gained by importing modules, and you can load a module even when you weren't given a reference to it. Reconciling Python modules with capabilities would be the challenging part. Python objects, bound methods, functions, and suchlike are already well-matched to capabilities. In case that isn't clear, I'll write a quick example. Recalling my "tic-tac-toe game" example from [1], I wrote code which allowed or denied the tic-tac-toe game to paint a window on the screen and to write to a file. This "allow-or- deny" enforcement was unified with the designation of which window and which file. That is: by passing a reference to a certain window, I simultaneously told the tic-tac-toe game which window to draw in *and* extended to it the privilege of drawing to the screen. This is a central motto of the capability security crowd: "Unify designation with authority." In a capability system *all* authority -- everything that you could ever want to prevent -- is mediated by capabilities. Code that is loaded and run, but to which no capabilities are extended, must be incapable of doing anything dangerous. Now, what about modules? In current Python, some code can "import os" and gain all kinds of authority. In the rexec scheme, as I understand it, there was a handler function which could be overridden to determine what happens when I try "import os". This is effectively a "policy mini-language", such as in the hypothetical "restricted Python v2" [1]. (Guido has pointed out that this overridable policy handler could be used to implement capabilities as well as other regimes. I think I agree in principle, but what I am advocating here is having the core language implement capabilities so that the programmer-visible part is as minimal and unified as possible.) Now what I would *like* is that instead of doing "import os" to load code, instead the caller provides, or doesn't provide the os module as part of the construction/invocation of A. I don't have a clear idea yet of how that could be implemented in a Pythonic, compatible way. Just to help me think about it I'll suggest a non-Pythonic and incompatible way: there is no "import" keyword. When you invoke a constructor, function, method, etc., you have to pass as arguments references to everything that the code will need to do its job. So, assuming the tic-tac-toe game requires the "math" module and the "string" module, I would have to write: # restricted Python v3+modules game = TicTacToeGame() game.display(open("/tmp/tttgame.out","w"), math, string) The burden of typing in dozens of module names with each invocation can be eased by: 1. bundling modules together (put math, string, and some other stuff into one object/module/package named "standardstuff" and pass that as an argument), 2. "safe" modules that nobody could ever wish to prevent could be globally available (via the resurrected "import" keyword, I guess). If math and string are both "safe", then the example goes back to: # restricted Python v3+modules game = TicTacToeGame() # a game against itself that writes results to a file game.display(open("/tmp/tttgame.out","w")) # a game against remote, listening on a socket game.display(open("/tmp/tttgame.out","w"), socket) (Note that there is a bootstrapping problem -- *some* code has to receive a reference to the os module ex nihilo. That code should be "trusted" code -- the Python interpreter, basically.) Ah, but this last line shows another problem -- the game now has the socket module, and the ability to open sockets to remote hosts and more. I just wanted to allow it to listen on a particular port! The code would be safer if I didn't pass the large-grained module and instead passed a specific object: # a game against remote, listening on a socket listensocket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) listensocket.bind(('daring.cwi.nl', 8901,)) game.display(open("/tmp/tttgame.out","w"), listensocket) Regards, Zooko http://zooko.com/ ^-- under re-construction: some new stuff, some broken links [1] http://mail.python.org/pipermail/python-dev/2003-March/033938.html [View Less]

4 6

Re: [Python-Dev] capability-mediated modules (was: python-dev Summary for 2003-03-01 through 2003-03-15)
by Zooko March 20, 2003

March 20, 2003

Greg Ewing <greg(a)cosc.canterbury.ac.nz> wrote: > > Maybe, instead of there being one ultra-global namespace for importing > modules from, it should be part of a function's environment. By > default a function invocation would inherit the "import environment" > of it's caller, but the caller could override this to provide a more > restricted environment. This is a reasonable idea too. It bears an intriguing similarity to scoping in general. One can put capabilities … [View More]into local variables, and then functions and classes that you define inside that scope automatically have access to them. That doesn't work for separate modules, of course, which have no enclosing lexical scope. So your proposal seems sort of like a kind of dynamic scoping for modules, but instead of the imported module having access to all variables in the scope of the "import" statement (the *lexical* scope of the import statement), it has access to specific ones -- either a special "variables accessible to imported modules" dict or specially flagged ones, or something. For what it's worth, the solution to this problem in E is quite elegant. When code is loaded from a module, it is executed with optional arguments. So if your spam module requires a TCP socket, you can write (transliterating to Python syntax): # Python with E's parameterized import import socket import spam(socket.socket(socket.AF_INET, socket.SOCK_STREAM)) If spam needs access to the eggs module, you could write: import eggs import spam(eggs) But as Samuele Pedroni has pointed out [1] there are deeper problems here, namely that modules are currently singletons, which doesn't fit with the notion of parameterization. It also doesn't fit with security! Consider a module that is safe to use if you give it your credit card number, and safe to use if you give it a network socket, but unsafe if you give it both! Capabilities offer this kind of security -- you can arrange it so that nobody else can give privileges to an object, thus allowing you to give the object privileges which would otherwise be dangerous. This is easy with objects in cap-Python, but not with modules: ttt1 = TicTacToe() ttt1.verify_card_number(mycreditcard) ttt2 = TicTacToe() ttt2.connect_to_server(socket.socket(socket.AF_INET, socket.SOCK_STREAM)) So one design for cap-Python might say that only safe modules can be imported by cap-Python code. Every unsafe privilege would have to be granted by using references (passed as arguments, assigned to variables, etc.). No authority would ever be made available to capability-secured code through "import". This might not be much of a loss, since all of the unsafe stuff that you can currently import -- socket, os, etc. -- is rather too coarse-grained anyway and will almost certainly be wrapped in a finer-grained interface before being given to capability-confined code. Regards, Zooko http://zooko.com/ ^-- under re-construction: some new stuff, some broken links [1] http://mail.python.org/pipermail/python-dev/2003-March/034172.html [View Less]

2 1

string.strip doc vs code mismatch
by Neal Norwitz March 19, 2003

March 19, 2003

Could someone please review the patch attached to this bug: http://python.org/sf/697220 There are two patches attached--one for 2.3 and one for 2.2.3. As you may recall, there was a parameter added to all the strip methods for 2.3. This was inadvertantly backported to 2.2.2, but only for string and unicode methods. Sometime back it was decided to update the string module for 2.2.2 to stay in sync with the string/unicode methods. However, there have been various partial fixes. I … [View More]

1 0