2013/6/3 Donald Stufft :

On Jun 3, 2013, at 1:58 AM, Benjamin Peterson wrote:

2013/6/2 Donald Stufft :

As of right now, as far as I can tell, Python does not validate HTTPS certificates by default. As far as I can tell this is because there is no guaranteed certificates available.

So I would like to propose that CPython adopt the Mozilla SSL certificate list and include it in core, and switch over the API's so that they verify HTTPS by default.

+1

Ideally this would take the shape of attempting to locate the system certificate store if possible, and if that doesn't work falling back to the bundled certificates. That way the various Linux distros can easily have their copies of Python depend soley on their built in certs, but Windows, OSX, Source compiles etc will all still have a fallback value.

My preference would be actually be for the included certificates file to be used by default. This would provide a consistent experience across platforms. We could provide options to look for system cert repositories if desired.

That's fine with me too. My only reason for wanting to use the system certs first is so if someone has modified their system certs (say to include a corporate cert) that it would ideally take affect for Python as well.

I don't think users should be able to modify stdlib behaviors (in this case could be unintentionally) without application consent.

But honestly the Linux distros will probably modify things to use system certs anyways and non Linux (esp Windows) probably doesn't have a way to get those system certs into OpenSSL.

Yes, I'm happy to let them figure it out. -- Regards, Benjamin

On Jun 3, 2013, at 12:52 PM, Barry Warsaw wrote:

On Jun 03, 2013, at 03:12 AM, Donald Stufft wrote:

...

That's fine with me too. My only reason for wanting to use the system certs first is so if someone has modified their system certs (say to include a corporate cert) that it would ideally take affect for Python as well.

This reminds me of one other thing. We have to make sure that the APIs (e.g urlopen()) continue to allow us to use self-signed certificates, if for no other reason than for testing purposes. OTOH, taking this away would be a backward incompatible change in API so probably wouldn't happen anyway.

-Barry _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/donald%40stufft.io

