Created attachment 324526 [details] Add a few features to python-nss Version-Release number of selected component (if applicable): python-nss-0.1-1.fc10 The attached patch adds various functionality I needed to python-nss. I'm afraid some of the interface additions are rather hacky, I might be able to offer cleaner implementations later if necessary. The changes in the patch: * #include "private/pprio.h"; drop conflicting typedefs. * Don't allow closing a socket twice, that causes crashes. * New function nss.io.Socket.new_socket_pair() * New function nss.io.Socket.poll() This interface is quite bad (for example, it doesn't allow reusing the storage for repeated polling). Even I am using a wrapper for this interface: def _nspr_poll(descs, timeout): '''Poll for descs. descs is a dictionary of {nss.io.Socket: flags}. On return, flags are updated with poll results. ''' flat = descs.items() res = nss.io.Socket.poll(flat, timeout) for (i, desc) in enumerate(flat): descs[desc[0]] = res[i] * New function nss.io.Socket.import_tcp_socket() * New method nss.nss.Certificate.get_subject_common_name() This would probably be cleaner by wrapping CERTName separately, and providing a 'common_name' property. * New function nss.nss.generate_random() * Fix return value creation in SSLSocket.get_security_status * New function nss.ssl.SSLSocket.import_tcp_socket()
Thank you for the patch. I have not had an opportunity to review it yet, however at first blush I'm concerned about import_tcp_socket(). Are you planning on passing at a socket.socket().fileno()? If so you can get yourself in trouble because operations on Python's native sockets are not identical to PRFileDesc sockets. In particular you cannot set blocking status on an fd because NSPR does not respect the OS's blocking flag. That is one of the reasons I choose not to export that API entrypoint. Without some "hackery" in the binding you really have to use the NSPR entrypoints to operate on an NSPR socket, trying to mix Python's API and NSPR's API will cause problems. One way to guarentee users do not mix the API's is to not allow them to, unfortunately exposing this entrypoint opens the backdoor to problems. If one is not planning on mixing the API's there is no reason to allow the exchange of fd's between the API's.
I'm doing something rather unusual: I need a TLS session inside another TLS session (the "outer" TLS session connects to an application-level proxy, the "inner" session is used for communication that is protected against tampering by the proxy). To do this, I use two processes connected by a socketpair. (Omitting some details,) process A opens a SSLSocket to the proxy and just transfers data between the socketpair and the SSLSocket, thus implementing the "outer" TLS session. Process B imports the socketpair socket into another SSLSocket, implementing the "inner" TLS session. Both processes need to convert the socketpair socket into a NSS Socket (nss.io.Socket in process A, nss.ssl.SSLSocket in process B). This can be done in C by using PR_NewTCPSocketPair() in the parent, and SSL_ImportFD() in process B. Rather than try to implement SSL_ImportFD() in python-nss, which implies ugly lifetime issues (Python code can keep a reference to the imported socket, but it must not be used (not even closed) after the import), I'm creating a non-NSS socket and importing it in both children, in one using nss.io.Socket.import_tcp_socket(), in other using nss.ssl.SSLSocket.import_tcp_socket() - nss.ssl.SSLSocket.import_tcp_socket() makes the socket "consumed" by SSL_ImportFD() invisible to Python. Yes, it implies some discipline, but so does not calling any SSL function before nss_init, which crashes the process, or not even importing the "rpm" module, which calls NSS_NoDB_Init() and breaks any future calls to nss_init(). That's life with NSS, I guess.
Just wanted to add that the patch works great for me. With that I'm able to upgrade an existing TCP connection to TLS. Any chance that this gets included in python-nss soon?
Thank you for the patch. It has been applied and will appear in python-nss-0.2 in the next day or two in FC-9, FC-10, and rawhide, F-11 will have to wait until it's unlocked.
F-11 isn't locked - updates can be built and pushed as normal, and they're available for download: http://download.fedora.redhat.com/pub/fedora/linux/updates/11/SRPMS/ http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/11/SRPMS/
John, can you publish python-nss-0.3 as an F11 update, please?
python-nss-0.4-1.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/python-nss-0.4-1.fc11
I've pushed the newest python-nss-0.4 into testing for F-11. Let me know if have no problems, and I'll push it into stable sooner.
FYI: renaming ssl.nss_init to nss.nss_init and ssl.nss_shutdown to nss.nss_shutdown should not break existing code so I just build a new package which restores ssl.nss_init and ssl.shutdown, but marks them as deprecated. I also added a version string to the package: nss.__version__ I'll push the new 0.5 package into stable in F-11, the only changes with respect to 0.4 are noted above.
python-nss-0.6-2.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/python-nss-0.6-2.fc11
python-nss-0.6-2.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/python-nss-0.6-2.fc10
python-nss-0.6-2.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
python-nss-0.6-2.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.