Some time ago we proposed adding monero= field to Cargo.toml, and making docs.rs automine for the crate owner. Uhh regardless of how good or bad of an idea that might be, let's talk more seriously about the idea of putting a money= field in Cargo.toml
The idea is pretty simple. You can currently do:
homepage = "https://ganarchy.github.io/[...]"
It'd be nice to be able to do:
money = "https://patreon.com/[...]"
and have it show up on crates.io. There's not really any drawback to this as it's just another metadata URL, altho arguably we should have a generic metadata URL system like pypi does.
This thread prompted by the latest in zeroday java-related CVEs. We were told to bring this up here before trying to implement it in cargo but this honestly feels unnecessary?
Well, we do think that ideally this would be something cargo could use to remind you to support the developers of your dependencies and whatnot. But that's meant as "future work" because that's a whole discussion and just having the metadata for it seems like a good start.
One thing about this piece of metadata is that it isn't "permanent". The docs, readme, authors, tags, etc. are all relevant for a given release over any time span[1]. For funding, authors could migrate to a new platform or have their existing platform account(s) hijacked. How is one supposed to update previous release's "money" links with any updated information?
Maybe this should instead be associated with the cargo account itself instead of specific crates?
[1] I suppose "homepage" isn't quite as robust as others, but the risk there seems far lower (because the reward of overtaking the domain doesn't seem so immediate). Also archive.org exists to some extent for historical data.
The reward of overtaking the crate itself is much higher than anything you'd do with the money link. And repos also move more often than homepages, generally. You don't have to update old releases if cargo is aware of how the whole thing works. crates.io only shows the latest.
You just explained why we need an RFC for this in the same paragraph... As @mathstuf explained:
As soon as there is money involved, there will be people out to steal it in some manner. This can be from the simple (cloning an existing project, changing the name in a confusing manner, and uploading to crate.io with a new money link on it), to much more sophisticated attacks. Do we want to tarnish crates.io's image with attacks on user's financial accounts in some manner?
Before we step into that minefield, I want to really think about the potential issues. The RFC process will handle that.
Care to specify how it works beyond "add a new field" so that we're all on the same page here? How are tools like a hypothetical cargo-tithe that goes and donates to your dependencies supposed to find the latest information? It's not just crates.io that is consuming this information.
Really we should just have a generic URL metadata mechanism, like python's. Deprecate the existing one, and let ppl specify their own URLs. The only URL that shouldn't use the generic URL metadata mechanism is the docs URL but that's because crates.io generates docs.rs automatically, so the docs URL provides an override for that.
Then we'd also be able to add ganarchy URLs to the crate (instead of hijacking the homepage URL for those) which would be nice. It solves so many problems of "where to put the URL" that aren't actually solved by badges (because those are images).
(Altho, yes, deprecating the existing system and moving onto a new system would take an RFC.)
Edit: Also, honestly, unless you're proposing magnet: metadata, none of these metadata are at all permanent. They're all subject to change in various ways. The most reliable kinds of URLs you could use aren't at all supported by cargo - stuff like GAnarchy URLs, which we use for almost all our crates nowadays, are the closest you can get to reliable, permanent URLs, but we have no way to actually put those on a crate, because they're not https:, so instead we point homepage at a specific GAnarchy instance as a workaround. But anyway this is sidetracking, have you heard of FUD attacks?
I'm pretty sure the biggest reason why there's so much hesitancy to add a money= field, is because the field would seem to have the same problems as the authors= field, which was ultimately soft-deprecated because it failed to account for things like name changes.
p.s. I would actually really like to have explicit support for magnet: home pages and docs. BitTorrent gets an undeserved bad rep, mostly thanks to hostile ISPs and IT departments that refuse to use any peg that won't fit into an HTTP-shaped hole. But, in practice, crate documentation is usually small enough that it makes more sense to just bundle the file directly in the .crate package and link to it by filename, like how READMEs are handled. Basically the only exception is video documentation, but how many crates even have that?
That doesn't seem to be the concern ppl are bringing up. Many (most?) services actually use usernames, which, yes, they can change, but also repos also tend to be under the same username so those would change as well, and we don't see anyone rushing to deprecate the repository field.
Instead, the concerns seem to be about hijacking. But would a hardware wallet bitcoin address (or government-issued non-blockchain equivalent, basically a public key) have that issue? No it wouldn't. And those can just be represented as URLs.
We're not gonna pretend bit rot isn't a thing, but we're definitely gonna argue it isn't an issue. Let bits rot. Let ppl be forgotten. The world isn't immutable, but that's okay.
Edit: Also, to be completely honest, there's no reason crates.io couldn't use magnet docs in the backend. Have the client generate the torrent (v2-only, please - there's no reason modern users of bittorrent should support older versions, especially because crate docs don't already exist in the v1 format. there's no benefit to supporting it and the major drawback is being vulnerable to SHAttered.) and whatnot, upload it to crates.io, and then let crates.io seed it. Bittorrent protocols wouldn't be used at all between the client and crates.io.
It's like a federated forge, but without the code/repo hosting part of a federated forge. It's for project discovery and it enables some cool things like coordinating multiple distros coming together to independently work on the same project, so there isn't a "lead maintainer" or "core team" to boot distros off the project and instead distros are held accountable to eachother.
A long time ago I asked about removing the scheme filter so that I could use links to non-HTTP pages; but it's not something the crates.io team appears to want so would probably need good justification and an RFC to get through.
There should also be some mention in this thread of the existing tooling in this space. cargo-fund is one tool which doesn't require any additional package metadata, it simply uses the existing package.repository and scans the current HEAD for a funding.yml file; which avoids some of the issues around immutable metadata.
If your hardware wallet is stolen, or you change your legal name, or you move to a different country and all your banking details change, the actual solution is exactly the same. You need to be able to retroactively change the field for all your crates, ideally all at once so there’s no risk of forgetting to update some of them. Any copies of the now-compromised one left lying around are landmines.
That’s why these concerns are always being brought up together. From crates.io‘s perspective, since it’s not the authority giving out these identifiers, they’re the same problem. Something in the outside world caused a piece of metadata attached to a crate to become invalid, and now there’s a new value (or null) that needs to be used instead.
There’s no reason why you couldn’t generate webseed-enabled torrent files, just like archive.org does, with no significant architectural changes at all. Even a third-party could do it, without involving the crates.io team. Except I don’t think anybody would use them, because most crates are less than 4MiB. By the time you finished walking the DHT to find a peer, you’d already finish downloading the crate directly from S3.
Well yeah it's a similar issue to commit signing. Bitcoin doesn't really have a way to mark public keys as compromised, so hardware wallets can't really make a "suicide token" that you should keep safe and separate from the hardware wallet to nuke it when you get the chance. But government systems do have that, and will just bounce transactions. It's fine.
That's fair. But still, the way to make torrents viable is to build the ecosystem. But we should take this to DM, or a new thread, if you wanna discuss it further.
Making multiple network requests every time you cargo build just to seek an up-to-date funding.yml with which to nag the user seems silly if not outright dangerous.
We know it's weird to point this out not as a reply to anyone in particular, but, we feel like it's important to point out that immutable doesn't mean permanent. Git is permanent. crates.io is immutable. those are very different things.
And yes, crates.io does eventually bitrot, and that's okay. It's not permanent. You're not supposed to use an outdated, vulnerable version of a crate that hasn't been maintained in a decade. The source code for that version, on the other hand, is still useful to learn from and whatnot. That's the difference between mutability and permanence.
Not quite what we meant. Commit/release/binary/etc signing has the same issue of keys getting lost and having to revoke them and whatnot. It's just a thing that happens.