tunneling socket could not be established statuscode=407 on searching packages in atom

[devshinoy]

[ukdor]

I and others at my company are having the same issue. We upgraded from 1.19.5 to the 1.25.0 release and now we can't search packages or themes. Featured Packages and Updates are working fine.

I've attempted to set my proxy, http-proxy, and https-proxy values in .apmrc (previously it worked with just proxy=) and still nothing. Something is wrong in since 1.19.0. I can't install or test other versions due to corporate approvals.

[smashwilson]

Looks related to atom/atom#16964. At some point, apm regressed on handling TLS configuration or authentication for proxies.

[aadrian]

The proposed setting in atom/atom#16964 does not seem to fix it on Win 7 machines :( .

This renders Atom practically useless in most corporate environments.

[ygorduraes-old]

Problem still persists in version 1.26.1, still waiting for a fix so I can use Atom through my corporate firewall

[andyakins]

I'm seeing the same issue. Checked proxy settings, etc... no luck

[karigunnarsson]

Not sure if it's the same issue or a settings/local problem (new user so i don't have the luxury of knowing if my settings worked with previous editions), but mine works ... sometimes? I can't see any rhyme or reason to it, but sometimes i can search and install plugins/themes, but most of the time i get a 407, with no change to settings.

Have proxy setup with username/password, on a Windows7 machine behind a corporate firewall. Both http-proxy and https-proxy are set, and strict-ssl=false in the .apmrc file.

[jarecsni]

Same here. Is there any interest in fixing this?

[kurankat]

I am having the same issue. It looks like this bug has been kicking around for 5 months now.

EDIT: The below did not work, I soon started having issues with installed packages.

I was able to get around it by doing the following (I have a Windows 7 standalone installation with .atom in the parent folder):

• I noticed that apm was looking for config in my home folder under my username\.atom.
• I set up config for the proxy under .apmrc in my home folder
• I verified the config was being loaded apm config list
• I used apm-install to install the packages
• I moved the packages to the original .atom folder

I suspect it is whatever Atom is using to search for the packages (and not the installation process) that is throwing the exception. Happy to try and help debug if useful.

[vlucian]

check my update on https://github.com/atom/settings-view/issues/1063

[ukdor]

vlucian, Thanks for sharing what worked for you. I've attempted to startup atom with the --proxy-server argument. This resulted in my search no longer returning the original 407 error. Instead it now reported connect etimedout. So it got a different result, but still not working. The Featured packages are still displaying properly, so the "search" function is still the focus.

[vlucian]

do you have your proxy settings like this? https-proxy=http://USERNAME:PASSWORD@domain:port if that doesn't work then try to use a local cntlm proxy.

[Frontrider]

That is not a solution since my company explicitly forbids that program.

npm works perfectly with the exact same settings.

I get this error, and nothing works, not the search, not the features.

[leehyunuk]

kurankat: thank you so much! it works. basically, I checked the .apmrc file in my local directory, and that file has some duplicates (and "strict-ssl false" as well) that caused the error. after setting only proxy for http and https, Atom is working beautifully as ever before.

[AndyOGo]

Same for me 😞 Behind Enterprise Proxy, using Fiddler with automatic authentication enabled.

[Edit]: Seems I had to actiave Fiddler's system proxy option 🤔

Running:

apm install revert-buffer

Errors with

Installing revert-buffer to C:\Users\userfoo.atom\packages failed Request for package information failed: tunneling socket could not be established, cause=connect ECONNREFUSED 127.0.0.1:8888 (5 attempts) (ECONNRESET)

I have followed the readme for firewall and proxy, here is my config:

apm config ls

; cli configs
globalconfig = "C:\\Users\\userfoo\\.atom\\.apm\\.apmrc"
metrics-registry = "https://registry.npmjs.org/"
scope = ""
user-agent = "npm/6.2.0 node/v8.9.3 win32 x64"
userconfig = "C:\\Users\\userfoo\\.atom\\.apmrc"

; environment configs
node-gyp = "C:\\Users\\userfoo\\AppData\\Local\\atom\\app-1.32.2\\resources\\app\\apm\\bin\\\\..\\node_modules\\node-gyp\\bin\\node-gyp.js"

; userconfig C:\Users\userfoo\.atom\.apmrc
http-proxy = "http://127.0.0.1:8888/"
https-proxy = "http://127.0.0.1:8888/"
proxy = "http://127.0.0.1:8888/"
strict-ssl = false

; globalconfig C:\Users\userfoo\.atom\.apm\.apmrc
cache = "C:\\Users\\userfoo\\.atom\\.apm"
progress = false

