3 ms·
If 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
by PhilippGille 2y ago
If 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.