The other additional comment I'd like to throw in here is that if we don't bundle SSL certs I think we should still verify by default (which means HTTPS urls will throw an error by default if we can't locate a certificate store) because I think the risk to people unknowingly thinking that their HTTPS urls are protected are significant enough that this "error" shouldn't be silent by default. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

On Mon, Jun 3, 2013 at 1:04 PM, Barry Warsaw wrote:

On Jun 03, 2013, at 02:21 PM, Donald Stufft wrote:

...

The other additional comment I'd like to throw in here is that if we don't bundle SSL certs I think we should still verify by default (which means HTTPS urls will throw an error by default if we can't locate a certificate store) because I think the risk to people unknowingly thinking that their HTTPS urls are protected are significant enough that this "error" shouldn't be silent by default.

+1, especially if we ensure that the APIs are available to not verify, as is currently the case with urlopen(). I don't think people will want to do that in production, but it will be useful for testing (e.g. guess how I found issues 17977 :).

+1 from me as well. Whether we bundle or simply provide a command to download the certs I think making this default is the bare-minimum, especially if setting nothing more than cadefault=True is all that is needed to get this behaviour since that's backwards-compatible to Python 3.3.

On Mon, 03 Jun 2013 19:38:45 +1200, Ben Hoyt wrote:

Love this idea. Some third-party HTTP libraries turn this on by default in any case (eg: requests, and I think others), so this would mean Python would get their "safe-by-default" behaviour in its stdlib.

...

...

Ideally this would take the shape of attempting to locate the system certificate store if possible, and if that doesn't work falling back to the bundled certificates. That way the various Linux distros can easily have their copies of Python depend soley on their built in certs, but Windows, OSX, Source compiles etc will all still have a fallback value.

My preference would be actually be for the included certificates file to be used by default. This would provide a consistent experience across platforms. We could provide options to look for system cert repositories if desired.

Very much agreed. When the Windows version of the mimetypes module tried to use Windows' system mimetype mappings by default, chaos and bugs ensued (for example, http://bugs.python.org/issue15207 and http://bugs.python.org/issue10551).

On the other hand, the fact that it uses /etc/mimetypes on unix does *not* cause chaos, quite the opposite: it means Python recognizes new mime types provided by the distro automatically, which provides for a more consistent experience for the Python application user. The situation for certs is probably fairly parallel: on unix, it would probably be an advantage as Python would automatically follow distro decisions about cert chains, while on windows trying to use a system cert store would probably be a disaster. An application can choose to explicitly ignore the system mimetypes file, by the way. That said, I don't feel strongly either way about the cert store case. --David

On Mon, 3 Jun 2013 21:37:10 +1200 Ben Hoyt wrote:

I'm not familiar with Unix/Linux, but on Windows, if it's anything like mimetypes it'll be really hard to get consistent behaviour across different boxes/versions from the registry, or wherever certs might be stored on Windows. I'd much rather have a slightly outdated but consistent experience by default.

The problem with a "slightly outdated" CA store is that it can be a security risk. Regards Antoine.

On Jun 3, 2013, at 5:51 AM, Antoine Pitrou wrote:

On Mon, 3 Jun 2013 21:37:10 +1200 Ben Hoyt wrote:

...

I'm not familiar with Unix/Linux, but on Windows, if it's anything like mimetypes it'll be really hard to get consistent behaviour across different boxes/versions from the registry, or wherever certs might be stored on Windows. I'd much rather have a slightly outdated but consistent experience by default.

The problem with a "slightly outdated" CA store is that it can be a security risk.

Regards

Antoine.

_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/donald%40stufft.io

Tracking the Mozilla store isn't difficult. New additions can be ignored for currently released Pythons so we'd just need to watch them for blacklisting certs and roll that into a security update. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

On Jun 3, 2013, at 12:52 PM, Ethan Furman wrote:

On 06/03/2013 09:43 AM, Donald Stufft wrote:

...

On Jun 3, 2013, at 5:51 AM, Antoine Pitrou wrote:

...

The problem with a "slightly outdated" CA store is that it can be a security risk.

Tracking the Mozilla store isn't difficult. New additions can be ignored for currently released Pythons so we'd just need to watch them for blacklisting certs and roll that into a security update.

Personally, I'm not interested in waiting six months for an update. And why can't I have the new additions?

Seems to me a better solution is to have routines that can query and update at will (meaning the app has to call them), as well as having the bundle (black lists as well as new additions) in the regular updates.

-- ~Ethan~ _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/donald%40stufft.io

Personally I view that as a nice to have but if an app is willing to call hem they can easily depend on certifi and just replace the default certificates. The goal here is to get secure by default without any work on the part of the developers. If a developer knows to update the certs they can know to use certifi. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

On Mon, 3 Jun 2013 12:43:32 -0400 Donald Stufft wrote:

On Jun 3, 2013, at 5:51 AM, Antoine Pitrou wrote:

...

On Mon, 3 Jun 2013 21:37:10 +1200 Ben Hoyt wrote:

...

I'm not familiar with Unix/Linux, but on Windows, if it's anything like mimetypes it'll be really hard to get consistent behaviour across different boxes/versions from the registry, or wherever certs might be stored on Windows. I'd much rather have a slightly outdated but consistent experience by default.

The problem with a "slightly outdated" CA store is that it can be a security risk.

Regards

Antoine.

_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/donald%40stufft.io

Tracking the Mozilla store isn't difficult. New additions can be ignored for currently released Pythons so we'd just need to watch them for blacklisting certs and roll that into a security update.

Let's see if our security release managers want to do that job. Regards Antoine.

On Jun 3, 2013, at 12:48 PM, Barry Warsaw wrote:

On Jun 03, 2013, at 09:05 AM, Ben Darnell wrote:

...

The data is analogous to the time zone database (PEP 431) in that it may need to be updated independently of Python's own release schedule, so we may want to use similar techniques to manage both. Also see certifi ( https://pypi.python.org/pypi/certifi), which is a copy of the Mozilla list in a pip-installable form.

Right, this is very much analogous, except with the additional twist that out-of-date certificates can pose a significant security risk.

I'm fairly certain that Debian and Ubuntu would explicitly not use any certificates shipped with Python, for two main reasons: 1) our security teams already manage the certificate store distro-wide and we want to make sure that one update fixes everything; 2) we don't want to duplicate code in multiple packages[1].

So *if* Python decides to do this (and I'm -0, but from a decidedly Linux-distro bias), it must be easily disabled. I generally like the way PEP 431 handles the tzdata, so I think we should do the same here.

I'd actually prefer for Linux to not use the bundled certs when installed from a package manager because it should use the system certs, but people can't depend on certs being there if they are only there on linux. Adding them into Python means people _can_ depend on them being there, and Windows and other systems without system integrators to modify it to use the system store will still get certs and Ubuntu can make it just work(™).

-Barry

[1] This gives us headaches in upstreams like coverage caused by bundling externally available JavaScript libraries, or like urllib3 bundling chardet and urllib3, not to mention their own certificates yet again. :(

This would probably (eventually) make the bundling of certificates better too. Meaning that once it's been in long enough people are willing to depend on it, they won't need to bundle their own certs and ubuntu/debian can just modify the one location instead of needing to modify it for every package that does it.

_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/donald%40stufft.io

----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

On Jun 3, 2013, at 1:07 PM, Barry Warsaw wrote:

On Jun 03, 2013, at 02:17 PM, Donald Stufft wrote:

...

I'd actually prefer for Linux to not use the bundled certs when installed from a package manager because it should use the system certs, but people can't depend on certs being there if they are only there on linux.

I think we agree on that.

...

Adding them into Python means people _can_ depend on them being there, and Windows and other systems without system integrators to modify it to use the system store will still get certs and Ubuntu can make it just work(™).

Again, I think PEP 431 provides a pretty good model for how this should be done. Maybe it's worth factoring out this specific part of PEP 431 into an informational PEP?

Looks fine to me minus the not updating in security releases (but that's just a difference in the type of data).

...

This would probably (eventually) make the bundling of certificates better too.

Meaning that once it's been in long enough people are willing to depend on it, they won't need to bundle their own certs and ubuntu/debian can just modify the one location instead of needing to modify it for every package that does it.

Can we do the same for the JavaScript libraries? :)

-Barry

----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

On Jun 3, 2013, at 12:36 PM, Barry Warsaw wrote:

On Jun 03, 2013, at 01:20 AM, Donald Stufft wrote:

...

So I would like to propose that CPython adopt the Mozilla SSL certificate list and include it in core, and switch over the API's so that they verify HTTPS by default. This is what most people are going to expect when using a https url (Especially after learning that Python 2.x doesn't verify TLS, but Python 3.x "does").

For the "verify HTTPS by default", do you mean specifically changing the cadefault argument to urllib.request.urlopen() to True? Note that I recently closed a bug related to this:

http://bugs.python.org/issue17977

+1 for changing the default to True.

-Barry _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/donald%40stufft.io

If that's all it takes to make sure that people have to opt out of an invalid certificate throwing an error than yes :) My goal here is to make it that when someone accesses a TLS secured network resource (I said HTTP, but if there are other things, xmlrpclib, or what not where people can reasonably expect valid TLS certificates those too) they are protected by a MITM attack by default. I worry with the current situation people will just use TLS connections without realizing it's not being verified and thinking they are "safe". As with most things security the outcome of "failing" to do it right when the default is insecure is well nothing until someone attacks you. So Hopefully we make things secure by default for folks :) ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

On 06/03/2013 11:34 AM, Antoine Pitrou wrote:

On Mon, 3 Jun 2013 14:12:34 -0400 Donald Stufft wrote:

...

I worry with the current situation people will just use TLS connections without realizing it's not being verified and thinking they are "safe".

Yet there's quite a visible warning in the docs: http://docs.python.org/dev/library/urllib.request.html

As has been been mentioned elsewhere, at the very least we should change cadefault to True for secure-type connections. The dangerous/unexpected behavior should not be the default. -- ~Ethan~

Am 03.06.2013 21:52, schrieb Antoine Pitrou:

cadefault=True will probably be fail if the system certs are not properly configured in OpenSSL, e.g. under Windows or with a hand-made OpenSSL build. And, because of the way the OpenSSL API works, there's no way of knowing if it is the case or not: http://docs.python.org/3.4/library/ssl.html#ssl.SSLContext.set_default_verif...

I only see an issue for uncommon Linux distributions and exotic Unices. For Windows an interface to crypt32 API solves the CA issue as shown in my wincertstore module. It gives the user the same SSL experience as Internet Explorer. Most Linux and BSD-ish operating systems have SSL certs at some standard location. https://bitbucket.org/pypa/setuptools/src/6de3186fdfd9f5b543380e9aca2d48976c... lists a couple of standard locations. Under which conditions do we need to ship a CA cert file? Christian

In article <699D9AB5-26E0-4CCE-89C5-8E92C3305BDE@stufft.io>, Donald Stufft wrote:

On Jun 3, 2013, at 4:19 PM, Christian Heimes wrote:

...

Most Linux and BSD-ish operating systems have SSL certs at some standard location. https://bitbucket.org/pypa/setuptools/src/6de3186fdfd9f5b543380e9aca2d48976c fc38cd/setuptools/ssl_support.py?at=default#cl-15 lists a couple of standard locations. Under which conditions do we need to ship a CA cert file? What about OSX?

OS X has an actively managed set of CA certs, by Apple and with provision for users to tailor their security policies (add/modify/delete certs and their policies via either a gui or cli). For python.org OS X installers, we currently depend on the system-provided versions of libssl and libcrypto which use the system/user cert infrastructure. But Apple has deprecated the OpenSSL-compatible APIs and we have an open issue (Issue17128) to move to supplying our own copy of OpenSSL libs. One hangup has been what to do about the certs. One solution would be to use a Python distribution of them as discussed here. Another, probably better for users, solution is to continue to use the existing system/user cert infrastructure; recently, we've seen a new approach to that which we need to look into: http://bugs.python.org/issue17128#msg189244. Third-party distributors of Python on OS X may use other solutions; for example, MacPorts already ships and links with its own version of OpenSSL. -- Ned Deily, nad@acm.org

On 3 June 2013 21:05, Chris Angelico wrote:

+1 for having the default be safe, but this will have to be very loudly announced ("when migrating from 3.3 to 3.4, TLS connections will cease to work if blah blah").

+1 on the default being safe, certainly. But with the proviso that the same code should work in 3.3 and 3.4, with no user impact (other than that the connection is safer, but that's not user-visible unless there's an attack :-)) In other words, that "will cease to work" clause should not exist - but see below...

Some legit sites with proper certificates still manage to muck something up administratively (developer.quicksales.com.au has a cert from RapidSSL but doesn't bundle the intermediates, and I've told their devs about it, but all I can do is disable cert checking). This will break code in ways that will surprise people greatly. But I'd still rather the default be True.

I'm happy if the "will cease to work" clause only says "some sites with broken security configurations may stop working" with a clear explanation that it is *their* fault, not Python's. I'd also expect that the same sites would fail in browsers - if not, we should also be able to make them work (or face cries of "well, Internet Explorer/Firefox doesn't have a problem with my site, why does Python?"). Also, we should consider the issue for application users. Suppose I'm using a Python application that downloads something from the web. I upgrade to 3.4, and the app stops working because of a "will cease to work" case. As an end user, how can I get the app working again? Having to patch the sources isn't an option, and reverting to 3.3 provokes the reaction "Python broke my app". Summary - I'm +1 as long as either the "will cease to work" list is empty, or we have a *very* good story for (legitimate) sites which do cease to work. Paul.

On Jun 3, 2013, at 5:41 PM, Antoine Pitrou wrote:

On Mon, 3 Jun 2013 22:31:40 +0100 Paul Moore wrote:

...

...

Some legit sites with proper certificates still manage to muck something up administratively (developer.quicksales.com.au has a cert from RapidSSL but doesn't bundle the intermediates, and I've told their devs about it, but all I can do is disable cert checking). This will break code in ways that will surprise people greatly. But I'd still rather the default be True.

I'm happy if the "will cease to work" clause only says "some sites with broken security configurations may stop working" with a clear explanation that it is *their* fault, not Python's. I'd also expect that the same sites would fail in browsers - if not, we should also be able to make them work (or face cries of "well, Internet Explorer/Firefox doesn't have a problem with my site, why does Python?").

Keep in mind that not every HTTPS service is a Web site that is meant to be readable with a browser. Some are Web services, possibly internal, possibly without a domain name (and, therefore, probably a non-matching certificate subject name).

They should need to explicitly opt in to disabling the checks that allow that to work.

Regards

Antoine.

_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/donald%40stufft.io

----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

On Jun 3, 2013, at 5:51 PM, Antoine Pitrou wrote:

On Mon, 3 Jun 2013 17:47:31 -0400 Donald Stufft wrote:

...

On Jun 3, 2013, at 5:41 PM, Antoine Pitrou wrote:

...

On Mon, 3 Jun 2013 22:31:40 +0100 Paul Moore wrote:

...

...

Some legit sites with proper certificates still manage to muck something up administratively (developer.quicksales.com.au has a cert from RapidSSL but doesn't bundle the intermediates, and I've told their devs about it, but all I can do is disable cert checking). This will break code in ways that will surprise people greatly. But I'd still rather the default be True.

I'm happy if the "will cease to work" clause only says "some sites with broken security configurations may stop working" with a clear explanation that it is *their* fault, not Python's. I'd also expect that the same sites would fail in browsers - if not, we should also be able to make them work (or face cries of "well, Internet Explorer/Firefox doesn't have a problem with my site, why does Python?").

Keep in mind that not every HTTPS service is a Web site that is meant to be readable with a browser. Some are Web services, possibly internal, possibly without a domain name (and, therefore, probably a non-matching certificate subject name).

They should need to explicitly opt in to disabling the checks that allow that to work.

Obviously, which means compatibility is broken with existing code.

Regards

Antoine. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/donald%40stufft.io

Yes in that case compat will be broken and they'll need to either specify a cert that can be used to validate the connection or disable the protection. I think it's very surprising for people that they need to *enable* secure mode when most tools have that on by default. It's handing users a security foot gun, and like most things security related "broken" is silent until it's too late. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

On Jun 3, 2013, at 5:31 PM, Paul Moore wrote:

On 3 June 2013 21:05, Chris Angelico wrote: +1 for having the default be safe, but this will have to be very loudly announced ("when migrating from 3.3 to 3.4, TLS connections will cease to work if blah blah").

+1 on the default being safe, certainly. But with the proviso that the same code should work in 3.3 and 3.4, with no user impact (other than that the connection is safer, but that's not user-visible unless there's an attack :-))

