Even package managers where signing support nominally exists, the take-up is often poor.
IIRC rubygems support package signing but almost no-one uses it, so it's effectively useless.
We're seeing the same pattern again with Docker. They added support for signing (content trust) but unfortunately it's not at all designed for the use case of packages downloaded from Docker hub, so it's adoption has been poor.
I think browsers show how to migrate away from insecure defaults successfully. The client software should start showing big obvious warnings. Later stages should add little inconveniences such as pop-ups and user acknowledgement prompts, eg. 'I understand that what I'm doing is dangerous, wait 5 seconds to continue'. The final stage should disable access to unsigned packages without major modifications to the default settings.
Browser security has heavily benefited from the fact that ther are a small number of companies with control over the market and an incentive to improve security.
Unfortunately the development world doesn't really have the same opporunities.
If, for example, npm started to get strict about managing, curating, security libs, they could just move to a new package manager.
Security features (e.g. package signing, package curation) have not been prioritised by developers, so they aren't widely provided.
actually when publishing to the biggest java package repository (sonatype) you NEED to sign your packages.
also you can't transfer ownership without giving away your domain or github account. But you can add others to also upload to your name, but if an accident occurs your liable, too.
IIRC rubygems support package signing but almost no-one uses it, so it's effectively useless.
We're seeing the same pattern again with Docker. They added support for signing (content trust) but unfortunately it's not at all designed for the use case of packages downloaded from Docker hub, so it's adoption has been poor.