PyPI Preventing Domain Resurrection Attacks

I wish Microsoft had done this to my deleted Hotmail, instead some random person got my email, and potentially access to every website I ever registered to with said email...

Why is Google notifying me that they'll delete the account associated with <some email address that i do own> lately then?

They'll delete the storage, or make that email available for new registrations?

It was quite possible to independently prove my report was genuine. I am confident they didn't take my word for it.

I give Google a lot of well-deserved criticism, but they handled this issue pretty well and quite promptly.

For a given version, yes. But the security risk here is about publishing a new (malicious) version of a previously trusted package, by taking control of an expired domain.

Say I'm using mydomain.org/abc and it's a perfectly fine package. I'm currently using v1.25.7. Two months later, I see a new version of mydomain.org/abc, v1.25.8. I will likely update to it and use it relatively confidently. But, unbeknownst to me, mydomain.org's registration expired one month ago, and a malicious actor has grabbed it in the meantime; and they have now released a malicious version of this package. Nothing in Go's security model prevents this type of attack, except that Google's package "cache" (the package repo that Go downloads things from) can be configured by Google to not provide that malicious package.

This is a major design flaw with the silly idea of using an extremely imparmenent identifier - DNS names, which can only be leased for a limited time and are automatically auctioned off after they expire - as the main identifier for something as long lived as Go packages. No other package ecosystem has this terrible design concept - even when they do use DNS, they use it only for an initial authentication, not as the only identifier.

For example, in Java's Maven repo, to publish a package org.mydomain.abc from a Maven Central account, you need to prove that you have ownership of abc.mydomain.org once when associating this package. Afterwards, the package name remains associated with your Maven Central account, forever. If you lose access to that domain name and someone else obtains, they can't go through the same steps, Maven Central won't let them, since that package name is already tied to your account.

This doesn't address availability or discoverability though. There are no upsides other than a fleeting sense of "decentralization", without any of the securities of a real decentralized protocol.

A malicious actor could, however, quite trivially add one to the version number. ;)

I really liked Keybase, and do note that Keyoxide exists as an open-source project where annotations of proofs are made directly on the PGP keys and no longer requires a central point of failure. ;)

I will say there are downsides to cryptographic keys being required for updating a package: One of the biggest pain points we have in Sandstorm is we both verify authors using their PGP key (from Keybase, as it happens, it's an old project), and we have a keypair for each app which you need to update it.

The end result unfortunately is sometimes we have trivial one-line fixes for apps which are abandoned by the author, and it is very difficult to deploy said fix to end users. This can hypothetically manifest in the form of unfixable security problems. We do have a way to forcibly change the key, but it's intentionally a pain to do, and of course, is possible because ultimately the central authority has the ability to code the platform to circumvent that key anyways.

Which is to say, you do trade some security risks for other security risks, whether it's a better situation is an exercise for the reader.

I think they meant cryptography not crypto currencies. I will forever hate crypto currencies for taking the entire concept of cryptography as their name and getting it associated with scams.