releases available via npm

[piotr-gawron]

I just found out that currently only the latest version of ecstatic is available via npm:

$ npm view ecstatic versions  --json
[
  "4.1.2"
]

Could you make the older versions available as well? There are a lot of libraries that are using this module and removing older version can break the build.

[thornjad]

@jfhbrook even though older version are insecure, this is entirely breaking installing http-server. Could even just one 3.x version stay published for now? If npm allows specific versions to be deprecated, that would be a good way to signal the issue.

[Blackbaud-PaulCrowder]

Or perhaps backport the security fix to 3.x and 2.x so that the Internet is no longer broken. This is having ripple effects across a huge number of consumers right now.

[thornjad]

Is be6fc25 the security fix? It looks like it could be quickly and easily backported to a new 3.3.2

[jfhbrook]

I’m on the road but can probably look at this tomorrow morning. In the meantime that is in fact the fix if you want to try backporting to 3.x - I can publish.

[thornjad]

@jfhbrook that commit is titled Ho hum and is the only commit between 4.1.1 and 4.1.2. Does that seem right for the fix?

[jfhbrook]

Yes that’s the correct commit.

[thornjad]

#256 beat me to it, thanks @Blackbaud-ShaydeNofziger

[darekf77]

yarn install saved my day... @jfhbrook please don't delete your npm packages from npm...

[sdhull]

@darekf77 but yarn is just a mirror of npm... yarn install will fail in exactly the same way, and in fact, we were always using http-server with yarn and it started failing this morning

[nolman]

It's unclear to me why someone (not sure who) decided that old versions needed to be unpublished. Typical best practice is to leave these old vulnerable versions out and give people an advisory to update. There are people like myself who use this library in a context where the vulnerable did not impact us (only used in CI), however what did impact us was pulling the old versions from NPM and breaking all of our builds.

I appreciate this open source software, the people who make it and the time they spend in doing so. That said when people start to depend on your work it is impolite to remove it with no recommended upgrade path. Sure your time is limited, or you don't want to maintain this library anymore, that's okay I get it. However when you pull packages from NPM you are needlessly taking time from other people.

[sliceofbytes]

For those that need a build to go through today you can use the commit

7538ac5fda216c6ecf2a3386051feaf11f6deb2d

npm install --save "git://github.com/jfhbrook/node-ecstatic.git#7538ac5fda216c6ecf2a3386051feaf11f6deb2d"

[raymallick]

@sdhull yarn has a yarn cache on your system

[sdhull]

@raymallick oh so ... maybe I'm missing something but if you're in the situation where yarn is installing from local cache then you wouldn't end up on this thread anyway, right? I'm just confused as to the scenario in which yarn install is helpful. But hopefully it helps some folks!

[raymallick]

@raymallick oh so ... maybe I'm missing something but if you're in the situation where yarn is installing from local cache then you wouldn't end up on this thread anyway, right? I'm just confused as to the scenario in which yarn install is helpful. But hopefully it helps some folks!

For me personally, npm was failing but my yarn commands worked.

[sdhull]

@raymallick like locally or on ci or production or ...? For that to work, you would've had to have yarn installed ecstatic of the proper version previously on the given system. Right?

[raymallick]

@raymallick like locally or on ci or production or ...? For that to work, you would've had to have yarn installed ecstatic of the proper version previously on the given system. Right?

On CI systems, yarn or npm will fail. Locally, I had yarn installed recently, and therefore had proper version cached.

[3cp]

Better to bring back latest v3 right now, apply security patch to v3 later...

[mrstux]

broke our CI and dev pipelines which are dependant on http-server

for a solution, see: https://github.com/indexzero/http-server/issues/521#issuecomment-488843797

[rudraksh]

We are facing similar issues, more that 400 developers are blocked due to this. @jfhbrook , please could you bring back the version 3.0.0 on repos and in parallel work on fixing it's issues.

[nolman]

@rudraksh if your upstream dependency for ecstatic is http-server I posted a fix in https://github.com/indexzero/http-server/issues/521

Otherwise your best bet is @sliceofbytes fix

[snehasis]

Just now found the same issue in our CI pipeline. Can anyone suggest how I can use the 2.x.x version ?

