3 ms·
There's indeed a serious problem if cache invalidation relies solely on the declared semver of the package. Maybe something govulncheck could manage by comparin
by mohamedattahri 2y ago
There's indeed a serious problem if cache invalidation relies solely on the declared semver of the package. Maybe something govulncheck could manage by comparing a package's hash on pkg.go.dev VS the remote vcs.
- PhilippGille 2y agoIf you just invalidate the cache on hash mismatch, the malware problem exists the other way around: You update a dependency to version x and check its code to ensure it's safe. Then the threat actor adds malware to that library you're depending on, and makes the old tag x point to the malicious commit. Yor coworker does "go get" to download dependencies and gets the malware. One solution (on dev side) is to vendor, which Go has native support for. Another (on Go side) is to show a warning on hash mismatch.
- jdndjcjjd 2y agoIs this really possible? I thought the package lock job was to prevent that
- mohamedattahri 2y agoThat's why I suggested govulncheck; it can keep a database of suspicious packages and issue a clear warning, and it can be locally check that the hash of tagged version you're using locally is the same on GitHub.
- silverwind 2y agoYeah, it's fundamentally flawed because git tags can be force-pushed over and this has happened on many open source projects in the past, leading to different mirrors hosting different content for the same version.