As far as I know, the ERRP rules describe the policies for the deletion of expired domains, which isn't required, so working off the auto-renew grace status was a good choice here. Most people don't realize that expired domains aren't guaranteed to go through the ERRP lifecycle [1].
> You should be aware that during the auto-renew period, the domain name may be available to third parties for registration, depending on your registrar's terms of service. You may also run the risk of having your domain name auctioned to a third party by your registrar during this period (depending on your terms of service)
The process described here sounds like a pretty reasonable approach to a hard problem. It won't catch everything, but it's a good approach and it's nice to see some effort put into the issue.
1. https://www.icann.org/resources/pages/registrant-about-errp-...
They'll delete the storage, or make that email available for new registrations?
I pressed 'try another way' and they told me they don't have enough information to prove the account is mine.
Fuck off Google basically. They could at least be honest and state that a phone number is required, instead of pretending that it's for verification.
That is how I am locked out of a gmail account... eventhough I have the right username/password, and backup email, and typed in a phone number, Google won't let me back in.
Don't use GMail
I give Google a lot of well-deserved criticism, but they handled this issue pretty well and quite promptly.
The other thing of course, is that the domain was expiring. So similar to PyPI just accepting in the parent article that an expired domain isn't trustworthy, Google could verify shortly thereafter whether or not the domain was renewed by the developer in question.
And ultimately, you're suggesting paying off an official to pretend someone is dead, so you can block package updates to a domain, which doesn't really introduce a security issue, and of course, is trivially reversible when the person in question is, in fact, still alive. As Tony Stark would say, "Not a good plan".
I forever am and forever will be a civil engineer somewhere in upstate New York thanks to them. Nevermind I was still in high school at the time and don't even have a shred of engineering qualifications. Whoever you are, thanks for the borrowed ladder my friend.
However, when devs change dependencies, an innocent `go mod …` might update to a new (compromised) version of a dependency.
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.
Upstreams going dark happens much more often than them going rogue. A system that requires you to prove more than you just control a domain isn't as vulnerable to this problem.
https://www.icann.org/en/contracted-parties/consensus-polici...
Here's an example from denic.de: https://www.denic.de/en/domains/de-domains/domain-deletion#c...
WHO IS policies also vary wildly, for example .de domains do not show registration date in the WHO IS, so it's not possible to know if a domain was dropped and re-registered.
(Actually we have, but nobody wants to make people install Metamask or similar to log into websites.)
Thread with comments announcing it: https://news.ycombinator.com/item?id=44520419
(I'm also not keen to follow Max to another project... they fucked up OKCupid pretty badly, and Keybase never actually had a business model, with predictable results, so I have to imagine FOKS is going to get enshittified somehow as well.)
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.
My understanding is that they were acqui-hired by Zoom - probably for optics reasons, since Zoom was having a series of high-profile security incidents around then. Keybase development basically came to a standstill at that point, probably because the team got pulled away to work on Zoom projects.
A less aggressively funded business might have limped on essentially forever with the base product.
I've personally worked at a startup that forcibly ejected its founders. It happens.
(The startup got sold for scraps about 6 months later. The service I personally worked on kept streaming video for about a year with zero maintenance, only failing when the hardware was physically powered off. This was well after the main database had collapsed, and the web UI was inoperable, while iframe embeds kept chugging along.)
Plenty of "founders" decide to sell out rather than follow their original vision no matter what. It's not even necessarily the wrong thing to do. But the prospect of a liquidity event can turn an idealist's head quickly.
this was one of the major problems with doing maven style domain based namespacing
namespaces when?!