[cookieguru]

@snehasis Scroll up for various solutions

[snehasis]

@cookieguru Well using another package manager like yarn is not a solution, I believe there must be a way to install 2.x version through NPM only. As all the production builds are blocked we can not change the process to use yarn now instead of npm.

[cookieguru]

@snehasis Various solutions with npm have been shared. Keep reading.

[snehasis]

@cookieguru I see this >> npm install --save "git://github.com/jfhbrook/node-ecstatic.git#f5a173d8968a7dd7b526be368cd8022cd9300840"

So for today we should go with particular version's commit id.

Is there any plan to revert back all the unpublished versions ?

[cookieguru]

@snehasis Keep reading

[snehasis]

@cookieguru Thanks for your reply.

By the way for 2.x.x I use the below command and this will work for me for now. npm install --save "git://github.com/jfhbrook/node-ecstatic.git#f5a173d8968a7dd7b526be368cd8022cd9300840"

[p1v2]

We are facing issues that we cannot install http-server package from node, as it requires a specific version of your package which is simply absent.

[garg10may]

For those that need a build to go through today you can use the commit

7538ac5

npm install --save "git://github.com/jfhbrook/node-ecstatic.git#7538ac5fda216c6ecf2a3386051feaf11f6deb2d"

this is 3.3.0 and it's not working for me

[NoExcuseForCode]

One of our module has dependency on 1.4.0 which is not available in npm, Can you reinstate the same. The whole CI is struck. or anyone can share a workaround for time being

[skjjain]

One of our module has dependency on 1.4.0 which is not available in npm, Can you reinstate the same. The whole CI is struck. or anyone can share a workaround for time being

Use npm install --save "git://github.com/jfhbrook/node-ecstatic.git#39f21cdf1998e6169f127874f97fd9dc9efcfacc"

[NemanyaM]

I have used npm install --save "git://github.com/jfhbrook/node-ecstatic.git#9aed3a74c126db56d299989f9ec068a9039f3b86" It worked for me!

P.S. It is a [email protected] version!

[Stewioie]

npm install --save "git://github.com/jfhbrook/node-ecstatic.git#39f21cdf1998e6169f127874f97fd9dc9efcfacc"

not working for me npm ERR! code 128 npm ERR! Command failed: git checkout 39f21cdf1998e6169f127874f97fd9dc9efcfacc npm ERR! fatal: cannot create directory at 'test/public/

': Invalid argument npm ERR! A complete log of this run can be found in:

[bitc]

Please re-publish to npm all versions that were un-published.

Standard practice is to flag versions with security bugs as insecure, but to leave them still available unchanged.

This is important for many many reasons. One example is for git-bisect, I need to be able to check out an old version of my code (that has a dependency on an arbitrary locked version of some library), and be able to install the versions of the libraries that I used back then, so I can have reliable tests. Un-publishing old versions basically prevents me from ever testing out old releases of my own code, among many other problems.

The tone of this comment is intended to be with the utmost respect towards the authors and maintainers of this project.

EDIT:

I am also curious how the un-publishing of older versions was even technically accomplished. It is impossible to un-publish old versions of a package using the npm tools and also impossible according to the npm policy:

https://docs.npmjs.com/unpublishing-packages-from-the-registry https://www.npmjs.com/policies/unpublish

The only way is to ask special permission from npm support, which is only granted for one of the following reasons:

• Published something accidentally.
• Wanted to test npm.
• Published content you didn’t intend to be public.
• Wanted to rename a package. (The only way to rename a package is to re-publish it under a new name)

Note that a security vulnerability is not listed as a valid reason. The proper way to deal with a security vulnerability is to deprecate the old vulnerable versions, as explained in the above links.

I thought that after the "left-pad" episode the npm community learned its lesson and locked things down such that we will never have a repeat episode where a package is removed causing a series of cascading breakage :| I am genuinely interested in knowing how the old versions were able to be deleted from npm, since this episode undermines my trust in the npm package registry and its "immutable" promise

[NoExcuseForCode]

One of our module has dependency on 1.4.0 which is not available in npm, Can you reinstate the same. The whole CI is struck. or anyone can share a workaround for time being

