Vendor lock-in

[Soni]

Currently, if you want to publish crates, you need a github.

I don’t feel like I have to expand on why this is icky, but it’s icky.

Also, if other crates depend on your crates, they can’t be published either.

It would be nice if this could be solved. My suggestion is, as always, federation and caching, like in mastodon. We should avoid tying the Rust ecosystem to github/microsoft.

[pietroalbini]

The reason why GitHub is the only way to log into crates.io is that nobody implemented other OAuth providers yet. There is an open issue on the crates.io repository tracking this feature:

Issue: Non-Github account creation

[Soni]

And I don’t want that.

I want to a registry where you login with keys (how you get those keys is up to you - argon2 or /dev/urandom it doesn’t matter), either over SSH or wrapped within a dummy TLS client certificate. This would be safer than GitHub as it simply doesn’t rely on (unsafe) OAuth. Oh, and there’s no such thing as usernames!

I’d strongly argue this is how cargo/crates.io should work. If someone intercepts the public key, say with an HTTPS proxy, they can’t publish crates because they don’t have the private key. But that’s something for a separate thread.

(tbh, I’d love just the ability to use arbitrary gitea instances for identity, altho I’ll likely never be able to fully delete github due to wanting to participate in rust stuff. but it’d still be an important step for me, deleting all my github repos and disassociating my crates from my github)

[jjpe]

If someone intercepts the public key

If this happens there’s no issue really, in asymmetric encryption systems (e.g. RSA used by GitHub) public keys are assumed to be readable by untrusted parties. I think that might even be where the name derives from And a public key is not enough, from what I remember you need a private key to push to GitHub, and another key/token to publish on crates.io.

[pietroalbini]

I want to a registry where you login with keys (how you get those keys is up to you - argon2 or /dev/urandom it doesn’t matter), either over SSH or wrapped within a dummy TLS client certificate.

That would be painful to use in the browser, as you can’t authenticate with SSH on a browser, and TLS certs are a pain to setup and maintain, compared to OAuth (the only time I had to use them was with StartSSL before it died… and it was not a pleasant experience).

This would be safer than GitHub as it simply doesn’t rely on (unsafe) OAuth.

What’s unsafe about OAuth? Personally I don’t know of any critical technical weakness of the protocol, but I’d love to be proven wrong here.

Oh, and there’s no such thing as usernames!

Usernames are actually pretty useful: you can easily see the other crates created by that person, and you can have a name to ping if there are any problems (like what I do with Crater).

(tbh, I’d love just the ability to use arbitrary gitea instances for identity, altho I’ll likely never be able to fully delete github due to wanting to participate in rust stuff. but it’d still be an important step for me, deleting all my github repos and disassociating my crates from my github)

I don’t think supporting arbitrary identity providers is going to happen, as it would make the spam/squatting situation way worse than it currently is (at the moment we rely on the third-party providers to provide another layer of protection against abusers).

[Soni]

Since the TLS client certs would just be wrappers for the keys, it’d be pretty easy to automate the wrapping of the keys and using it like SSH. (this can be done with an extension - just take an SSH private key, and make a self-signed cert from it.) And, unlike OAuth, you’re not sending a secret value with every request, you’re just confirming you have the secret.

[pietroalbini]

Since the TLS client certs would just be wrappers for the keys, it’d be pretty easy to automate the wrapping of the keys and using it like SSH. (this can be done with an extension - just take an SSH private key, and make a self-signed cert from it.)

I don’t think it’s practical to ask users to install an extension or deal with certs just to log into crates.io. That would be an huge UX regression, and you can’t use extensions on most mobile browsers.

And, unlike OAuth, you’re not sending a secret value with every request, you’re just confirming you have the secret.

If you’re on an untrusted network that intercepts TLS requests you shouldn’t log into sensitive websites at all. And I think (not actually tested this) client cert authentication would fail anyway if there is a MITM.

[Soni]

Yes, client cert would fail, rather than leaking secrets to third parties.

OAuth and proxies bad.

1. Define new standards
2. Implement standards
3. Deprecate previous standards
4. Push for adoption
5. ???
6. Profit

[pietroalbini]

Yes, client cert would fail, rather than leaking secrets to third parties.

Sure, but you’re trading an extra bit of security for people in untrusted networks (who should use VPNs anyway to connect to sensitive sites) with huge usability issues for everyone, especially on mobile. I don’t think it’s a worth tradeoff.

[Soni]

tbh I use argon2 to make keys from an username+password, browsers could do the same, you just need to give them time.

it’s absolutely worth it, if it allows deprecating HTTP auth.

[pietroalbini]

tbh I use argon2 to make keys from an username+password, browsers could do the same, you just need to give them time.

This is not the place to discuss future web standards or HTTP auth deprecation though :). That won’t happen overnight, and it would probably take years until an implementation of what you suggest is implemented on the majority of the users’ browsers.

We shouldn’t wait for that to improve crates.io though. An easy way to improve the status quo is to implement support for more OAuth providers, and the team said they welcome PRs for that!

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.