Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • Especially not now, what if they're down? ;)
    by sscaryterry
  • This is a big issue. https://janetdocs.org/ handles auth through GH which leads to... regular problems, unfortunately. I hope to migrate soon.
    by veqq
  • Sadly, that's probably correct. No outside single point of failure that can cancel users at will can be allowed to gatekeep open source projects.
    by Animats
  • Cargo tied itself to GitHub back when GitHub still looked like an open-source utopia. Now the dependency is deeply baked in, and rolling it back would be very hard.
    by linzhangrun
  • The teams support may be a bit trickier/less clear to move on, but generally: this feels like a great place where atproto / bluesky support would slot in well.
    by jauntywundrkind
  • I don’t see how that would be effectively useful for any aspect of the problems
    by dnfmfnfnfb
  • GitHub, just like NPM, is a liability of the worst order. I'm sure it's just coincidence that both are owned by Microslop. Anyway, having either of those as a mandatory dependency is a big no-no.
    by zombot
  • From a supply-chain perspective, Cargo is still in the same broad risk category as npm and PyPI: installing packages means trusting externally published code, including code that may execute during build or installation.

    Rather than looking for someone to blame - in this case, GitHub - we should focus on constructive ways to harden the ecosystem.

    by r2vcap
  • I'm working on a tool for collaboratively reviewing Rust crate dependencies: https://github.com/thirdpass-org/thirdpass

    Also supports npm, PyPI, and Ansible Galaxy.

    by rndhouse
  • That's a separate issue of supply-chain risk, and crates.io using GitHub auth isn't really material to that.

    The gripe with using GitHub auth for crates.io is that GitHub is owned by a large, fickle corporation with a (shall we say) complicated history with open source, and people object on principled grounds to being forced to use GitHub in order to participate in the crates.io ecosystem.

    by kelnos
  • The longer I go the more I have actually come to appreciate the way Packagist works for the PHP community, there are lots of cool things it does that I wish NPM or other registries did by default, like forcing you to package from a source repository, so that you can't upload a different artifact from what you keep in source control.
    by mikey_p
  • crates.io also only distributes source code.
    by steveklabnik
  • How does a close source package work? Depending on the language its not super helpful, but a package that is closed source should be possible.
    by ecshafer
  • I'm not sure that really gives you the guarantees you think it does, though.

    For example, I could push some malicious code, tag it, wait for Packagist to finish pulling it to publish a package, and then amend history to remove the malicious code, rewrite the git-tag, and force-push both to the git server.

    This scheme makes it hard/impossible to push mismatching code by accident, but doesn't do much to stop a malicious actor.

    by kelnos
  • My take: publishing Rust crates shouldn't depend on any single internet property, including crates.io.
    by dboreham
  • I mean... it technically doesn't? You can always point to other registries (or you can even just pull in git repos), we literally do this at work.
    by pyreko
  • I think crates.io is essentially just the default, and you can point cargo to an alternate package repository, if you so desire.

    I've worked on projects where we vendored all third-party crates, for example, so our config just pointed to that vendoring, and I think support ought to be better these days…

    by deathanatos
  • Go handles this well, kind of. It's super easy (in fact, transparent) to import from GitHub urls. You can self-host your Go packages, but it involves making and hosting some manifest files. Not as seamless as using GitHub, but still totally doable.
    by lorecore
  • In practice, Go is much, much more github dependent than rust, most go packages are on github
    by fyrn_
  • See the official project issue on this: https://github.com/rust-lang/crates.io/issues/326

    TL;DR: They want to fix this, it's a lot of work that no one's being paid to do, there's a roadmap with specific tasks that need doing, volunteer contributions are welcome.

    by ameliaquining
  • Just going to say it out loud :) Its been known for 10 years.

    https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_wha...

    by sscaryterry
  • That reminds me tailscale still depends on anyone-but-them for identity...
    by nottorp
  • > it's a lot of work that no one's being paid to do,

    aren't they like some kind of non-profit (in the legal sense) that is still able to take a lot of money (from players like Google and Co, to justify fixing this), as opposed to ... say the Zig foundation, ... that is is also "non-profit" but can't get money the same way?

    by DyslexicAtheist
  • I agree and so does the rust project. The main problem is that it's alot of work and it's hard.

    https://www.youtube.com/watch?v=zGS-HqcAvA4 Here's a long video from jon gjengset that shows how it works and some of the effort already done to de-couple from github.

    Crates is widely used so it's a rebuilding the track while the train is driving kind of problem.

    It's just not a priority for the project right now, but I would also definitely like to see the issue done. It might be good for the rust project to vote on things like this during surveys so they know where to focus work!

    by vsgherzi
  • An RFC was recently merged to unblock this: https://github.com/rust-lang/rfcs/pull/3963

    The implementation on this has started.

    Something to keep in mind is https://blog.m-ou.se/rust-is-not-a-company/. Rust is mostly driven by volunteers working on what they find interesting. Boring/uninteresting tasks depend on funding, a warm body to accept the funding, and a reviewer.

    by epage
  • Except it is a company: https://rustfoundation.org/

    And you forgot to mention the bureaucratic process that also blocks warm bodies from developing code because the changes are not/unlikely to be accepted regardless of the level of excitement

    by eviks
  • > https://github.com/rust-lang/rfcs/pull/3963

    Ironically hosted on GitHub.

    by zombot
  • It's not just that this is boring work, but there's disagreement about Cargo and crates.io's direction. There are a lot of changes people would like to make that get turned down.

    Crates.io and Cargo need namespaces, but the leadership flatly says no.

    There's a big problem with name squatting, and nothing is being done about this either.

    I get that there are more technically important issues around builds and reproducibility and the like, but this is pretty foundational stuff.

    by echelon