; node bin location = C:\Users\userfoo\AppData\Local\atom\app-1.32.2\resources\app\apm\bin\node.exe
; cwd = C:\Users\userfoo\projects\ecme-react
; HOME = C:\Users\userfoo
; "npm config ls -l" to show all defaults.

[contang0]

Same here. Atom is unusable for all developers in my organisation.

[Frontrider]

Still going to use atom at home, but switching over to vs code at the workplace for now.

[jarecsni]

It's beyond me. Atom is hands down better than VSCode and still this issue of proxy configuration is left unattended. What can be the reason for this? This is clearly rendering Atom unusable in a corporate context, and often people want to use the same IDE everywhere, so it does cast a shadow on the future of Atom...

[sethbergman]

If it weren't for the package sync-settings I'd be completely unable to use atom behind my corporate proxy as well. I forked my original gist and created a new access token after the first backup (restore) on my work laptop. Hopefully this will help those in need of their custom atom settings until the proxy issues are resolved.

[contang0]

@sethbergman, sorry, I don't understand what this solves? I can get my settings from sync-settings relatively easily as well, but packages won't install no matter what.

For an editor which positions itself as the most hackable there is, this is really a deal breaker.

[sethbergman]

You have to connect to a different network in order to download and install the packages. If that's impossible for you then this is of no help.

[contang0]

Indeed, it isn't possible for me.

[jarecsni]

This forum doesn't seem to be getting much attention from the developers... top issue was opened a month ago, noone replied. I'm not trying to blame anyone, just trying to understand where Atom is heading. This is a key issue (the proxy one), the fact that it's been like this for years is a bit worrying. It's a shame as Atom+Nuclide is such a lovely combo...

[contang0]

@jarecsni, no wonder, when you think about it. Microsoft bought Github. Both VS Code and Atom are targeting the same audience. They're even built using the same framework. Good night, Atom. It was fun while it lasted. I just hope Hydrogen will be ported to VS Code.

[lee-dohm]

Nat Friedman, GitHub's new CEO, has stated multiple times that we're going to continue to develop Atom. The main issue here is that we don't have a way to reproduce all of the possible proxy configurations that people use in order to replicate the problems people are running into. Until we have the time to tackle that (or someone from the community helps us out in that regard), these proxy issues are going to have a lower priority for us than other issues that we can make headway on.

[Frontrider]

Where can I get the logs from?

[jarecsni]

@lee-dohm thanks for confirming this, it's good to know.

On the actual point that it's difficult to reproduce the problems around proxy configuration, let me add a few points:

1. proxy is an absolute MVP feature, it's part of the 'launch application' scenario, I mean it should really be considered a vital feature

2. I'm sure the pareto principle works in this case too. First, please put something in place that fixes this for 80 pct of the users. Not doing anything saying there are difficult cases sounds questionable to be.

3. Not sure if this is realistic of feasible, but since the same thing works fine in VSCode, perhaps that bit could be shifted and lifted into Atom?

I'm really sorry for dwelling on this, but I think this is something really really important, massively impacting your userbase. Thanks!

[smashwilson]

Where can I get the logs from?

You can collect network-level logs from commands that use the atom.io API like apm search by setting the environment variable NODE_DEBUG=request. Careful if you share those logs here - I'm not sure if it's smart enough to elide things like proxy credentials automatically 😉

I'm sure the pareto principle works in this case too. First, please put something in place that fixes this for 80 pct of the users. Not doing anything saying there are difficult cases sounds questionable to be.

We do have some proxy support in apm. At one point I did have an http proxy spun up on a DigitalOcean box to test our proxy support... but there's such a broad range of enterprise setups (TLS MITM and so forth) that it's really easy for something to slip.

Maybe you can see something we're doing wrong? For reference, here's the code that's used for network connections to atom.io:

https://github.com/atom/apm/blob/7be49cfbf6ebbce1b02f62ae6366aceae298c869/src/request.coffee#L12-L20

[Frontrider]

npm works fine, maybe you could salvage the proxy from there.

[Chlorek]

I am yet another case where Atom fails while literally everything else manages to connect to the internet. Tried manually setting proxy - failed. From my understanding my workplace utilizes McAfee proxy. Atom is useless without working proxy.

[contang0]

How come Atom itself is able to update behind corporate proxy, but APM doesn't work? How did I find out? After months of using my Hydrogen that I copy pasted to packages folder from an USB stick everything suddenly broke because my version of Atom no longer worked with it. How is this possible?