I shouldn't have used the word 'certified'— I just meant the package version should have an associated commit hash. There has to be a relationship between the

I shouldn't have used the word 'certified'— I just meant the package version should have an associated commit hash. There has to be a relationship between the hash and the published code in some way, unlike eg. the "homepage" field people use to link to Github which can just be an outright lie. My goal is for readers to match the hash to one on Github so they know the code they're reading there to vet the package is what's on npm. For OSS maintainers, it's an immediate red flag to see a package version published with a hash that was never in the public repo. This won't certify that the version is blessed by a legitimate author. It just delegates the problem to Github (or their competitors). It doesn't solve the problem of preventing all OSS library-based attacks, but plugs one of the leaks in trust that caused today's failure: that Github->NPM is not checked in any way.