I understand that line of thinking, but what land are they grabbing? They already possess all of it through npm and GitHub.
Do you think they intend to exclude caches like yarnpkg.com as insecure? I don't see how they would do that, since (1) your cache is a local config variable, not part of package.json, so there's no static analysis that could mark packages downloaded through Yarn as insecure, and (2) all of the key signature metadata is publicly available, so any cache or alternative package manager can implement the same provenance features as npm.
Or are you worried about EEE of the upstream source repositories and CI runners, eg "only packages built through GHA platform can contribute provenance data to npm registry?" I guess I could see that as a more reasonable fear, but as someone else explained to you, it's also unfounded (at least for now - which is maybe your argument), and GitLab is currently working on their own implementation. But even if they tried that, then you could still publish and consume packages from another registry if you wanted to. And I'd like to think that if Microsoft made a hostile move like that, we could count on package managers like yarn to pull provenance data from other sources.
Comments
I understand that line of thinking, but what land are they grabbing? They already possess all of it through npm and GitHub.
Do you think they intend to exclude caches like yarnpkg.com as insecure? I don't see how they would do that, since (1) your cache is a local config variable, not part of package.json, so there's no static analysis that could mark packages downloaded through Yarn as insecure, and (2) all of the key signature metadata is publicly available, so any cache or alternative package manager can implement the same provenance features as npm.
Or are you worried about EEE of the upstream source repositories and CI runners, eg "only packages built through GHA platform can contribute provenance data to npm registry?" I guess I could see that as a more reasonable fear, but as someone else explained to you, it's also unfounded (at least for now - which is maybe your argument), and GitLab is currently working on their own implementation. But even if they tried that, then you could still publish and consume packages from another registry if you wanted to. And I'd like to think that if Microsoft made a hostile move like that, we could count on package managers like yarn to pull provenance data from other sources.