everlastingbugstopper / binary-install Goto Github PK

GitHub is giving warnings about GHSA-4w2v-q235-vp99 when using this library. Is it possible to upgrade the version of Axios used and cut a new release?

I would like to vote to add some feature like check cache, if it does not hit then axios will download it.
Sometimes my network is not stable, the installation process would not download the file successfully. If I know where the cache it stores, then I can put the file there.

we should likely be installing this in node_modules/.bin instead of node_modules/binary-install/bin. it doesn't super matter, just a little unexpected. I can't seem to figure out an elegant solution for this, help very welcome.

relevant code is here: https://github.com/EverlastingBugstopper/binary-install/blob/main/packages/binary-install/index.js#L45

I have binary-install successfully downloading my binary.

When I try to run it, though, I just get this error:

Error: spawnSync /Users/brianheise/test/node_modules/binary-install/node_modules/.bin/ce-cli ENOENT

I navigate to the folder and indeed it is empty. Elsewhere in the node modules folder, I was able to find a binary with my apps name. However, when I run it I get the exact same error. My guess is that binary-install creates this binary file that directs to another folder where my binary actually should be, except it's not there. Any ideas what could be causing that and how I can fix it?

binary-install do not wait for install when run is executed

so if for some reason npm install did not download and you execute the command it will download again but run will not wait for the download to finish and fails

The usage of envPaths().config as the default installation path is problematic for two reasons:

1. Storing the binaries outside of the project directory causes surprising behaviour in CI environments because one has to remember to cache those directories as well. Otherwise, the next CI run will fail to find the binary if only node_modules is being cached. It would be more resilient to put the binaries into node_modules/.cache or some other sub-directory within node_modules.

2. It violates the XDG directory specification. $XDG_CONFIG_HOME is meant for configuration files. Binaries are clearly not configuration files. If at all, we should be putting those binaries into $XDG_CACHE_HOME.

(2) is actually no longer an issue if we simply store the binaries within node_modules.

The download progress is wrong and message gets printed too early.

You can see that file size of the wrangler binary is increasing, which means the download does not finish. But it already said wrangler has been installed! and it stuck in the state of waiting for the download complete.

When downloading a binary from a private repo you have to use the Github API URL of the form https://api.github.com/repos/{owner}/{repo}/releases/assets/{asset_id} which requires an Authorization header and an additional header of the form Accept: 'application/octet-stream' to download the asset. While the authorization token can be added to the URL with a https://{token}@api.github.com/repos/{owner}/{repo}/releases/assets/{asset_id}, the Accept header still needs to be passed

There isn't currently a way to affect the axios call within the install function. Could there be a fetchOptions parameter added to either the install function or the constructor that would allow a user to pass additional options to send to axios?

I'd be happy to submit a PR for the change

Should this be package.name or platformMetadata.BINARY_NAME?

Also should the supportedPlatforms array also contain BINARY_NAME? by removing this and using it in the package.json with something like binDependencies allows it to be decoupled and allows for multiple binary installations.

I'm currently making some tweaks to get this to work to install a collection of binaries, hopefully will submit PR.

See rustwasm/wasm-pack#1038 (comment) for more information.

Problem

Running an installed package with binary-install on Ubuntu results in the following errors:

After sudo npm install -g fleetctl, do the following.

(without sudo)

$ fleetctl
fs.js:114
    throw err;
    ^

Error: ENOENT: no such file or directory, mkdir '/usr/local/lib/node_modules/fleetctl/node_modules/binary-install/bin'
    at mkdirSync (fs.js:757:3)
    at new Binary (/usr/local/lib/node_modules/fleetctl/node_modules/binary-install/index.js:48:7)
    at getBinary (/usr/local/lib/node_modules/fleetctl/binary.js:58:10)
    at run (/usr/local/lib/node_modules/fleetctl/binary.js:62:18)
    at Object.<anonymous> (/usr/local/lib/node_modules/fleetctl/run.js:5:1)
    at Module._compile (internal/modules/cjs/loader.js:778:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
    at Module.load (internal/modules/cjs/loader.js:653:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
    at Function.Module._load (internal/modules/cjs/loader.js:585:3)

(with sudo)

$ sudo fleetctl
You must install fleetctl before you can run it

Details

When npm is installed with apt on Ubuntu, npm install -g must be run with sudo (due to permissions). Internet research seems to indicate that postinstall scripts are skipped when npm is run as a root user. This leaves the binary un-downloaded after installation when using the example configuration in this repo.

While it seems possible to download the package in the run step, I believe the current binary-install API would require the install step to take place on each run.

Do you see a good workaround for this? Is there a good way we could make a checkInstall sort of step that would check if the proper version is installed and do so if it's not?

 uninstall() {
    if (existsSync(this._getInstallDirectory())) {
      rimraf.sync(this.installDirectory);
      console.log(
        `${this.name ? this.name : "Your package"} has been uninstalled`
      );
    }
  }

This code was removed in a refactor and never reintroduced.
Was this intentional?

We have a security scanner that flagged this package because it's pulling in an axios version with a high risk vulnerability

https://nvd.nist.gov/vuln/detail/CVE-2021-3749

Just thought I'd pass it on here for info.

Is there a particular license you want to apply to this project so contributors and users know what the usage terms are?

axios 0.8.1 - 1.5.1
Severity: moderate
Axios Cross-Site Request Forgery Vulnerability - GHSA-wf5p-g6vw-rhxx
No fix available
node_modules/binary-install/node_modules/axios
binary-install *
Depends on vulnerable versions of axios
node_modules/binary-install

Moving an issue from apollographql/rover#1563 to here.

Currently the install command checks to see if the binary exists, and if it does, immediately resolves the promise without taking any actions.

This is fine for first time installs, but will cause unintended behaviors if users of the wrapper npm module are updating their dependencies. The npm i of the wrapping module will succeed, and users will be unaware that the functionality behind the module remained on an old version.

Suggestion here would be to add an option to the install function enabling it to overwrite the existing file. Calling modules could then have their own logic to determine when to use the overwrite option for install.

I am willing to contribute this feature.

Typically Windows binaries are published with a .exe extension. This package looks for something exactly matching the name parameter provided, which makes for an unexpected You must install foo before you can run it if the downloaded archive actually contains foo.exe.

I was able to work around this by explicitly changing the name for the Windows platform, but it could be nice to automatically handle the .exe extension.

I apologize if this is actually documented somewhere outside of the code. I couldn't find it.

Currently, if your tarball looks like

file
dir/file

since strip is set to 1, you lose file, and most annoyingly if your whole tarball is just single file name components, you lose everything in the extraction - I just wrestled with this case myself before I learned all this about tar and the strip option.

I propose documenting this stripping as core assumption of binary-install, so people know how to pack their balls.