# Vendor lock-in **URL:** \ **Category:** Uncategorized\ **Created:** [October 16, 2018, 10:51pm UTC](https://internals.rust-lang.org/t/vendor-lock-in/8590 "2018-10-16T22:51:54Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![Soni](https://avatars.discourse-cdn.com/v4/letter/s/a3d4f5/32.png) [@Soni](https://internals.rust-lang.org/u/Soni)\ **Post date:** [October 16, 2018, 10:51pm UTC](https://internals.rust-lang.org/t/vendor-lock-in/8590/1 "2018-10-16T22:51:54Z")
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. ---
**Author:** ![pietroalbini](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/pietroalbini/32/10694_2.png) [@pietroalbini](https://internals.rust-lang.org/u/pietroalbini)\ **Post date:** [October 16, 2018, 10:59pm UTC](https://internals.rust-lang.org/t/vendor-lock-in/8590/2 "2018-10-16T22:59:30Z")
The reason why GitHub is the only way to log into [crates.io](http://crates.io) is that nobody implemented other OAuth providers yet. There is an open issue on the [crates.io](http://crates.io) repository tracking this feature: > ---
**Author:** ![Soni](https://avatars.discourse-cdn.com/v4/letter/s/a3d4f5/32.png) [@Soni](https://internals.rust-lang.org/u/Soni)\ **Post date:** [October 16, 2018, 11:21pm UTC](https://internals.rust-lang.org/t/vendor-lock-in/8590/3 "2018-10-16T23:21:56Z")
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) ---
**Author:** ![jjpe](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/jjpe/32/9779_2.png) [@jjpe](https://internals.rust-lang.org/u/jjpe)\ **Post date:** [October 17, 2018, 7:25am UTC](https://internals.rust-lang.org/t/vendor-lock-in/8590/4 "2018-10-17T07:25:51Z")
> [@Soni](#): > > 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](http://crates.io). ---
**Author:** ![pietroalbini](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/pietroalbini/32/10694_2.png) [@pietroalbini](https://internals.rust-lang.org/u/pietroalbini)\ **Post date:** [October 17, 2018, 8:15am UTC](https://internals.rust-lang.org/t/vendor-lock-in/8590/5 "2018-10-17T08:15:20Z")
> [@Soni](#): > > 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). > [@Soni](#): > > 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. > [@Soni](#): > > 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). > [@Soni](#): > > (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). ---
**Author:** ![Soni](https://avatars.discourse-cdn.com/v4/letter/s/a3d4f5/32.png) [@Soni](https://internals.rust-lang.org/u/Soni)\ **Post date:** [October 17, 2018, 10:12am UTC](https://internals.rust-lang.org/t/vendor-lock-in/8590/6 "2018-10-17T10:12:14Z")
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. ---
**Author:** ![pietroalbini](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/pietroalbini/32/10694_2.png) [@pietroalbini](https://internals.rust-lang.org/u/pietroalbini)\ **Post date:** [October 17, 2018, 11:30am UTC](https://internals.rust-lang.org/t/vendor-lock-in/8590/7 "2018-10-17T11:30:38Z")
> [@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.) I don't think it's practical to ask users to install an extension or deal with certs just to log into [crates.io](http://crates.io). That would be an huge UX regression, and you can't use extensions on most mobile browsers. > [@Soni](#): > > 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. ---
**Author:** ![Soni](https://avatars.discourse-cdn.com/v4/letter/s/a3d4f5/32.png) [@Soni](https://internals.rust-lang.org/u/Soni)\ **Post date:** [October 17, 2018, 11:33am UTC](https://internals.rust-lang.org/t/vendor-lock-in/8590/8 "2018-10-17T11:33:15Z")
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 ---
**Author:** ![pietroalbini](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/pietroalbini/32/10694_2.png) [@pietroalbini](https://internals.rust-lang.org/u/pietroalbini)\ **Post date:** [October 17, 2018, 11:47am UTC](https://internals.rust-lang.org/t/vendor-lock-in/8590/9 "2018-10-17T11:47:02Z")
> [@Soni](#): > > 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. ---
**Author:** ![Soni](https://avatars.discourse-cdn.com/v4/letter/s/a3d4f5/32.png) [@Soni](https://internals.rust-lang.org/u/Soni)\ **Post date:** [October 17, 2018, 11:54am UTC](https://internals.rust-lang.org/t/vendor-lock-in/8590/10 "2018-10-17T11:54:19Z")
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. ---
**Author:** ![pietroalbini](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/pietroalbini/32/10694_2.png) [@pietroalbini](https://internals.rust-lang.org/u/pietroalbini)\ **Post date:** [October 17, 2018, 12:11pm UTC](https://internals.rust-lang.org/t/vendor-lock-in/8590/11 "2018-10-17T12:11:17Z")
> [@Soni](#): > > 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](http://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! ---
**Author:** ![system](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/system/32/14092_2.png) [@system](https://internals.rust-lang.org/u/system)\ **Post date:** [March 25, 2019, 8:31am UTC](https://internals.rust-lang.org/t/vendor-lock-in/8590/12 "2019-03-25T08:31:00Z")
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.