Node-sass: Cannot download …binding.node from GitHub

[flogehring]

I work in an environment where I am required to go through a proxy, which also has a local self signing SSL certificate. In order to circumvent that complication for all the various package managers, we use Artifactory as a proxy registry for npm, bower etc. Also, we're required to run Windows 7.

So far all npm installs were successful, but I have an issue when trying to install nodesass.

From what I can tell, it is trying to download something separate from github, that doesn't go through npm and fails doing so, because of the local proxy.

I'm not sure if this is issue-worthy or just a too complicated environment. I'm trying to make it as easy as possible for my coworkers to work with these tools. Setting up everybody's proxy settings with their npm installs is not really an (easy) option.

I'm thankful for any pointers as to how to approach the problem.

[xzyfer]

Hi @flogehring.

From what I can tell, it is trying to download something separate from github

This is correct.

doesn't go through npm and fails doing so, because of the local proxy

This request should be using your npm proxy settings assuming you can configured them with npm. config. If this isn't working, it's a bug.

Setting up everybody's proxy settings with their npm installs is not really an (easy) option.

The alternative approach we developed for your exact situation is for you to mirror the release binaries internally and tell node sass where to download them from.

This can be done by with either setting the SASS_BINARY_SITE environment variable,

SASS_BINARY_SITE='https://github.com/sass/node-sass/releases/download'

or setting the following in your package.json.

nodeSassConfig {
  binarySite: 'https://github.com/sass/node-sass/releases/download'
}

Hope this helps.

[xzyfer]

The specifics of the download url generation can be found in https://github.com/sass/node-sass/releases/download

[flogehring]

or setting the following in your package.json.

Which package.json are you referring to? I tried setting it in the package.json of the project I'm testing the integration with.

 "nodeSassConfig": {
    "binarySite": "D:/dev/nodeTest/node-sass-bin-mirror/"
},

I downloaded the file that was mentioned in the log to that folder. The error message ("Cannot download...") stays exactly the same.

The link regarding download url generation gives me 404.

[xzyfer]

Should be the top most package.json. Could be a bug. For now try

SASS_BINARY_SITE='your path' npm install

On 25 Aug 2015 18:16, "Flo Gehring" [email protected] wrote:

or setting the following in your package.json.

Which package.json are you referring to? I tried setting it in the
package.json of the project I'm testing the integration with.

"nodeSassConfig": {
"binarySite": "D:/dev/nodeTest/node-sass-bin-mirror/"
},

I downloaded the file that was mentioned in the log to that folder. The
error message ("Cannot download...") stays exactly the same.

The link regarding download url generation gives me 404.

—
Reply to this email directly or view it on GitHub
https://github.com/sass/node-sass/issues/1104#issuecomment-134518466.

[flogehring]

Thanks, that seems to be doing something.

I did

 set SASS_BINARY_SITE=D:/dev/nodeTest/node-sass-bin-mirror
 npm install node-sass

But I get

 Cannot download "D:/dev/nodeTest/node-sass-bin-mirror/v3.2.0/win32-ia32-14_binding.node": 
 Invalid URI "d:/dev/nodeTest/node-sass-bin-mirror/v3.2.0/win32-ia32-14_binding.node"

The file is at

 D:\dev\nodeTest\node-sass-bin-mirror\v3.2.0\win32-ia32-14_binding.node

No success with switching slashes to backslashes, appending one at the end etc.

[mgreter]

I guess node-sass doesn't recognize the on file-system path and tries to download it anyway, see the "Invalid URI" part of the error you get! Maybe it works if you add the proper protocol to make it valid:

set SASS_BINARY_SITE=file:///D:/dev/nodeTest/node-sass-bin-mirror

[xzyfer]

@mgreter is correct. The expectation from our end was that files would be hosted on a remote webserver. Filesystem downloads are not supported but it might be worth adding support for.

[xzyfer]

Tracking feature proposal for local file support in https://github.com/sass/node-sass/issues/1106

[flogehring]

Yes, file:///… didn't do anything either. Starting up a local apache and linking there in the SASS_BINARY_SITE env variable worked.

@xzyfer what were you trying to say with

The specifics of the download url generation can be found in https://github.com/sass/node-sass/releases/download

The link gives me a 404. I only downloaded one file for now but if there's an easier way than downloading them all separately I'm interested :)

[xzyfer]

Sorry, copy paste error.

Here is the proxy logic - https://github.com/sass/node-sass/blob/master/scripts/install.js#L67-L87

Here is the url generation - https://github.com/sass/node-sass/blob/master/lib/extensions.js#L104-L111

[flogehring]

Thanks again for your help.

[seldon007]

I experience the same with Nexus. Was this ever fixed, it doesn't make that nodesass behaves differently. Was this ever fixed since I'm still seeing it

[xzyfer]

@seldon007 there was recent regression, see #1787

[skovalyov]

I use gulp-sass, which in its turn install the latest version of node-sass. And recently node-sass is being released quite frequently (sometimes several times a day) forcing me to replicate binary bindings for every new release. Is there anyone, who automated that replication process? How do you do that?

[seldon007]

@xzyfer Yeah, using v3.11.2 fixed our problems, thanks

[milewski]

just a quickly note if someone come here from google... and is using SASS_BINARY_SITE in a .npmrc file.. it should be lowercase exacly like sass_binary_site=https://npm.taobao.org/mirrors/node-sass/ strangely it worked as uppercase before..

[fazouane-marouane]

@skovalyov I don't know if you're still looking for an automated process for replicating the binaries, but I needed this kind of tool lately. So I developed a cli tool that does just that!

I used it inside my organisation to download node-sass & electron, to name a few. It worked without any problem. :sparkles:

[xzyfer]

I recommend extreme caution using anything non-official when dealing with release binaries. They're a high value target for exploitation.

[fazouane-marouane]

It's just a small opensource node package. Plain javascript. I linked the github repo in my first message. While I agree with the fact that one should be cautious with the tools one is using, I don't see how this is appropriate here.

[xzyfer]

https://github.com/ChALkeR/notes/blob/master/Gathering-weak-npm-credentials.md

Is a perfect example of why I think it's appropriate.

[fazouane-marouane]

I see in the link you shared that you've been a direct target to the attack. So maybe I shouldn't take offense in your comment, It's probably standard procedure by now anytime someone links a github repo/npm package.

[xzyfer]

No offence was intended. It was intended a statement that we cannot support the usage of anything non-official that interacts with our binaries.

By their nature malicious binaries are much harder to detect than malicious JavaScript. This is a constant concern of ours.

[fazouane-marouane]

I didn't run a poll or anything but my guess is many big companies (like my employer) use proxies that are incompatible with npm. They use a private cdn for binaries like node-sass's but the process of replicating those binaries is too difficult. So from your comments I guess that the issue is the tool being non-official. But it's of high value for my company, it's probably high value for other companies with the same setup.

So, would you be confortable with taking full ownership of the git repo/npm package?

[xzyfer]

I completely understand the use case, and that it's a pain to do manually.

To be clear, we have no interest in maintaining such a tool, or believe the posted tool to be malicious at this time. We're just advising people to exercise caution and best judgement when using 3rd party tools.

Our end goal is to eradicate the need for binaries all together in the near to medium term. Our official advice is to directly download the appropriate binaries manually and store them within your firewall, and using the install config to point at the new location.

[clouless]

Here is a howto for a simple nginx proxy that also deals with the AWS S3 redirect internally.
Even though in german, the codesnippets should be self explanatory:

https://comsysto.com/blog-post/jenkins-builds-mit-node-sass-beschleunigen