Not if the goal is to avoid vetting each new version as if it were a completely new dependency. The whole reason for the current system, and the very idea of new versions of "the same software", is that we want to be able to rely on the reputation of a project to make certain decisions. For example, we trust Linux 5.11.1 to be non-malicious and to be mostly stable etc largely on the reputation of the Linux project. We don't go around vetting the code of such s project except in efemer specific niches.
If we don't trust the provenance of the code we're getting though, that reputation becomes irrelevant. As such, this is a problem of identity assurances and access management, it can't be solved otherwise.
Ok: you've provided two requirements that I agree with:
- It should be possible to compare between two releases (I'd personally like to see a code diff, ideally with a complete path of the commits involved)
- Providing a reputation visibility mechanism (for publishers? author(s)?) across a series of releases is important
Those don't require user accounts necessarily, though. And responding to the end of your message: identity assurances, yep, those seem necessary; access management, I'm not so sure.
Access management is required to have identity assurances. If there's no way to ensure someone's identity is secure, how do we know it's them in the first place?
If we don't trust the provenance of the code we're getting though, that reputation becomes irrelevant. As such, this is a problem of identity assurances and access management, it can't be solved otherwise.