kevva / bin-wrapper Goto Github PK

It should be possible to print out instructions on how to manually install if everything else fails.

Consumer either supplies a note or better get an event.

For security-conscious applications, it'd be nice to be able to add a set of hashes for each src that the library checks to make sure the binaries match.

Not sure if this would make more sense as a 4th and 5th arg src(..., [hash], [hash-method]) or as an entirely new call tacked at the end with a map or array of hashes that correspond to each src.

The download package should be updated to the latest version (it's 8.0.0 now) which would remove the moderate Dependabot issue, caused by a downstream dependency 'got':

https://docs.github.com/en/code-security/dependabot/working-with-dependabot/troubleshooting-dependabot-errors

As reported by npm audit:

┌───────────────┬──────────────────────────────────────────────────────────────┐
│ High          │ Arbitrary File Write                                         │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ decompress                                                   │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in    │ No patch available                                           │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ gatsby-plugin-sharp                                          │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ bin-wrapper > download > decompress                          │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://npmjs.com/advisories/1217                            │
└───────────────┴──────────────────────────────────────────────────────────────┘

If I'm using a 32-bit version of Node on a 64-bit version of Windows, and only configure a win32 x64 binary using bin-wrapper, it throws the following error:

No binary found matching your system. It's probably not supported.

This is misleading, as there is a binary matching my system. The real error is something like "No binary found matching the architecture of your Node.js process", as it's not even checking the system architecture. The only time it should care about the architecture of the Node.js process is if you want to load something into that process itself (for example, a DLL file).

See facebook/flow#2288

I believe the bin-version-check package should be updated to the latest version of 5.0.0 which would remove the high CVE found here caused by a downstream dependency semver-regex

The readme only lists darwin and x64 as example values. What other values could be used?

https://travis-ci.org/k-kinzal/failed-bin-wrapper-/jobs/73195061#L101-L143
I found install error.

https://github.com/k-kinzal/failed-bin-wrapper-/blob/master/package.json#L6-L7
If you use the same dependent module in the parent and child , postinstall will start in before the installation is complete.
Install error is likely to occur and dependencies of the dependent module is large.

Bubbling up from sindresorhus/bin-version-check#3

As mentioned in #37 it's currently a black-box. Would be nice if it were more flexible.

bin-wrapper is a bit of a black-box if the use-case doesn't fit exactly how bin-wrapper works.

For example I had the need to decompress .tar.xz which requires a plugin to decompress and this is impossible because of all the leaky abstractions.

I had to hack around in the meantime...

It would be great that global binaries would be symlinked in vendor folder, so the result of building this module would be determistic. We are doing deterministic builds of our applications and this would help us a lot :)

This is also related to #18

This statement is in all views wrong:

if (isbin(this.bin)) {
    if (!which.sync(self.bin).indexOf('node_modules/.bin')) {
      return which.sync(self.bin);
    }
}

