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.

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

It's useful to have when you have complex graph structures. Or when implementing language runtimes. I've written a bit about these types of use cases in https://manishearth.github.io/blog/2021/04/05/a-tour-of-safe...

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.

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

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.

Most of the graphs here are about new code.

[1]: https://security.googleblog.com/2021/04/rust-in-android-plat...

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.

I think most of these companies have had a pretty large investment, they're just not really open about it in many cases. So yeah, it's a pretty visible signal, but the investments they had already were much larger ones. A team of core developers is a pretty small investment compared to having a ton of teams all over the place, which most of them had already.

The wgpu crate is being developed by Firefox engineers for Firefox. As lastontheboat said we had a student integrate it into Servo this year.

The Linux Foundation is basically a catch-all foundation for smaller open source projects, this is not "Linux owns a browser engine".

The "Linux" there is more of an indicator of its origins than its purpose.

Many of us are looking for (or have found) dayjobs, but it's possible some folks may be open to contracting work on servo/etc. But nobody is being paid to work on servo right now.

We spent a significant amount of effort in the last year and a half working on a redesigned modular/parallel layout subsystem.

The VR focus was because it was a good way to get servo out to end users early without needing to be fully web compat -- WebXR doesn't require complex layout. We didn't drop our focus on full web compat during this, but full web compat has always been a more long term goal given how complex the web platform is.

Servo was never tightly integrated with a sizeable browser project. It shared some components with Firefox, but the only time Servo itself was inside an actual browser release was Firefox Reality for AR. Which still exists, though I'm not sure what the future of development for it will look like.

So this is the core problem with all of the general relativity materials that model it as a rubber sheet causing curvature in spacetime. They always model it with focus on _spatial_ curvature: which is totally able to model an orbit or a hyperbolic trajectory as a geodesic, but it totally cannot model "throwing a ball up" since the geodesic for throwing a ball up is just a straight line.

The important thing is that gravitation is a distortion in space-_time_, which is way trickier to model as a rubber sheet because you end up with one dimension of space and one of time. If you distort _those_ (also, they don't distort quite like a ball-in-a-rubber-sheet), you can get the results of a ball being thrown up. It's also possible to visualize this for 2 spatial dimensions with a distorted 3d space, but tricky.

No, not quite, the signature will be `fn foo<'a>() -> &'a u8` (there is no way to elide this)

However, Rust lifetimes are stretchy-squeezy, and a free lifetime is basically the same as 'static when it comes to covariant lifetimes, since both are "I can be whatever you want me to be".

However if the lifetime is invariant (e.g. in https://play.rust-lang.org/?version=stable&mode=debug&editio...), it is actually not 'static and will map to whatever lifetime is requested by the context.

I agree, as someone who works on rustc I think it's a significant endeavor to maintain a substantial fork of either Rust or LLVM.

(Rust does maintain a fork of LLVM, but it's just a couple minor patches that typically get upstreamed eventually)

The text was changed due to feedback provided elsewhere in this HN page.

The blog post was drafted by the core and foundation team, however we did get sign-off from Mozilla on it.

Mozilla currently owns the trademarks that the Rust foundation plans to take ownership of, so they have to be involved to some extent. They have agreed to transfer it as mentioned in the blog post, and are going to work with us to make that happen.

The Rust project as an open source project with open governance has been pretty independent of Mozilla for quite a while now. However, Mozilla did provide some crucial services including trademark ownership, which is _extremely_ relevant to the discussion of forming a foundation.

Trademark ownership and is rarely impactful to the day-to-day workings of the Rust project, which is why I consider these irrelevant to whether or not Rust is still being "incubated" by Mozilla.

I want to clarify: The Rust project has been largely "outside" of the Mozilla incubator for quite a while already; with most of the governance being non-Mozilla individuals. The main things Mozilla provided was infrastructure (a lot of which has moved out in the past year), trademark ownership, and paying some people to work on Rust full-time (which many companies do now).

Make no mistake, Mozilla has contributed a lot to the Rust project, but the particular stage of maturity you mention was achieved some years ago :)

When it comes to the Rust project: it was already well outside the confines of Mozilla, with an independent leadership team, and with a lot of the infrastructure being run by other companies (Github/Microsoft for CI, Amazon for storage, etc)

The main stuff that was left over was the trademarks, domains, and some infrastructure.

This does not seem simpler to me, this seems easier to mess up. The most common use case is dropping all fields.

Furthermore, you still have to special-case Drop because now you have to support destructive destructuring for Drop types because it isn't allowed anywhere else.

And plus, if you forget to do this, the failure mode is a stack overflow.

The current design is absolutely based on practical requirements here, it is not a retroactive justification. This is by and large how destructors work, for good reason.

> but Rust's Drop makes the same mistakes as C++: destruction needs to be for consuming data, not borrowing it and mutating it.

but Rust's drop isn't for that purpose. It's not for the actual cleanup of the struct and its children it is for additional cleanup before the children are deleted. So it has to be mutable. The compiler synthesizes the "delete children" code.

(I don't understand your point about drop<T>)

Yeah this was my biggest fear with edition changes: You can fix live code, but you can't as easily fix existing programmers' mental models, and you can't update all existing online resources.

OpenGL has this issue and it sucks, and i did bring this up during the edition discussions but it didn't stack up as well against arguments on the other side.

I'm self taught and "google things until it works" is a key aspect of how i learn, and i'm disappointed to see this workflow somewhat broken in Rust. Over time, it will heal (it's much harder to find stuff that uses `try!` now), but it's still annoying.

I address this in the second paragraph:

> impl Trait in return position has changed how people code; but that's because it made certain things suddenly possible, which isn't an idiom change as much as obsoleting some old bad workarounds.

this isn't a new idiom. this is code that wasn't possible before suddenly becoming possible, and people using it.