I mean, we have the crates available for analysis. We take snapshots before deleting them.
We would probably be open to sharing files with those who ask. Probably, I don't know what other team members would think about that. This roughly matches the workflow you propose below where people can ask for access to these things, just a bit more manual.
Any way of keeping it around on the server in a way that is fetchable by cargo is a complete non-starter. Bright red lines are useful in security: _the file is gone_ is way easier to keep secure than "the file is still there in a way that might be fetched if you have the right flags set" now means that that flags mechanism is now security sensitive.
If you'd like us to have a nice page that shows deleted-for-security crates, that's probably a proposal we'd welcome, but it is not really something anyone has time to work on themselves. Right now we just remove them from the db after taking a backup.
The response was managed by the security-response team working with the infra team and the Rust Foundation's Security engineer. Tobias from the crates.io team was also involved but on vacation so it was not as active. This is normal.
What makes you say we were unprepared? We have been deleting malicious crates for a while. This is the first time those crates have wormed their way into an actual real crate that people use, but most of the playbook here was the usual one. We take a snapshot copy of the crate and then purge it from the system.
The security page thing is because the rustsec maintainers were not around or a part of the response as it was occurring. It's pretty normal for a security advisory on rustsec to take some time to merge. We should probably get everyone on the same page about when people not on the rustsec team can merge security advisories, because I do agree that getting them merged quickly is important sometimes.
The crates.io page and version history should have an entry, like red with an ! and a cross through with an advisory note explaining the security issue, accessible via the api as well so it is clear what happened.
The main crate entry should also contain a security advisory at top. I looked at the crate and it just looked normal; I had to dig to find the exact impact surface, and if I wasn't informed via secondary means (hackernews) I would not have known. This is unacceptable for a mature package management system.
cargo-audit is the automated mechanism you are looking for
The crate does have an advisories/"security" page on crates.io.
We could try and show the existence of a security-deleted crate on the page. This is not a priority for anyone, and I remain unconvinced that it needs to be (not that that is my decision anyway). File an issue and make your case to the crates.io team.
I recently used a pretty well-tuned LLM to find ~500 safety bugs across the Rust ecosystem. Most of them are minor, and even major safety issues in Rust usually mean "it's possible to accidentally use this API in a way that is broken" not "this is directly exploitable", but I didn't want to just file LLM output as issues on these repos.
I very briefly considered doing something like this: if I just post the results on the internet, people can crowdsource filing issues and working on fixes. It's certainly not the nicest way of doing this, but on balance I'd like these issues to be fixed eventually.
I ended up not doing that and am instead filing a couple issues a day because it's not that much of a burden. This was an experiment that was much more successful than I expected, so I didn't budget to spend this time, but it's also not a huge deal to slowly do it.
Can you at least provide some links to examples of the issues you’re filing?
I’ve seen so many claims of people who used LLMs to generate hundreds of issues that turned out to be full of hallucinations or non-bugs being described as bugs that any claim like this needs some real evidence. Saying you found 500 safety bugs in Rust but that you’re casually only filing a couple of them makes this hard to believe.
Don't let the hype turn you into a cynic. You're replying to a Rust core team member, who explicitly says the issues are mostly minor, across Rust ecosystem and not in Rust itself, and that they're filing them manually to avoid dumping unreviewed AI output on people.
I have a dozen or so critical CVEs now, it's not hard to believe at all if they're just hardening tasks. I can get a dozen hardening tasks from just one prompt. I don't even bother filing them as the critical ones are more important right now.
Some "root" passwords are ones I do not put in my password manager out of "what if my pwd manager gets compromised" paranoia, but that makes me more vulnerable to this.
And annoyingly some websites like to forget you're logged in. Not Google as much, but it's a thing that happens enough that means that there's a chance that I would blindly enter a password if my guard was down. A slight chance I think (especially in the last year where i've been worried about more sophisticated scams) but a chance nonetheless.
.... we're talking about serialization here. "convert to a raw string" is sort of the name of the game.
It's a string in a well specified string format. That's typically what you want for serialization.
Temporal is typed; but its serialization helpers aren't, because there's no single way to talk about types across serialization. That's functionality a serialization library may choose to provide, but can't really be designed into the language.
Worth highlighting: library-level GC would not be convenient enough to use pervasively in Rust anyway. library-level GC does not replace Rust's "point".
And there's a huge benefit in being able to narrowly use a GC. GCs can be useful in gamedev, but it's a terrible tradeoff to need to use a GC'd language to get them, because then everything is GCd. library-level GC lets you GC the handful of things that need to be GCd, while the bulk of your program uses normal, efficient memory management.
This is a very important point, careful use of GCs for a special subset of allocations that say have tricky lifetimes for some reason and aren't performance critical could have a much smaller impact on overall application performance than people might otherwise expect.
Yeah, and it's even better if you have a GC where you can control when the collection phase happens.
E.g. in a game you can force collection to run between frames, potentially even picking which frames it runs on based on how much time you have. I don't know if that's a good strategy, but it's an example of the type of thing you can do.
Diplomat has a wasm backend so it would even be really easy to produce a WASM ffi target with idiomatic JS and TS bindings.
Also, Diplomat supports traits and callbacks so you could actually make the timezone impl pluggable. Though we don't currently have JS support for that.
They're also explicitly tracking new code by language, and talking about memory safety vulnerabilities per year, and they also link to [1] which talks about how most memory safety bugs they get are in new code.
It's also useful to look at the "rate of bugs per line of new code" because even stablished, long stable projects have code churn. Rare is the project that is unchancged, frozen in bakelite, and any mild refactor can introduce regressions or affect relied upon implicit invariants.
(the person who posted the article here isn't the author (me))
The bugs in part 1 all around using higher ranked trait bounds. I'd disagree with the characterization that they're "feature requests": five years ago, yes, I would agree, but this entire area of the compiler needs to be bug-free for an upcoming feature (GATs) anyway, and indeed, the issues I found were often fixed by people working on fixing related GAT bugs. Ultimately, my use of higher ranked trait bounds is an attempt to emulate some of what GATs get you in stable Rust, so it's not surprising that the bugs are in the same area of the code.
If I understand correctly, GATs are about being able to change compiler assumptions about data types in user code? Generics acting on the compiler?
How is that helpful? Is it that you're trying to skip all the language boilerplate around creating objects? Are there any risks/footguns to that approach?
Generic type-driven code makes my head hurt, let me know if I'm somewhat close
GATs allow traits to abstract over associated types that are themselves to some degree abstract. In this case, it's necessary to do the relevant trait machinery around lifetime transformation since we need to be able to talk about "a replaceable lifetime of a type" in a generic way.
We would probably be open to sharing files with those who ask. Probably, I don't know what other team members would think about that. This roughly matches the workflow you propose below where people can ask for access to these things, just a bit more manual.
Any way of keeping it around on the server in a way that is fetchable by cargo is a complete non-starter. Bright red lines are useful in security: _the file is gone_ is way easier to keep secure than "the file is still there in a way that might be fetched if you have the right flags set" now means that that flags mechanism is now security sensitive.
If you'd like us to have a nice page that shows deleted-for-security crates, that's probably a proposal we'd welcome, but it is not really something anyone has time to work on themselves. Right now we just remove them from the db after taking a backup.
reply