If we bundle certs that will be the case sans connections where it doesn't validate.

In other words, that "will cease to work" clause should not exist - but see below...

Some legit sites with proper certificates still manage to muck something up administratively (developer.quicksales.com.au has a cert from RapidSSL but doesn't bundle the intermediates, and I've told their devs about it, but all I can do is disable cert checking). This will break code in ways that will surprise people greatly. But I'd still rather the default be True.

I'm happy if the "will cease to work" clause only says "some sites with broken security configurations may stop working" with a clear explanation that it is *their* fault, not Python's. I'd also expect that the same sites would fail in browsers - if not, we should also be able to make them work (or face cries of "well, Internet Explorer/Firefox doesn't have a problem with my site, why does Python?").

Browsers tend to download intermediate certs while I don't think Python does.

Also, we should consider the issue for application users. Suppose I'm using a Python application that downloads something from the web. I upgrade to 3.4, and the app stops working because of a "will cease to work" case. As an end user, how can I get the app working again? Having to patch the sources isn't an option, and reverting to 3.3 provokes the reaction "Python broke my app".

Supply a SSL vert using the environment variable?

Summary - I'm +1 as long as either the "will cease to work" list is empty, or we have a *very* good story for (legitimate) sites which do cease to work.

Paul. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/donald%40stufft.io