Use npm install --save "git://github.com/jfhbrook/node-ecstatic.git#39f21cdf1998e6169f127874f97fd9dc9efcfacc"

Still the error npm install --save "git://github.com/jfhbrook/node-ecstatic.git#39f21cdf1998e6169f127874f97fd9dc9efcfacc"

not working for me npm ERR! code 128 npm ERR! Command failed: git checkout 39f21cd npm ERR! fatal: cannot create directory at 'test/public/

[snehasis]

@NoExcuseForCode What is the exact error you are getting , you need to get the particular version commit id for the same.

[NoExcuseForCode]

@NoExcuseForCode What is the exact error you are getting , you need to get the particular version commit id for the same.

The error is No matching version found for ecstatic@^1.4.0

Can you please tell how to find the commit if for the same

[snehasis]

Can you please try this, I think it must be trying to installing the latest of 1.4.x npm install --save "git://github.com/jfhbrook/node-ecstatic.git#70751198635509a156ad1564296625fc753af89f"

[StphnDamon]

Hi,

This is really problematic!

I can't build my app because of a dependency of a dependency. So I can't move to your new version because you are not a direct dependency.

Can you please tag again as before?

Here is the error we have:

npm ERR! code ETARGET npm ERR! notarget No matching version found for ecstatic@~0.7.0 npm ERR! notarget In most cases you or one of your dependencies are requesting npm ERR! notarget a package version that doesn't exist. npm ERR! notarget npm ERR! notarget It was specified as a dependency of 'http-server' npm ERR! notarget

[virajjasani]

Error building open source Ambari Project:

[ERROR] npm ERR! Linux 2.6.32-696.23.1.el6.x86_64
[ERROR] npm ERR! argv "Workspace/ambari/ambari-admin/src/main/resources/ui/admin-web/node/node" "Workspace/ambari/ambari-admin/src/main/resources/ui/admin-web/node/node_modules/npm/bin/npm-cli.js" "install" "--unsafe-perm"
[ERROR] npm ERR! node v4.5.0
[ERROR] npm ERR! npm  v2.15.0
[ERROR] npm ERR! code ETARGET
[ERROR] 
[ERROR] npm ERR! notarget No compatible version found: ecstatic@'>=0.4.0 <0.5.0'
[ERROR] npm ERR! notarget Valid install targets:
[ERROR] npm ERR! notarget ["4.1.2"]
[ERROR] npm ERR! notarget 
[ERROR] npm ERR! notarget This is most likely not a problem with npm itself.
[ERROR] npm ERR! notarget In most cases you or one of your dependencies are requesting
[ERROR] npm ERR! notarget a package version that doesn't exist.
[ERROR] npm ERR! notarget 
[ERROR] npm ERR! notarget It was specified as a dependency of 'http-server'
[ERROR] npm ERR! notarget 

[mail4sheik]

Can you please try this, I think it must be trying to installing the latest of 1.4.x npm install --save "git://github.com/jfhbrook/node-ecstatic.git#70751198635509a156ad1564296625fc753af89f"

@snehasis, Works for me as a dependency for [email protected]. Thanks !

[ghost]

We are having the same problem with a failing CI do to missing of version 2.2.1

EDIT: We resolved the problem by removing the package from our project.

[rhiadj]

@jfhbrook Hi! First off let me start by saying thank you for creating this module and the hard work you've clearly put towards it over the years. In situations like this people often forget honest mistakes and attempts to resolve them don't always run smoothly.

I can see discussions on you being happy to port fixes to various previous versions.

Pulling v2.*.* from npm has broken our builds on a very large multi-million dollar enterprise solution used across the banking industry.

With that in mind - any chance we can get an update on this? And which versions you think might be patched? And if at all possible - when?

If you need help doing this we have a (large) team of devs on standby and are more than happy to help.

Many thanks in advance.

[carlosgit2016]

Install yarn to install packages that depend on ecstatic@^3.0.0 Run yarn install name-package

[virajjasani]

@jfhbrook Is there going to be any change of plan and old versions are going to be made available again or everyone is supposed to install ecstatic locally with githash only as per some of the above comments? Could you please let us know what would be the permanent(assuming local install with git-hash as temporary) solution?

