What if the maintainer had also given away the key used to sign the previous releases?

I know, it doesn't make much sense why would anyone do that, but then again, I think "why would you that?!" feeling is part of what is triggering the negative reactions here. We just don't expect people to do things we wouldn't.

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.

Would you have distrusted this maintainer though? If someone takes it over and publishes what appear to be real bug-fixes, I'd imagine most people would trust them. The same goes for trusting forks, or trusting the original developer not to hand over access.

> Would you have distrusted this maintainer though? If someone takes it over and publishes what appear to be real bug-fixes, I'd imagine most people would trust them.

Quite possibly. But I'd make a conscious decision to do it, and certainly wouldn't be in any position to blame the original maintainer.

The sale of any business that makes use of cryptography will generally include the private keys and passwords necessary to ensure business continuity. Code signing would not necessarily protect you against a human-approved transfer of assets as occurred here, whether as part of a whole-business sale or as a simple open-source project handoff.