Harden supply chain security#18
Conversation
The dependency pin in package.json (^3.2.0 → 3.2.0) left the lockfile specifier out of sync, which broke `pnpm install --frozen-lockfile` in CI. The resolved version is unchanged (3.2.0); only the specifier field is updated. A full `pnpm install` would have been blocked by the 7d minimumReleaseAge cooldown against a recently-bumped transitive, so the lockfile is edited surgically. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request pins the ethereum-cryptography dependency to a specific version and increases the minimumReleaseAge for package updates to 7 days. Review feedback advises against pinning dependencies in a library to prevent version conflicts for consumers and suggests that a 7-day delay for updates may be too long, potentially delaying critical security patches.
| }, | ||
| "dependencies": { | ||
| "ethereum-cryptography": "^3.2.0" | ||
| "ethereum-cryptography": "3.2.0" |
There was a problem hiding this comment.
Pinning a dependency to an exact version in a library's package.json can lead to dependency conflicts for consumers. It prevents the package manager from deduplicating the dependency if other packages in the consumer's tree require a compatible but different version. For libraries, it is generally recommended to use semver ranges (e.g., ^3.2.0) and rely on the lockfile for reproducible development.
| "ethereum-cryptography": "3.2.0" | |
| "ethereum-cryptography": "^3.2.0" |
| # are at least 10080 minutes (7d) old. pnpm 11's default is 1440 (24h). | ||
| minimumReleaseAge: 10080 |
There was a problem hiding this comment.
Setting minimumReleaseAge to 7 days (10080 minutes) significantly delays the availability of all new dependency versions, including critical security patches. While this mitigates the risk of "poisoned" packages, it introduces a window of vulnerability where the project cannot easily update to a patched version of a dependency after a vulnerability is disclosed. A shorter window (e.g., 24 to 48 hours) is typically sufficient to catch most malicious releases while allowing for faster response to legitimate security updates.
# are at least 2880 minutes (48h) old. pnpm 11's default is 1440 (24h).
minimumReleaseAge: 2880
1 participant
Need help on this PR? Tag
@codesmithwith what you need.