[Python-Dev] RFC - proposal for urilib. unified module of urlparse, urllib and urllib2
Hello All, I am drafting a PEP proposing a module 'urilib', which will be the unified module of urlparse, urllib and urllib2. a) _all_ functions will include from urlparse,urllib and urllib2. b) overlapping functionality between urllib and urllib2 to be ironed out. c) RFC3986 and RFC3987 compliant. Cleanup task of urllib was my G-SoC, and this unified module is a suggestion with python 2.6 in mind. I would like to know your thoughts on - How should we plan to maintain the backward compatiblity? - What other features should be kept in mind while designing? Thanks, Senthil -- O.R.Senthil Kumaran http://uthcode.sarovar.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] More on server-side SSL support
> The idea is that if you call socket.ssl() on a socket that's bound to > an address, the socket is assumed to be server-side, the cert passed > in is assumed to be a server-side cert, and the SSLObject returned has > a couple of extra methods, listen() and accept(). Calling accept() does > the SSL dance with the remote side, and returns an SSLObject. After looking at the code a bit more, I think it's wrong to use SSLObject for both of these uses. Instead, it makes more sense to introduce a different C-implemented object, SSLServerPort, which supports only the method "accept". So the Pythonic change will be that calling socket.ssl() will call the "getpeername" method on the socket, and if it doesn't have one, will assume it's server-side, and construct and return an SSLServerPort instance instead of doing the SSL dance and returning SSObject. Code using this will then call listen on the SSLServerPort, and when a connection is requested, will call "accept" to do the server-side SSL dance, which if successful will return an SSLObject. I intend to add a method to SSLObject, "peer", which will be functionally equivalent to the current "server" method, which returns a string version of the name of the server the socket is connected to. We'd deprecate the use of "server", and replace it with "peer" over time. Similarly, internally in _ssl.c, the "server_cert" slot of SSLObject will become "peer_cert". I'm very tempted to add an optional parameter to socket.ssl(), which will be a callback function which will be passed the remote side's IP address and credentials, and which may raise an exception if it doesn't like the credentials. The exception would then be re-raised from socket.ssl() (on the client side) or SSLServerPort.accept() (on the server side). The callback function would of course default to None which would give the current behavior. This is different from the built-in SSL verify function, which just checks the certificate chain. This could do things like only allowing particular clients to reach the server; it would also work on the client side, allowing a client to check the credentials of the server. The problem with doing this is that we'd also need to devise a Python object wrapper for the cert itself, with an appropriate API. More work. Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RFC - proposal for urilib. unified module of urlparse, urllib and urllib2
O.R.Senthil Kumaran schrieb: > Hello All, > > I am drafting a PEP proposing a module 'urilib', which will be the unified > module of urlparse, urllib and urllib2. > > a) _all_ functions will include from urlparse,urllib and urllib2. b) > overlapping functionality between urllib and urllib2 to be ironed out. c) > RFC3986 and RFC3987 compliant. > > Cleanup task of urllib was my G-SoC, and this unified module is a suggestion > with python 2.6 in mind. > > I would like to know your thoughts on - How should we plan to maintain the > backward compatiblity? - What other features should be kept in mind while > designing? In any case, you should probably be ready to write and maintain a PEP to keep track of suggestions and proposals in case there are many of them, or inclusion in 2.6 is debated. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] More on server-side SSL support
> I'm very tempted to add an optional parameter to socket.ssl(), which > will be a callback function which will be passed the remote side's IP > address and credentials, and which may raise an exception if it > doesn't like the credentials. The exception would then be re-raised > from socket.ssl() (on the client side) or SSLServerPort.accept() (on > the server side). The callback function would of course default to > None which would give the current behavior. This is different from > the built-in SSL verify function, which just checks the certificate > chain. This could do things like only allowing particular clients to > reach the server; it would also work on the client side, allowing a > client to check the credentials of the server. The problem with doing > this is that we'd also need to devise a Python object wrapper for the > cert itself, with an appropriate API. More work. A simpler way of doing this would be to just have the "peer" call on SSLObject return a read-only mapping giving the entities in the peer certificate (or None, or host and port, if there is no peer certificate). Then the application can look at this before working with it, and decide whether to communicate with the remote end. It would still be nice to add a flag argument to socket.ssl() to allow the application to control the level of verification for the remote certificate. CERT_NONE would mean that no cert is required, or if provided not verified (SSL_VERIFY_NONE). CERT_OPTIONAL would mean that no cert is required, but if one is provided, it's verified (SSL_VERIFY_PEER). CERT_REQUIRED would require a cert to be provided, and would verify it (SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT). The default SSL verify procedure would be used for verification. The default would be CERT_NONE, which is what is currently used. Now, does this mean that we'd need to create a database of trusted certs, similar to Java's trustStore and various OS X keychains? I'm not sure how useful verification will be without such a facility? I see that there was some discussion about this in December, which I missed earlier. http://mail.python.org/pipermail/python-list/2006-December/418511.html And of course there has been discussion about SSL in general: http://mail.python.org/pipermail/python-dev/2005-June/054083.html http://mail.python.org/pipermail/python-dev/2001-October/018161.html There's a list of failings of the current SSL support by Gerhard HÂring: - no support for specifying the SSL protocol (SSL v2/SSL v3/SSL v2|3) (I wasn't planning to touch that. The current code uses v2|3. However, this might be a good time to fix this, too. It would be simple to provide an optional keyword protocol argument to socket.ssl().) - no proper certicate checking (See above discussion of verification.) - SSL objects are neither compatible with sockets nor are they file-like objects (Don't currently intend to change this.) - no advanced features like SSL callbacks (to allow the user to accept a cerficicate, for example) (Providing more information about the peer cert would halfway address this.) And there is the pyOpenSSL library, from http://mail.python.org/pipermail/python-dev/2001-July/015855.html, now at http://pyopenssl.sourceforge.net/. It would be nice if we could just use that X509 object type to allow the app to get its hands on the peer cert, but it's GPL'd code. Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