The return part never gets called(actually it does if node_packages/.bin starts at char 0, but i guess that's not a desired behaviour).

Even if i fix this and bin-wrapper finds path, my CPU goes to 100%, and i don't know what's wrong from there on.

node 0.10.12
npm 1.2.32
bin-wrapper 0.1.6

From imagemin/gifsicle-bin#3

This is still an issue

Downloading pngquant: 7%


  3 passing (166ms)

✓ pre-build test passed successfully, skipping build...
[email protected] node_modules/pngquant-bin
├── [email protected]
├── [email protected]
├── [email protected] ([email protected], [email protected])
├── [email protected] ([email protected])
├── [email protected] ([email protected], [email protected], [email protected])
├── [email protected] ([email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected])
└── [email protected] ([email protected], [email protected], [email protected], [email protected], [email protected], [email protected])

This piece of code can be used in most scenarios to test the binary. Would be nice if I could instead just call a method on bin-wrapper to do that, so to reduce useless boilerplate.

Currently we manually have to create useless proxies like these: https://github.com/kevva/elm-platform-bin/tree/master/bin

The reason is that we have to define the path to the binary in package.json up front.

Another way we could do it is to instead have bin-wrapper copy/move the binary to a fixed path/name we define in package.json.

@kevva What do you think?

.addUrl(['url', 'url']);

You should not depend on dynamic compiled binaries, because they don't tend to work across systems. For example if linker is on non-standard path like on nixos it will not work and that's not the only example.

There are few standard lib c libraries, musl and glibc.
BInary files builded on one linux system e.g. ubuntu doesn't compatible with another system, e.g. Alpine Linux.
I would like to have opportunity to choose binary file based on standard lib c library.
It will be very useful for Linux systems.

What do you think about this feature?

Looks like because it is not using proxy settings when using Download,
it hangs then npm install process in corporate/enterprise proxy environment.

> [email protected] postinstall .../node_modules/gifsicle
> node lib/install.js
{ hangs like forever }

Want to make use of Promises and somehow simplify stuff a lot. Also, #31, #37 and #38 needs to be fixed.

This is worng: https://github.com/kevva/bin-wrapper/blob/master/index.js#L213

You should allow symbolic links, there's no reason why not, and that's exactly the use case we have in nix package manager and in nixos.

_find() just needs a try / catch block around the which statement. PR and test incoming.

Please make sure that you handle this common case. I think this is the cause of 100% cpu usage with user provided binaries and failed tests.

afaik I didn't see a way to do everything but run without actually running the executable (I want to call path(), then call spawn aka run the app but with stdio piped etc etc), it'd be cool if there was a fetch method that guarantees that path will work (I used bin-wrapper to wrap the Google protoc compiler, https://github.com/anaisbetts/protoc-bin)

Bin-wrapper is used by many postinstall scripts but it doesn't allow to bypass strict SSL checking when using a corporate proxy to download the binaries. It should allow the scripts to set an option to do that.

As requested at imagemin/gifsicle-bin#47 I am opening an issue here.

Steps to reproduce:

• OSX 10.10.1
• node: v0.10.33
• npm: 2.1.11

cd ~/my-app
mkdir ~/node_modules
ln -s ~/node_modules ~/my-app
npm install gifsicle

Hangs installation forever with:

> [email protected] postinstall /Users/zanona/my-app/node_modules/gifsicle
> node lib/install.js

Add .exe on the bin property when process.platform === 'win32'.

Meaning an OS not defined in the bin-wrapper config:
https://github.com/sindresorhus/flow-bin/blob/47bfd263b08ae6d8f598ca37a2eb98680abba9cf/lib/index.js#L6-L7

Re flow/flow-bin#2

Users should be able to download an archive containing an executable file which should be moved to the correct destination along with other files defined in a files prop.

Commit 85a9d04 removed the global option (not totally though...) breaking at least mozjpeg-bin (see this pull request).

Maybe the module should not search for pre-installed binaries? I think this can cause some trouble if a different version or a different binary with the same name (mozjpeg) is already installed on the system.

imagemin/imagemin#43.

Hi,

it were nice if bin wrapper would just use the systems binaries if available. This especially makes sense for alpine Linux where static compiled binaries often do not work.

Greetings, Sascha

I have been trying to solve this issue:
imagemin/gifsicle-bin#11 (comment)

When trying to build on the build server I get the following warning:

[Step 1/1] (node) warning: possible EventEmitter memory leak detected. 11 listeners added. Use emitter.setMaxListeners() to increase limit.
[20:45:23][Step 1/1] Trace
[20:45:23][Step 1/1]     at IncomingMessage.EventEmitter.addListener (events.js:160:15)
[20:45:23][Step 1/1]     at Through2.<anonymous> (/root/BuildAgent/work/443e455e9b41081f/node_modules/grunt-contrib-imagemin/node_modules/jpegtran-bin/node_modules/bin-wrapper/bin-wrapper.js:124:13)
[20:45:23][Step 1/1]     at Through2.EventEmitter.emit (events.js:117:20)
[20:45:23][Step 1/1]     at Request.<anonymous> (/root/BuildAgent/work/443e455e9b41081f/node_modules/grunt-contrib-imagemin/node_modules/jpegtran-bin/node_modules/bin-wrapper/node_modules/download/download.js:37:20)
[20:45:23][Step 1/1]     at Request.EventEmitter.emit (events.js:117:20)
[20:45:23][Step 1/1]     at Request.onResponse (/root/BuildAgent/work/443e455e9b41081f/node_modules/grunt-contrib-imagemin/node_modules/jpegtran-bin/node_modules/bin-wrapper/node_modules/download/node_modules/request/index.js:830:10)
[20:45:23][Step 1/1]     at ClientRequest.g (events.js:175:14)
[20:45:23][Step 1/1]     at ClientRequest.EventEmitter.emit (events.js:95:17)
[20:45:23][Step 1/1]     at HTTPParser.parserOnIncomingClient [as onIncoming] (http.js:1688:21)
[20:45:23][Step 1/1]     at HTTPParser.parserOnHeadersComplete [as onHeadersComplete] (http.js:121:23)

I believe there is an issues with the event emitter that is why on imagemin/gifsicle-bin#11 (comment) we get looping downloads.

URLs should be overridden when defining platform and arch.

bin
    .addUrl('url')
    .addUrl('url2', 'linux')
    .addUrl('url3', 'linux', 'x64');

Some dependencies of the version 3.0.2 are vulnerable. It would be nice to update them.

Or at least (in package.json) :
"download": "^4.0.0" to "download": "^5.0.1" because 4.4.3 is vulnerable and 5.0.1 fixed it.

The better would be to update "download": "^4.0.0" to "download": "^6.2.5" (the latest version released).

I can open a PR in case you don't have the time.

EDIT : Seems to be fixed here.

This project is stale. No PRs merged since 2018, no commits since 2018. No communication on any issues by the repository-owner. I guess this project should be handed over to a new maintainer or at least should be marked "archived".

dest()

Accepts a path which the files will be downloaded to.

run()

Runs the search for the binary. If no binary is found it will download the file using the URL provided in .src().

Oddly, the path given to dest() appears to affect the success of run()? I was trying to figure out why bin-wrapper was not working in the imagemin-cwebp/cwebp-bin package, cwebp -version works just like they test for, which cwebp points to /usr/bin, but when running the package install.js which uses bin-wrapper it fails to run the command.

We use Jenkins to run our application's test suites. When running the build, the environment is not a TTY. According to theintern/intern#23 trying to render a progress bar in a non-TTY environment will throw an error.

Can we put a guard around the progress bar code to not render it if the environment is not a TTY (process.stdout.isTTY)?

I'll try to get you a PR soon.

Introduced in #65

The option mode was removed in download 5.0

Current version doesn't honor strict-ssl option, causing a lot of trouble for users behind a proxy. For example, imagemin/optipng-bin#74. The fix is in 5 branch here kevva/download@559a6f5, but this project uses version 4.

I was toying around with the idea we outlined for Elm-Platform (elm-lang/elm-platform#19) and realized that the archive would look a bit different from what the others here look like:

.
├── bin
│   ├── elm-doc
│   ├── elm-make
│   ├── elm-package
│   └── elm-repl
└── share
    └── reactor
        ├── _reactor
        │   ├── core.js
        │   ├── debugger
        │   │   ├── pause-button-down.png
        │   │   ├── pause-button-hover.png
        │   │   ├── pause-button-up.png
        │   │   ├── play-button-down.png
        │   │   ├── play-button-hover.png
        │   │   ├── play-button-up.png
        │   │   ├── restart-button-down.png
        │   │   ├── restart-button-hover.png
        │   │   └── restart-button-up.png
        │   ├── reactor.js
        │   ├── toString.js
        │   └── wrench.png
        └── favicon.ico

Firstly, there's more than one binary in there. You could certainly split them up into different modules or cache the archive somewhere so you don't have to re-download them for each individual module.

Secondly and probably more important, there are some shared resources in the archive that need to be placed somewhere. I don't think it's actually that uncommon. Is that something this module wants to tackle or is this out of scope?

Thoughts?

I tried to install node-pngquant-bin on Smartos but after I got error and I started read the code.
For smartos I wrote package for pngquant and installed it with dependencies (zlib, libpng). With bin-wrapper I need url for binary for pngquant but how it possible? If I'll make binary for both architectures then I can't give any guarantee because some libs (and version hell) maybe not exists on system. If I'll ship binary with static linking then some users will get segfault when trying to execute. Universal binary is not possible, it is a lie as universal string for making binary from source.
Maybe we can it resolve with making url option as not required if need binary exists in the path? I can do PR for this.
Thanks.

In the _parse function on line 189 only the x64 and x86 architectures are currently considered.

I was recently trying to install node-pngquant-bin on arm machine but it fails because of the lack of support for the architecture. I forked the node-pngquant-bin repository, compiled the binary for the arm platform and included it in the repository but the lack of support for the architecture in bin-wrapper means that the x86 is always downloaded.

Is it possible to use bin-wrapper with JAR files? If yes, it would be nice to add it to the docs.

Looks download have security issue in caw (tunnel-agent) (install latest npm@latest and run npm audit), also download use gulp-utils (which deprecated).

/cc @kevva @sindresorhus