> On Oct 18, 2017, at 20:31, Simon Sapin <simon.sa...@exyr.org> wrote: > > Servo downloads appropriate versions of Rust and Cargo using Python’s > urllib2. At some point, https://static.rust-lang.org started requiring TLS > SNI (I think when it moved to a CDN?) and we had issues with downloads > failing on CI or on contributor’s machines because of old Python versions. > > So we moved to using https://static-rust-lang-org.s3.amazonaws.com instead, > which does not require SNI. However, that URL is not considered stable: > > https://internals.rust-lang.org/t/public-stable-rust-services/6072 > > I don’t expect it’ll go away any time soon, but we should still consider not > relying on it. > > > I propose that we move back to using https://static.rust-lang.org, and > document that Python 2.7.9 or more recent is required, and print a warning > when and older version is used. > > Support for SNI was added in 2.7.9, which was released in December 2014. > Debian has had a recent enough default version since Debian 8.0 Jessie > released in April 2015, and Ubuntu since Vivid Vervet 15.04 released in April > 2015. > > Travis-CI still uses Ubuntu 14.04 LTS, but using 'language: python' in > .travis.yml gives an environment with a recent enough Python version.
Having somewhat recently overhauled Mercurial’s TLS code, I can tell you that Python installs without the ssl module additions added in 2.7.9 are still quite common in the wild. I suspect that requiring SNI support in the Python client will draw ire from a significant population. Also, there are versions of Python <2.7.9 that have the ssl module improvements backported. For example, RHEL/CentOS 7 ship a Python 2.7.5 that has all the ssl goodies from 2.7.9. So please look for presence of attributes on the ssl module instead of version sniffing. If I were in your shoes, I would provide a hostname without SNI as a fallback. (I’m assuming you aren’t willing to do non-SNI CDN for cost reasons - last I looked this was somewhat costly.) I.e. the script would attempt to use CDN+SNI and fall back to a single homed service if the client lacks modern crypto. Assuming you are using CloudFront backed by S3, the fallback could be the generic per-region S3 hostname. This is how we handle “clone bundle” hosting for hg.mozilla.org. _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