[jfhbrook]

I just published 3.3.2 with the backported fix. This may help.

[jfhbrook]

$ npm view ecstatic versions --json
[
  "2.2.2",
  "3.3.2",
  "4.1.2"
]

If you're using v1, I'm sorry but you'll have to upgrade.

[dotpanic]

I confirm that our CI build is working back with new 3.3.2 version, thank you @jfhbrook!

[davityavryan]

So https://www.npmjs.com/advisories/830 can be updated?

[jfhbrook]

Good point, I'll email those guys and see what they say.

[Akmanar]

Hi @jfhbrook!

What about version [email protected]? Any chance it will be available again?

Our case is the same as @rhiadj 's. Our product integrations depends on this version and we have many CI servers affected by this.

Btw I would like to thank you and appreciate your time and efforts supporting the project.

@jfhbrook Hi! First off let me start by saying thank you for creating this module and the hard work you've clearly put towards it over the years. In situations like this people often forget honest mistakes and attempts to resolve them don't always run smoothly.

I can see discussions on you being happy to port fixes to various previous versions.

Pulling v2.*.* from npm has broken our builds on a very large multi-million dollar enterprise solution used across the banking industry.

With that in mind - any chance we can get an update on this? And which versions you think might be patched? And if at all possible - when?

If you need help doing this we have a (large) team of devs on standby and are more than happy to help.

Many thanks in advance.

[jfhbrook]

I don't plan on patching 2.1.x. Looking at the changelog it should be a fairly simple and painless upgrade path. Arguably, as an aside, a multi-million dollar banking app should probably be using nginx and not my humble module.

[Akmanar]

I don't plan on patching 2.1.x. Looking at the changelog it should be a fairly simple and painless upgrade path. Arguably, as an aside, a multi-million dollar banking app should probably be using nginx and not my humble module.

Thanks for the reply, I will pass the information to our dev teams so they are aware of it and can plan accordingly.

[rhiadj]

I don't plan on patching 2.1.x. Looking at the changelog it should be a fairly simple and painless upgrade path. Arguably, as an aside, a multi-million dollar banking app should probably be using nginx and not my humble module.

Thanks that's very helpful.

[igor-h]

everything works again!

[bretterer]

All works here, but this did cause a headache for me yesterday as it broke all of our builds using VuePress. What kind of guarantee can we get from you @jfhbrook that this will not be removed again?

[sigseg1v]

@rhiadj If you have a multi-million dollar banking application then you may want to consider a better security model than using unvetted dependencies that could be modified or removed by third parties at any time.

Additionally, you probably do not want to rely on a disaster recovery model that involves arguing with developers of free software (under a MIT license, provided with no liability or warranty) over a GitHub comment section.

I believe that there are options where you can host and cache your enterprises package dependencies in a manner that these kind of things will not affect your uptime or build, made specifically to avoid situations like this for critical software such as yours.

[rhiadj]

Thanks @griever989 - all good and understood. We have found a solution and we are moving forwards again. If you look at my first comment I wasn't arguing. MIT licence or not - given the impact this has had to so many projects and the fact we'd tried/offered to help - my reaction was mainly that of shock at the response. All the same - I wish everyone the best in resolving this in their own way - including @jfhbrook

[sigseg1v]

Good to hear! The fortunate part about this is that the developer was fixing a vulnerability in good faith, and it happened to have unintended side effects for users. If he had instead pushed hidden malicious code, there may have been many affected users and it could have gone unnoticed for a long time. For critical software, always control your dependencies!

[alberanid]

