Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add TLS Debugging #1131

Open
wbond opened this issue Jul 29, 2016 · 3 comments
Open

Add TLS Debugging #1131

wbond opened this issue Jul 29, 2016 · 3 comments

Comments

@wbond
Copy link
Owner

wbond commented Jul 29, 2016

Due to the number of users who have weird issues with TLS and proxies, I believe some functionality should be added to debug TLS connections.

Additionally it would be nice if there was a simple way using oscrypto.tls and certvalidator to grab the chain of certs and show the user which cert would need to be added to their user bundle to get TLS working again.

@con-f-use
Copy link

From what I see, some functionality should be added to (optionally!) disable secure connections or support SOCKS proxies.

@wbond
Copy link
Owner Author

wbond commented Jul 25, 2017

I don't have the intention of ever implementing, nor accepting a PR to disable TLS in Package Control. That is a Very Bad Idea, which makes it easy for your machine to have arbitrary Python code run on it. You could walk into a coffee shop and have a rogue version of Package Control upgraded to, that sets up a trojan, uploads all of your code to a public location, etc.

I welcome anyone who wants to implement SOCKS proxy support, or help improve the TLS layer.

@con-f-use
Copy link

con-f-use commented Jul 26, 2017

I was more thinking of an option to disable it temporarily in certain circumstances. For instance where I work we have a strange setup of SSL interception, multiple firewalls and content scanning. Even if I add the certificate to Package Control.user-ca-bundle and/or add the proxy and/or use tsocks/porxychains for sublime, I cannot get Package Control to work. I tried curl and wget as downloaders as well. As a last resort measure it has it's use cases. You could also allow to pass options such as -k to curl or --no-check-certificate to wget. Non-power-users are less likely to know these and misuse them. After all it's my choice and my risk if I want to disable security features. I agree they should be the strong and overwhelming default but not at the cost of user freedom.

Btw. if one was really serious about it, one could just replace wget/curl by a wrapper that removes the security options.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants