On Oct 7, 2010, at 2:53 PM, [email protected] wrote: > (cc to both twisted and sage-devel lists) > > Hi all, > > In the Sage project (http://sagemath.org), we apply a patch to the > Twisted version we distribute. I'd like to clean out our custom patches > and push them upstream, if possible. So I have a couple of questions > (I'm not terribly familiar with Twisted): > > 1. Is the patch below generally useful?
Not really. It's not really clear what the intent of the patch is. Your subject line implies that you don't quite understand the relationship between "SSL" and "TLS". If you do, then you can disregard the following paragraph, but this may be useful to others following this thread even if you understand the distinction perfectly well already :). SSL and TLS are different names for the same protocol, with subtly different implications. "TLS" formally names a later version. The fact that "OpenSSL" has "SSL" in its name and "GnuTLS" has "TLS" in the name is simply reflective of the fact that OpenSSL has been around for longer, and was created when "SSL" was still the name of the protocol. See <http://www.ietf.org/rfc/rfc2246.txt>, section 3: "This document and the TLS protocol itself are based on the SSL 3.0 Protocol Specification as published by Netscape." "TLS" is sometimes informally used to mean "start TLS after some plaintext communication" as opposed to "initiate TLS at the start of the connection", since "STARTTLS" is usually the name of the protocol command to initiate encryption over a previously-plaintext connection. This is why Twisted has 'connectSSL' and 'listenSSL', but 'startTLS' method on a transport. If all Sage wants is to use the later version of the protocol, the technique that Itamar suggested is the right way to go; just specify the 'method' argument in your strports description, and Twisted (via OpenSSL) will already do what you want. Whereas if you actually want GnuTLS the library, rather than TLS the protocol... > 2. Is there a better way to do this than to patch the file? Yes. As suggested on <http://twistedmatrix.com/trac/ticket/4473>, there should be an extension mechanism for registering new endpoint types with a string name, just as there is a mechanism for registering new reactors and new credential factories. #4473 itself has been repurposed to be the endpoint API rather than the plugin mechanism, so I need to file a new ticket once #4473 is done for the separate extensibility bit. You could contribute a fix to that new ticket, or a review for it, if you were so inclined :). > 3. What do we need to do to incorporate it upstream in Twisted? Follow the instructions on <http://twistedmatrix.com/trac/wiki/TwistedDevelopment>. I can tell you right now that we're unlikely to support GnuTLS directly within Twisted (it's been discussed in the past and we didn't see a good reason to do it), but then, even if we were, the extension mechanism would be a probable prerequisite so that we could have a cleaner internal factoring of strports parsing mechanisms. The current mechanism (even in #4473) is not really scalable.
_______________________________________________ Twisted-Python mailing list [email protected] http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