----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

On Jun 3, 2013, at 6:01 PM, Paul Moore wrote:

On 3 June 2013 22:46, Donald Stufft wrote:

...

Also, we should consider the issue for application users. Suppose I'm using a Python application that downloads something from the web. I upgrade to 3.4, and the app stops working because of a "will cease to work" case. As an end user, how can I get the app working again? Having to patch the sources isn't an option, and reverting to 3.3 provokes the reaction "Python broke my app".

Supply a SSL vert using the environment variable?

Hmm, that would be acceptable, I guess, for many users (although Windows users are somewhat more environment-variable-averse than Unix users). But you say that as if it's obvious how to do that (or where to get a cert). It's certainly not obvious to me, and if "it works in Internet Explorer", I'd have no idea where to get a cert from that I could use in an environment variable.

Just to repeat - I agree with the principle, but in many environments, users are pretty much clueless about security and actively object to being educated "for their own safety". These users will disable all security quite happily if it stops the internal app failing, and will blame Python for "making things harder" and breaking backward compatibility. On the other hand, I suspect we're talking about an extremely low percentage of cases, so let's not blow the issue out of proportion :-)

Paul

Let me make myself a bit more clear because maybe I haven't been. If someone is relying on the insecure by default behavior and Python 3.4 gets this change, their code will break and their options will be: Client side: - Disable Verification, essentially reverting back to the old behavior. - Setup their Python install to be able to validate that certificate - This may be importing it into their OS certificate store - This may be using an env var to specify - This may be passing it directly somewhere Server side: - Make the certificate valid - Purchase a Valid by default certificate - Serve immedaries etc. Generally any of these will be completely valid options, even disabling the checks. The idea behind my proposal is that people generally only use TLS for a reason and that reason is they want to protect against the kinds of attacks that TLS protects against. You really only get the bulk of those protections if you validate the certificates. So for the vast bulk of people validation is the option they want. It also happens that validation on by default is "secure" by default which aims a fairly large foot gun away from peoples feet. To expand on something else, I'm completely willing to do whatever I can to hep make this happen. I don't really know what the process is. If I need to write a PEP I'll do that. If I need to volunteer to manage the certificates, I'll do that. If we need docs or tooling to help the people who this change might break I'll do that too. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA