Publishing crates without GitHub? (and some criticism)

Yeah, brute force is why there's a requirement that the server accepting TOTP (or any other MFA) codes rate limits requests; though it's made a bit more complex by possibly needing to re-sync the clocks. Since you generally only accept these codes after the first authentication factor this is relatively simple to implement (key it against the unverified user id) and protects against getting it right by pure chance.

That requirement isn't visible when you're writing an MFA client at all, and often it's also handled by whatever auth middleware you may be using on the server, but it could be messed up like any other auth. As it's a second factor, it can only make things at least as secure as not being there, if it's completely bungled.

2 Likes

I agree, it's the major problem. You see only the iceberg tip, probably there are highest level of developers, just < 1,000 and you are among of them. You are very smart, well educated with a decent work experience. But majority of developers just blindly use what crates.io offers them. Say more, they unlikely ever look in the code of used crates. Unfortunately, crates.io gives you just a number of downloads, and says nothing about a quality of the code. The download number is a very deceiving. You can't relay on it. If you start review the actual crate code, you will scream - who's taught to code those programmers? Crates io should hide the download number and give only negative review count as Amazon, eBay and other e-commerce companies do. You probably saw many screams about NPM security. It's exactly what happened, people use any free code without worry how good it is. It's free! Why you should complain. AI makes the situation even worse:

A recent example is, I needed a string encoded to be used for JSON values. I wrote a function for that and then asked the forum to improve it. 30% performance improving compared to my original code was offered and it was was amazing. Then I asked AI same and guess what? AI told me to use serde JSON encoder. Say more, AI got offended when I asked as "your variant". I do not have my variant, it emphasized, I give you a common idiomatic approach. I corrected my question like I do not need a JSON string value, I need just a string encoding suitable for a string in JSON. Now, it was more interesting. AI said, thank you for the clarification, use still the serde JSON string encoding and then remove wrapping quotes, and then it provided Rust code for that.

You can see the future now: the current developer with a good knowledge of math and CS can value AI solution, but soon, he/she can't do it. So AI will just manipulate people's mind on the way creators of AI selected.

1 Like

I have a habit of projecting my care for unsafe code onto others. “Surely whoever writes unsafe code would take the time to know what they’re doing. Surely it’s better to use existing third-party code instead of taking the risk of making an incorrect implementation myself.” For some libraries, that thought is perfectly accurate. But for some others… their docs.rs page looked golden, their source code did not. I still need to read more of my dependencies’ source code.

1 Like

I've noticed this pattern in the 'Rustocean' in general—there's a crate for pretty much anything and developers seem to be encouraged to use premade crates wherever possible.

Sure, this tends to be more convenient and when such crates are actually well-written means not having to do redundant work. On the other hand I have run into certain crates where the developers' decisions are questionable, for example this problem I'm having using sqlx.

Some crates also seem to be trying to do too much, both in terms of providing more features than are actually needed; and having a lot of dependencies, for example in one of my projects something is pulling in Windows-related dependencies despite me not intending to explicitly support Windows systems.

Generally the more dependencies and therefore the more code in a project, the slower it is to compile, the more space required and the more opportunities for security issues to arise whether from buggy code or a malicious attack such as NPM has been experiencing recently.

Perhaps we should split this discussion to a new topic?

Hey, this exact topic has been on my mind as well for some time now.
I would drop GitHub in a heartbeat, if it wasn't for the requirement of authentication, when publishing a crate.

Can someone tell me what happens when I lose access to my GitHub account, which I used to publish crates in the past?
My best guess is, that I would lose the ability to maintain that crate, since the crates.io account is linked exclusively to the GitHub account.

I know there is already people working on moving things and making them happen - and they should take all the time which it takes to do those things without major hiccups.
The most on-point thread i found is this one: Refactoring to disentangle account creation from only one identity provider · Issue #10611 · rust-lang/crates.io · GitHub

Currently I am working on a handful of libraries/applications for reverse-engineering, data de-duplication and some other interesting shenanigans, which I want to share, but I am refraining from publishing further crates as long as I have this bad gut feeling with GitHub.

Just last month I had a rather sobering experience with their customer support - if you are not a big name (registered trademark) and paying enterprise, they don't really want to move a finger.

Remember when there was a certain sickness at the start of 2020, and just mentioning it's mere existence would get you (shadow)banned on YouTube?
It is something different than Microsoft running GitHub, but the point still stands: being at the mercy of big billion dollar enterprises for accessing/maintaining your projects, or landing on a shadow list of undesirables is something, that resilience should be built against.

3 Likes

Note that crates.io is subject to DMCA and other overreaching US banhammers. So your crates could be taken down regardless of the identity provider used by you.

Additionally, using GitHub for authentication on crates.io does not force you to host code of your published crates there. You can use Gitlab, self-hosted git server, or even do not provide any repository information at all.

This doesn't invalidate my concern - one less point of failure is still a win in my book.

I was already explicitly writing that it is required for authentication (and not hosting) - my crates are on my self-hosted cgit instance.

1 Like

That really doesn't help much: if you loose access to github, or don't have access to begin with, you loose the ability to ever release bug fixes to your crates (or publish them to begin with).

1 Like

IIUC the concern was that by releasing crates which may be considered legally gray GitHub may decide to close your account as a form of attack. But GitHub does not know about crates which you publish to crates.io!

Yes, it's possible to trivially look it up, but if you care about such theoretical scenario (someone powerful sees your crate on crates.io, does not like it, goes to GitHub and requests to close your account, and it gets done), then you should not consider publishing to crates.io in the first place since a far more likely scenario is that the take-down request will be sent directly to crates.io.

1 Like

My concern is a bit broader than that. Accounts getting closed randomly for little reason happens at all the big tech giants (though Google is worse by far).

2 Likes

Looks like the sentiment towards GitHub is souring in general, and it is not just a few people you see in this thread here: Zig is moving away from GitHub too.


And since the timing is very nice: there is currently the State of Rust Survey running.

If you haven't done it yet and can spare a few minutes, you can properly fill it out, and voice your concerns about GitHub at the very end in the free form field.
Just stay civil and objective :innocent:

4 Likes

Today I have concerns about GitHub:

  1. What is GitHub for? I always thought GitHub's primary purpose was hosting git repositories. However you visit Github's home page you will not find any mention of "git" except as part of the spelling of GitHub. You will not find any mention of "repositories" either.

  2. I could not view anything on GitHub. Not even my own open source repositories. Why, because when I try to it asks me to register or sign in. WTF?

The repository pages work fine without logging in for me.

1 Like

How do you imagine an easier search compared to the existing "Search or jump to..." input? Make it similar to the Google's home page?

There are many valid concerns about GitHub, but design of the home page for unlogined users is, even being generous, somewhere around the very bottom of the list.

Yeah, the search is there, just nothing mentions there may be some projects there. Probably because you are expected to land on a specific project from Bing anyway.

And it's kinda irrelevant to the main point here anyway. GitHub is being used as identity provider only, and the concern is that relying on only one identity provider is risky.

Turns out this is GitHub and Safari on my MacBook conspiring against me.

Mac/Safari has a user name and password for me on GitHub stashed away in its keychain or wherever. So when I try to visit my repos on ZiCog (zicog) · GitHub I get confronted with a login page. As it happens this Mac has an old password stashed away so I cannot get in.

At least not without going through the "forgot password" business...

Happily Chrome on the same Mac does not get in the way.

1 Like

Sometimes you want to preserve results of your work, however maintaining a home server can be inconvenient. GitHub plays the role perfectly and you can access it from anywhere, for example my employer blocks everything from an access but GitHub. You do not need to make your repository private, because in the era of AI, nobody is willing to find it.

I don't think anybody's saying don't use GitHub at all. And even less saying don't use rented storage on someone else's servers (a.k.a. the cloud). Rather the point is to not rely exclusively on one particular provider, GitHub. Allow some alternatives for people who for whatever reason have problems with GitHub, and an out just in the (improbable, but not completely impossible) case of some disagreement between GitHub and the Rust project itself.

3 Likes

Unfortunately when GitHub introduced TOTP, and I didn't have Rust TOTP implementation yet, I switched to GitLab and sourceforge.net. They are good alternatives to GitHub, but the quality of their software lower than GitHub provided, however my major reason to return to GitHub was that the firewall of my company allows only github domain freely accessed by employees.

maintaining a home server can be inconvenient

You still have other options: Codeberg, GitLab, and many smaller forges. It's unfortunate that your employer blocks these

4 Likes