Upgrade yarn version

[technophile-04]

Description

Ran:

yarn set version berry
yarn install

The #1184 seems way too old. Also, I'm not sure what commands they used to migrate because there are some files that need to be added which were not present.

TODO:

Research about npmMinimalAgeGate and see whats the best and standard people are using and add it

[rin-st]

Research about npmMinimalAgeGate and see whats the best and standard people are using and add it

Since we're not in a hurry most of the time, I think it's ok to use "7d", it should be enough to prevent most of the supply chain attacks. And use npmPreapprovedPackages for burner-connector and similar cases

[carletex]

Since we're not in a hurry most of the time, I think it's ok to use "7d", it should be enough to prevent most of the supply chain attacks.

We also have to think about the opposite side of this. When you want to update to a safer version currently released (nextjs / react recently). I guess you just need to add temporarily to npmPreapprovedPackages, right?

Also, for our npmPreapprovedPackages packages (burner, sui?) we'd need to implement something similar to this? If not, we are still vulnerable (way less, but still)

[rin-st]

We also have to think about the opposite side of this. When you want to update to a safer version currently released (nextjs / react recently). I guess you just need to add temporarily to npmPreapprovedPackages, right?

I think yes, I don't see other solutions

Also, for our npmPreapprovedPackages packages (burner, sui?) we'd need to implement something similar to this? If not, we are still vulnerable (way less, but still)

Yes, wanted to say it too but forgot

[technophile-04]

Hey guys thanks for the discussion! So been researching as well, and I think:

1. 7d is good enough!

• Like yup we don't update things that often, and we can wait / also need time to implement to update to new version code.
• lol this is future future but, in create-eth we can have a CI which doesn't have "npmMinimalGate" field. So we scaffold a new version of scaffold-eth with latest packages and this will help us catch bugs earlier (like if you remmber we had issue with react-copy-to-clipboard types, cause it was internally not pinned) so in that CI it will be caught and we will have like 7days to fix it. (since in og repo the gate will unlock after 7days)

We also have to think about the opposite side of this. When you want to update to a safer version currently released (nextjs / react recently). I guess you just need to add temporarily to npmPreapprovedPackages, right?

I think yes, I don't see other solutions

yeah I dont see a better solution either, but for now I have added (our maintainer packages + react, next patch versions) since those are main ones. We can can also think of allowing (hardhat patch version) their. And for some excpetional cases we follow the flow of adding packages on-demand and then removing them.

Also, for our npmPreapprovedPackages packages (burner, sui?) we'd need to implement something similar to this? If not, we are still vulnerable (way less, but still)

Ohh yes! We shall add them 🙌

[rin-st]

I think we need to remove react/next from preapproved packages.
As I remember npmMinimalAgeGate option was added after this, when patch versions of popular packages was compromised. Hopefully it will not be the case for react/next but we're not 100% sure.

For last react/next CVE's it works (when patch versions added the fixes), but probably it's better to update them that way just in case?

We also have to think about the opposite side of this. When you want to update to a safer version currently released (nextjs / react recently). I guess you just need to add temporarily to npmPreapprovedPackages, right?

[technophile-04]

I think we need to remove react/next from preapproved packages.
As I remember npmMinimalAgeGate option was added after this, when patch versions of popular packages was compromised. Hopefully it will not be the case for react/next but we're not 100% sure.

Ohh man :( I seee yup and agree, the more I think and read it just makes sense to only have our packages (which are controled by us) to have in npmPreapprovedPackages rest we can remove and add depending on the need

[Kushmanmb]

yarn install

[technophile-04]

This is ready to be merged I feel 🙌

[rin-st]

Lgtm, thanks!