-
|
Hey 👋 This is a follow-up to these articles:
Current behaviorIn short words, it's possible to manually update lockfile, so it will install a different package than listed in package.json. It works both for yarn v1 and yarn v2, but I will add example only for yarn 2. package.json {
"name": "yarn2",
"packageManager": "[email protected]",
"dependencies": {
"is-number": "^7.0.0"
}
}yarn.lock # This file is generated by running "yarn install" inside your project.
# Manual changes might be lost - proceed with caution!
__metadata:
version: 5
cacheKey: 8
"is-number@npm:^7.0.0":
version: 7.0.0
resolution: "is-number@https://kozlovzxc.ru/static/is-number-7.0.0.tgz"
checksum: 9383a7b41b63cc84e14ef6b157d71fccf12a57bb87231004b3dd99086e4531fba371461279cad9cfeef97e617eecc166e71ba0b6103b97cfcba59d04a44ad618
languageName: node
linkType: hard
"yarn2@workspace:.":
version: 0.0.0-use.local
resolution: "yarn2@workspace:."
dependencies:
is-number: ^7.0.0
languageName: unknown
linkType: softindex.js const isNumber = require("is-number");
console.log(isNumber(1));console output The issue is that for open source packages, PR updating lockfile may look like this:
So probably no one will ever look into this. Expected behaviorNot sure about this one, so I'm opening this as a discussion, probably the best case would be to check lockfile integrity on each install, but I guess it may require extra resources' consumption. So maybe it will be nice to have some build in command to verify lockfile integrity and configuration options to white-list allowed domains/packages. Related pnpm issue pnpm/pnpm#4361 cc @ai |
Beta Was this translation helpful? Give feedback.
Replies: 6 comments 12 replies
-
|
That's an issue with how GitHub displays lockfiles. They actually have a better interface, but it's hidden by default: https://twitter.com/arcanis/status/1179481387818201089 And given that this component isn't open-source, we can't improve it on our side. |
Beta Was this translation helpful? Give feedback.
-
|
Also note that in Yarn's case GitHub reports "Large diffs are not rendered by default", because smaller changes are shown if possible. That's because we explicitly asked for them to be reviewable: |
Beta Was this translation helpful? Give feedback.
-
|
Oh, I have never seen this interface before! Thanks! But need to check it further, e.g. does it show whole dependency three? What if we have two different versions of one package which are downloaded from different places (it's possible, right?). In any way, it is still up to user to verify up to hundreds of dependencies, why do we need to rely on manual work when we can automate it and make e.g. there is lockfile-lint package, but I guess only a few users actually know about it. |
Beta Was this translation helpful? Give feedback.
-
You need to be more explicit and list exact ways you think it'd be better, otherwise it's difficult to answer. But because there are reasons why things work the way they are, I think you also need to think strongly about why those ideas wouldn't work. For example:
What does it mean to check integrity? Against what would you check this integrity? How can Yarn know that the lockfile it is given has been tampered? What if users legitimately want to reference packages from their own networks? What if a malicious package is hosted on the same domain has legitimate ones (ie the npm registry)? |
Beta Was this translation helpful? Give feedback.
-
|
Thinking about this, perhaps a way we could improve this would be by integrating w/ GitHub Actions (and a few other vendors). If Yarn detects that the current environment is a PR (ie unsafe environment), it could check the diff in domain names between the base branch lockfile and the new one, and abort if it sees a mismatch. However this 1/ would require a way for administrators to bypass this, and 2/ wouldn't help against malicious packages on the same registry. Regardless how clever we are, lockfiles will have to be reviewed by someone. |
Beta Was this translation helpful? Give feedback.
-
Can't we also check the name of the package? e.g. if it is |
Beta Was this translation helpful? Give feedback.
-
|
It's not only a matter of the package.json but also its transitive dependencies. Yarn stores these dependencies inside the lockfile, so a malicious actor would simply add a fake subdependency and Yarn wouldn't be any wiser. |
Beta Was this translation helpful? Give feedback.
-
|
I'm a bit constrained with expressing ways how it should work just because I'm not super familiar with how any why
My initial thoughts were that if lock file is generated out of
This case is a bit tricky, since it's a bit hard to come up with an actual case to modify lockfile instead of |
Beta Was this translation helpful? Give feedback.
-
|
Oh, sorry, my bad, it's my first post in Discussions 🙏 Will keep it in one thread moving on! Btw looks like folks from pnpm want to add an extra command for this, so if it will be useful for you, here is the pnpm thread pnpm/pnpm#4361 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
Generally I'd prefer any protection we have to be there by default, otherwise people will forget about it (same reason why |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, totally agree, if it's a new command it won't be much different from having external package like lockfile lint, people will still to get to know it |
Beta Was this translation helpful? Give feedback.
-
|
Btw here is another possible alternative, npm has https://docs.npmjs.com/cli/v8/commands/npm-ci |
Beta Was this translation helpful? Give feedback.
-
|
It's still another command, but it feels like it's easier to get to know it compared to |
Beta Was this translation helpful? Give feedback.
-
This is actually supported already using networkSettings, the following configuration will block requests to all origins except networkSettings:
"registry.yarnpkg.com":
enableNetwork: true
"*":
enableNetwork: false |
Beta Was this translation helpful? Give feedback.
-
|
Wow, can it be default? It won't help with changed name, though (e.g. |
Beta Was this translation helpful? Give feedback.
-
|
Yarn 4.0 (rc) now automatically protects against lockfile attacks through a new
Put together, those rules will entirely prevent malicious actors from adding dependencies deep into the lockfile, hidden from review. The only downside is that they make installs from PRs slightly slower, since we need to re-fetch the package metadata. |
Beta Was this translation helpful? Give feedback.
Yarn 4.0 (rc) now automatically protects against lockfile attacks through a new
enableHardenedModesetting which is automatically enabled for "untrusted" environments (such as GitHub PRs on public repositories). When enabled:Put together, those rules will entirely prevent malicious actors from adding dependencies deep into the lockfile, hidden from review. The only downside is that they make installs from PRs slightly slower, since we need to re-fetch the package metadata.