hi, it seems that also forms is broken (at least, I'm unable to build the latest version 1.3.0 on a Yocto environment). It seems to require ecstatic ~0.4.5 (via some other packages over which we have no control). Any chance to re-publish that version, also? forms is pretty popular...

Thanks!

[thornjad]

If you're using v1, I'm sorry but you'll have to upgrade.

@jfhbrook I really think it would be better to republish everything. I can't see any reason not to, it's not your responsibility to stop people from using insecure versions of the package (that's the "no liability" part of the license). While dependent projects may have been insecure before, now they simply don't work, without any warning.

[olayer66]

I have problems with several modules that as a dependency this library for example: No matching version found for ecstatic@~0.1.6 npm ERR! notarize In most cases you or one of your dependencies are requesting npm ERR! notarize a package version that does not exist. npm ERR! notarget npm ERR! notarize It was specified as a dependency of 'browserify-server' Please, how can I fix it?

[knperi]

@jfhbrook As @thornjad suggested can you republish everything. We are having issues while installing apiconnect which depends on 3.3.1 of ecstatic

[ljharb]

@alberanid if you mean https://npmjs.com/forms, please file an issue on that repo. (oops, nvm, i see https://github.com/caolan/forms/issues/208)

[ghost]

@jfhbrook I could mention that our ionic project cli failed, do to the use of a certain capacitor cli version. I can not tell for sure but I could imagen that a lot of people having problems with ionic right now. It seams to depend on version 2.2.1

[BruceRick]

I had a CI server that referenced a very old version (v0.4.12) through an older version of http-server. To fix it short term I just referenced the github releases here.

npm install jfhbrook/node-ecstatic#v0.4.12 && npm install

Obviously, long term the solution is to properly upgrade.

[jfhbrook]

Against my better judgement, npm unilaterally republished everything so we should be good

[ghost]

@jfhbrook Thanks for your efforts to resolve this problem, i will run some test on Monday to check if everything is fine.

[cookieguru]

2.2.2 and 3.3.2 are gone now on npm

[thornjad]

@jfhbrook why would they ever be unpublished in the first place?

[rhiadj]

Against my better judgement, npm unilaterally republished everything so we should be good

@jfhbrook fyi you might want to read this.

I know you meant well removing old versions - and as before I'll state again - thank you for all your efforts on this module.

@jfhbrook why would they ever be unpublished in the first place?

^ I 100% agree with @thornjad - deleting modules depended on by hundreds, and indirectly thousands, of other modules should always be a very last resort.

This brought down our entire CI/CD pipeline today, took me an entire day to resolve, and meant we missed several important (for us at least) deliverables.

Appreciate you disagree with npm's judgement here but please - in future - patch first, do communications, deprecate and then remove within a reasonable timeframe as per npm's own advise and policies:

Note: We strongly recommend deprecating packages or package versions instead of unpublishing them, because unpublishing removes a package from the registry entirely, meaning anyone who relied on it will no longer be able to use it, with no warning.

This has caused a lot of upset for a great many people and projects and will have had real world ramifications - both professionally and personally (all those extra hours desperately trying to fix a broken build).

Once again - thanks so much for this module. We will be taking your advise and removing it from our dependencies, which seems a shame given we have been able to use it unhindered (and it's worked so well) for a good 4 years.

Thank you and best of luck.

[newlink168]

by any chance please restore or fix @1.4.1... in directly referred and have no control to use the upgraded version...

[thornjad]

@newlink168, @BruceRick, @FelixQuehl and anyone else, I've just published a fork of ecstatic, renamed qtzl. It's a straight up fork which can be a drop-in replacement for older versions of ecstatic, no code changes necessary except the require. Simply:

npm r ecstatic && npm i qtzl

Then replace require('ecstatic') with require('qtzl').

To specify a version, use npm i [email protected]. If you need a specific version I haven't published, let me know and I'll get it up as quick as I can.

[jfhbrook]

A statement on my end that might be relevant to the interests of people following this issue: https://github.com/jfhbrook/node-ecstatic/issues/259

[sorrentinopasquale]

HI guys, my Jenkins is failing because of this: npm ERR! Command failed: git clone --template=/root/.npm/_git-remotes/_templates --mirror [email protected]:jfhbrook/node-ecstatic.git /root/.npm/_git-remotes/git-github-com-jfhbrook-node-ecstatic-git-v0-4-12-85ae907a npm ERR! Cloning into bare repository '/root/.npm/_git-remotes/git-github-com-jfhbrook-node-ecstatic-git-v0-4-12-85ae907a'... npm ERR! ssh: connect to host github.com port 22: Connection timed out npm ERR! fatal: Could not read from remote repository.

Can you kindly help?

[ljharb]

@sorrentinopasquale that's failing because you can't connect to github; it's got nothing to do with this repo, or this issue.