v0.14.5 recently overwritten? and v0.14.6 does not work... about vue-demi HOT 11 CLOSED

Alright, so it was about the post-install script after all 😄

from vue-demi.

Here is further reference:

from vue-demi.

npx npm-diff vue-demi 0.14.4 0.14.5

npx npm-diff vue-demi 0.14.5 0.14.6

There do not seem to be many changes between those versions on npm (align with the commit history and nothing strange to me).

Just note that vue-demi works by swapping the files based on your Vue version, so I assume it's something changed in your environment rather than vue-demi itself.

I would need a minimal reproduction to prove it's vue-demi's issue.

from vue-demi.

@antfu Ya, i am a total loss with this. It is totally baffling. on my end I have only minor diff between .5 and .6 but my .5 from a few months ago has a massive diff.

I do not know what else to do, I can jump on a screenshare meeting and show you package diffs and explain how this came about or I can e-mail the sources to you?

Its created an impediment and we cant publish updates to our projects.

from vue-demi.

You'll need to control the variables and narrow them down to find the root cause. If there isn't a massive change in vue-demi's npm dist, then it must be something else causing that. I can't help as I don't have a reproduction on my end.

from vue-demi.

@antfu Hi

I uploaded the anomalies, The working source code snapshot I have from a few months ago is not visible in the project commit history as far as I can see, as if a rebase or history reset has happened... I have reached an impasse.

https://github.com/ESP-Marc/vue-demi-discrepency

from vue-demi.

A reproduction is a repository where the installation of vue-demi fails, not the vue-demi downloaded packages.

Note you can force the version of Vue as noted in the readme

from vue-demi.

@posva @antfu I couldn't get this done sooner as I had to prioritize making sure our dev's could continue to work first as this prevented them running our project and publishing updates and I figured someone might have just know what what's wrong right away with the initial information I had.

For the initial issue we had with [email protected] here is the failing reproduction repo:
https://github.com/ESP-Marc/demi-6-pinia

@posva As for that discrepancy repo, that come about because I had it to hand already and that was my first point of concern, naturally the first thing I tried was to force Pinia to use the last known working version of vue-demi which for us was 0.14.5 last week, only to find it didn't work anymore either giving exact same error.

On investigation of this rollback failure we find we have two different source codes for the same single version (0.14.5), Two timestamps a few months apart where the older one works and the newer one does not, that is what I shared as being the more serious issue here.

The source code I have provided does not appear to marry up with the vue-demi commit history so, I started looking through Pinas source code history for any point where Pinia might have pointed to a forked copy of vue-demi at the time we installed Pinia, I found nothing to suggest this... Thus I am totally puzzled by the two different source codes of 0.14.5...
I also checked to see if any other dependency was using vue-demi I found nothing but Pinia referencing it?

To get my team back into production I have taken the 3 month old copy of [email protected] that Pinia installed at that time we added Pinia to our project, and added that older copy directly into our project, forced Pina to use this working copy instead of the currently published 0.14.5 .

We are out of panic mode for now, I have never witnessed anything like this in 16 years, anyone that can shed light on this mystery would be great but for resolving 0.14.6 not working for us would be nice :)

Thanks gents

from vue-demi.

Can you make the repro minimal? it has too many things that are unrelated. Should probably only have vue, pinia and the CLI service

from vue-demi.

@posva Updated to bare bones

from vue-demi.

@posva @antfu
I started looking at this lib today to understand how it works and started with how the version switching @antfu mentioned works.

The issue is, for security reasons we have post script installs disabled in Yarn enableScripts: false.

I suspect then from what I can observe when I saw what I referred to as a lib history discrepancy; that the content from /lib/2.7 was copied to the root of the libs folder by the post install script at the time we installed Pinia when post script install was enabled.

Shortly after the point I installed Pinia to our project, It would have been the space of a day or two after that a security advisory suggested setting enableScripts to false for preventing npm from Executing Arbitrary Scripts, to wich point I did and no issues resulted from doing so for whole month.

Rational for disabling:

npm disclosed the discovery of a vulnerability that essentially allows npm packages to execute potentially malicious code on your machine. This vulnerability is potentially more harmful than running something like a bash script on your machine, because while a bash script will execute arbitrary code on your machine, npm executes arbitrary code on your machine from hundreds, if not thousands, of packages.

One example of this attack is an incident that occurred with the popular eslint-scope package. A new version of the package was published that contained malicious code via a postinstall lifecycle hook. The same applies for preinstall, preuninstall, and postuninstall hooks.

All of our development environments and build pipelines retained a cached copy this whole time for the past month until recently when days after the release of 0.14.6 our entire dev stack except for my own dev env consumed this while support for install scripts was disabled.

The above now makes it clear that the code discrepancy I thought I was seeing was because my project clone had not yet sucked in the 0.14.6 update this week so I still had the package installed with with code copied over a month ago from lib/2.7 by postinstall before enableScripts was set to false. Hence my confusion over the failed rollback for everyone else and our CI/CD pipelines.

We have quite an extensive dependency stack, after a "from-scratch" test with enableScripts: false on our entire dependency stack, we find vue-demi is the only sub-dependency out of everything we consume that has an issue with this.

Now that I know this is explicitly an postinstall script execution issue I started looking for information "we can't be the only ones with this issue", sure enough within minutes of this revelation I found in the Readme of this package a line on postinstall failure and the suggestion to run npx vue-demi-fix .

I could add this command to our build pipeline but that would open up the possibility if some day malicious postinstall code was published in this project, it would get executed and we can't allow that possibility to happen.

So I am going to stick with keeping a localised copy of vue-demi with the 2.7 lib source pre-copied for our project moving forward while we work towards our Vue 3 migration.

Best Regards

from vue-demi.