> On 13 Jul 2016, at 10:00, Paweł Miech <pawel...@gmail.com> wrote: > > > Anyway, I’ll be spending my Twisted time on this for a while I suspect. > > This will delay HTTP/2 client support, unfortunately. =( > > Isn't it better to get HTTP2 client support and just document things better > for HTTP2? Or maybe even backport some features from CertificateOptions to > factory? DefaultSSLContextFactory seems to work ok for cases outside HTTP2. > It is not evidently broken. It is probably less secure than > twisted.internet.ssl.CertificateOptions but is really broken beyond repair?
Generally speaking I’d say it isn’t better, for a couple of reasons. Firstly, it rarely works well to document one’s way out of a usability problem. This is doubly-true when the *rest* of the documentation is contrary to what your new documentation would say. For example, the Twisted Web howto client documentation uses ClientContextFactory, which will be utterly unsuitable for HTTP/2. More generally, having two different ways to do TLS, one of which is substantially less secure and powerful than the other, is a real problem. For example, DefaultSSLContextFactory literally only works for HTTP/2 servers by chance: it was never actually *designed* to work with ALPN and only managed to do so because we refactored the implementation to have the TLSMemoryBIOFactory apply the ALPN/NPN logic. In essence, by sheer bad luck we managed to change the HTTP/2 implementation to accidentally work with the old method, when it was never planned to do so. Worse, though, is that while the ContextFactory isn’t that bad for servers, it’s *terrible* for clients. In particular, the ClientContextFactory does not use SNI, does not validate hostnames, and generally speaking does not produce secure TLS. That means I’d want to prevent the HTTP/2 client from using the ClientContextFactory *anyway*: it’s really genuinely terrible and needs to be burned with fire. If you’re interested in speeding up the arrival of HTTP/2 client support, then, the best way to do that is to help out with the deprecation effort. I’ve got patches open for the majority of the docs problems, and will be starting to work on the code problems over the next few days. All of these patches will require review, and other people writing patches will also speed things up. Basically, I’m disinclined to want to prolong the lifetime of something that was supposed to go away two years ago. Twisted has a lot of things in it that were *supposed* to be deprecated but were never *actually* deprecated, and that kind of soft deprecation ends up causing the kind of problem we’ve bumped into here, whereby a lot of people have code that “works” with current features, but new features are designed only with an eye to the best practice. On a personal level, I want to push for Twisted to *actually* deprecate things that are soft deprecated. That has the best long-term effect on the project, by reducing the amount of code that needs to be maintained and encouraging users to move towards features that function better. Cory
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
