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

7538ac5

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...

[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 caolan/forms#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: #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.aaakk.us.kg-jfhbrook-node-ecstatic-git-v0-4-12-85ae907a
npm ERR! Cloning into bare repository '/root/.npm/_git-remotes/git-github.aaakk.us.kg-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.