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 (check Upgrade yarn version #1211 (comment))

[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!

[technophile-04]

Was having a meeting with Carlos earlier and he flagged a concern, since we have scaffold-ui and our other maintained packages on npmPreapprovedPackages, what happens if we ship a new scaffold-ui version and it ends up pulling a freshly compromised transitive. Does the allowlist just wave the whole subtree through the gate?

Digging a bit, npmPreapprovedPackages is a strict name match. It only lets the named package through the gate, it doesn't cascade to that package's dependencies. Every transitive gets evaluated on its own. So if we ship scaffold-ui with a hypothetical bad axios@1.14.1 published less than 7 days ago, scaffold-ui itself bypasses because we allowlisted it, but axios still hits the 7d gate and gets blocked. Yarn then falls back to the latest version that satisfies the semver range and is at least 7 days old

Also tried running a small verification of both behaviors locally with yarn 4.10.3:

Setup: fresh project on yarn 4.10.3 with npmMinimalAgeGate: 525600 (365 days), axios@^1.0.0 as the only direct dep, and toggled npmPreapprovedPackages: [axios] vs [] between the two runs to isolate the cascade vs fallback behavior.

1. npmPreapprovedPackages does not cascade. Allowlisted axios + 365d gate → follow-redirects@^1.15.11: No candidates found. The transitive hit the gate even though its parent was allowlisted.

2. Yarn falls back to the latest semver-compatible version old enough to pass. No allowlist + 365d gate + axios@^1.0.0 → resolved to 1.8.4 instead of latest 1.15.0.

sidquest:

I went to check how scaffold-ui is actually built, because I kept wondering if maybe the deps are bundled into the dist and the consumer never resolves them. Turns out no. All three packages (hooks, components, debug-contracts) just run tsc and emit ESM to dist/esm/. No webpack, no rollup. The published dist keeps every import statement intact, and the published package.json ships a real dependencies field. So when someone runs yarn install, yarn reads scaffold-ui's package.json and resolves the deps fresh, which means every one of them goes through the 7d gate at the consumer's install time

So this is safe to merge 🙌 and yup the behvaour doesn't change for create-eth since while doing yarn install only while creating the yarn.lock it follows all this rules

[rin-st]

Does the allowlist just wave the whole subtree through the gate?
...

Thank you for detailed comment!

Looking good! Added one question

[carletex]

Thanks for the research, Shiv! <3

[technophile-04]

Merging this 🙌