Manishearth

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 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.

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.

Yeah. I do use this trick.

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.

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.

But also tz info isn't that big I think...

I always say that if the strongest complaint people have about your language is syntax; you've already succeeded.

I don't understand your question.

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.

(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.

> Total BS too. Maybe in India.

This has been the case at both my current and previous (American tech) jobs.

And it's pretty racist to assume that a person is working or has worked in India just because they have an Indian name.