erickt

I also work on Fuchsia’s Software delivery team.

For some more detail on how we secure downloading components, we implement a concept called verified execution [1]. We establish a chain of trust from:

* a hardware key (on hardware that supports it), which checks the signature of

* the bootloader, which has a key baked into it and verifies that each boot slot has a properly signed vbmeta structure. This vbmeta then contains a hash of the zircon kernel, and the merkle root for the user space system image blob.

* we boot up zircon, which eventually starts up blobfs, our content addressed file system. It then reads the system image from blobfs, and launches Component Manager and Package Cache (which implements a package filesystem on top of blobs).

* package cache gets launched with the system image merkle from vbmeta, which allows us to know which packages are part of the base package set.

* base packages are then launched upon demand.

This establishes a direct line of trust from the hardware key to the base packages.

For over the air updates and ephemerally resolved packages, we use The Update Framework [2] and Omaha [3] for our package repositories. Each entry contains the merkle root for the package metadata, which in turn bakes in the merkle roots for each blob in the packages. We bake in the public keys for TUF and Omaha into our system image. This allows us to indirectly verify from hardware up that we are fetching the correct software.

[1]: https://fuchsia.dev/fuchsia-src/concepts/security/verified_e...

[2]: https://theupdateframework.io/

[3]: https://chromium.googlesource.com/chromium/src.git/+/master/...

ABI and API backwards compatibility is written up here:

https://fuchsia.dev/fuchsia-src/development/languages/fidl/g...

I believe the first major funding by the Rust Foundation was hiring Ferrous to help develop and maintain crates.io:

https://foundation.rust-lang.org/posts/2021-10-18-crates-io-...

I’d go further and say it’s not possible to fully implement async/await without compiler help.

I got really far with stateful, back in 2016 [1]. Stateful was an attempt to write a coroutine library in a proc macro, which generated state machines, as opposed to using os primitives like green threading. This was back before the rust community really started working in this space. I ended up extracting the type system from rustc to do much of the analysis, but it ultimately failed due to how difficult it was to output rust code that respected the borrow checker rules. I also didn’t have anything like the pinning system, so I couldn’t catch move issues either.

It was a much better idea to just implement this in the compiler.

[1]: http://erickt.github.io/blog/2016/01/27/stateful-in-progress...

The account issues have apparently been resolved, and Terraria port to Stadia has been uncanceled:

https://forums.terraria.org/index.php?threads/terraria-state...

Disclaimer: I work at Google, but don’t work anywhere near this.

Could (2017) be added to the title? Since then, Daniel has since rethought this post and is now writing a Rust backend for curl: https://daniel.haxx.se/blog/2020/10/09/rust-in-curl-with-hyp...

This is great news! I'm glad Servo found a place to land. Are you planning on sticking with the MPL-2.0 license, or are you also considering relicensing as well?

> Closed-world ("sealed") traits. Rust's rules against private types in the public API are good civilization but they make it difficult to define pseudo-private traits like Mount that I want users to name but not implement or call into.

Rust actually supports sealed traits by using public traits in private modules. See this for how to use it, and how it works:

https://rust-lang.github.io/api-guidelines/future-proofing.h...

Original author of serde here. I call it sir-dee, but the current maintainer, dtolnay, calls it sear-day. But we really don't care how people pronounce it. It's really more of a neither / potato thing:

https://www.youtube.com/watch?v=K75g7eRhH9M

The official rust book [1] is a great place to start. So are the exercism tutorials [2]

[1] https://doc.rust-lang.org/book/

[2] http://exercism.io/languages/rust/about

Drat, that must be the jekyll syntax highlighter. It might be easier then reading it off of github if you or anyone else has problems with reading the post:

https://github.com/rust-community/blog.community.rs/blob/gh-...

Organizer here!

Aidan actually submitted two entries. This particular entry that exploited this unsoundness bug wasn't actually the winner, even though it was great (horrible?). We weren't sure if the underhandedness would survive code review in this particular instance. He had to jump through some hoops [1] to trigger the unsoundness.

His other entry blew us away. It took us a long time to figure out how it worked.

[1]: https://github.com/rust-community/underhanded-submissions/bl...

Yeah, there's progress on 8-bit and 16-bit support. We're tracking our work on improving Rust for embedded systems in this roadmap issue [1], with details in this RFC repo [2]. As part of that, we have preliminary support for the 16 bit cpu MSP430 in-tree [3], and a fork for the 8-bit AVR in [4].

[1]: https://github.com/rust-lang/rust-roadmap/issues/15

[2]: https://github.com/rust-embedded/rfcs

[3]: https://github.com/rust-embedded/rfcs/issues/20

[4]: https://github.com/avr-rust/rust

Good idea. I noted that for next year's survey [1]. One of our big initiatives this year is working on our ergonomics [2]. I'm not sure if we can ever get as approachable as Python, but we've been working hard on trying to make the language easier. Results are starting to come out over the next couple releases. Things will hopefully be a bit better if/when you try the language.

Please let us know if you need any help!

[1]: https://github.com/rust-community/team/issues/160#issuecomme...

[2]: https://blog.rust-lang.org/2017/03/02/lang-ergonomics.html

Rust Core team member here.

Our code of conduct [1] has been the fundamental cornerstone of our project and community since the beginning. Every large institution ends up having to choose explicitly or implicitly how they deal with conflict. We wanted to put our beliefs up front to enable people to choose if they want to participate with us, or not.

When you boil it down, it's really "don't be a jerk". It doesn't seem to be that big of an ask that people don't harass each other, and for people to understand that everyone's situation is different. A lot of people have been discouraged from participating in tech, from active things like aggressive or rude language and sexualized imagery, to passive things like not providing for child care or mothers rooms at conferences. These are all things that are pretty simple to manage if you're aware of it.

It's our belief that not only is this just the right thing to do, it's our best strategy of growing our community. I don't have any proof, but I do attribute our welcoming community to why we have 1,856 contributors to just our compiler.

[1]: https://www.rust-lang.org/en-US/conduct.html

Core/Community team that helped design the survey here.

We actually did ask about this, but unfortunately it's quite time consuming to process through all the free text entry like this one. Some of the popular things people want from nightly are Clippy, impl traits, RLS, SIMD, and compiler plugins, which isn't surprising. It'll take some time to dig through the rest of the comments to see if there is anything unexpected.

I'm hoping to do follow on posts as we go, but no promises :)

Rust Core/Community Team member here, who helped design the survey. You got it. We asked this question to check whether or not we're succeeding at maintaining our backwards compatibility. While we have great visibility on if we're breaking our open source community with tools like cargobomb [1], we don't have great visibility into running tests against our commercial users (which we got a ton now! [2]).

[1]: https://github.com/rust-lang-nursery/cargobomb [2]: https://www.rust-lang.org/en-US/friends.html

Servo is still considered a research project, but one of the benefits of sharing WebRender, Stylo, etc between Servo and Firefox is that it is really helping to productionize those systems. That then will make it easier to turn it into a real thing.

> Kubernetes "secrets" aren't actually...well...secret. They're stored unencrypted in etcd with no ACLs. You must go outside the Kubernetes system to do this.

They are in progress towards encrypting at rest the etcd database. You can experimentally turn it on by following this doc:

https://kubernetes.io/docs/tasks/administer-cluster/encrypt-...

FYI, rkt was created (and I believe still predominantly maintained) by CoreOS: https://coreos.com/rkt

One of the most important tools when writing unsafe rust is compiletest [1]. It's a tool extracted from the compiler project that lets you write tests that are supposed to fail compilation. Since safe abstractions rely on the type system to make unsafe code safe, it's critical to make sure the compiler is properly rejecting code. I wrote a post about this years ago when I got hit by one of the bugs Gankro wrote about [2].

[1]: https://github.com/laumann/compiletest-rs

[2]: http://erickt.github.io/blog/2015/09/22/if-you-use-unsafe/

Hello! Rust core and community team member here. If you (or anyone else) are serious about trying to fund development of Tokio, please send us an email at [email protected] and we would happily connect you to people working on the project.

I think that was one of the proposed variations, but we ended up picking the shorter .expect to cut down on repetition. We expected (ha) that this function would be used in these one-offs, so we wanted something more efficient.

That is a good point. I'm going to have to start being more positive in my expectations :)

If I recall correctly we just couldn't come up with a great name for it. To me "expect" is a positive action, but the argument is about it failing to meet the expectation. Semantically I like `thing.unwrap_or(|| panic!("failure message"))`. It feels more like what I would want to say, but it just is so wordy.

Ultimately I'm happy we just picked something and moved on, but still mildly annoys me whenever I write it. If only we found that perfect method name way back when...

Hello Justin Turpin! Sorry to hear your struggles with rust. It's always going to be a bit more verbose using rust than Python due to type information, but I think there are some things we could do to simplify your code. Would you be comfortable posting the 20 line code for us to review? I didn't see a link in your post.

Anyway, so some things that could make your script easier:

* for simple scripts I tend to use the `.expect` method if I plan on killing the program if there is an error. It's just like unwrap, but it will print out a custom error message. So you could write something like this to get a file:

    let mut file = File::open("conf.json")
        .expect("could not open file");

(Aside: I never liked the method name `expect` for this, but is too late to do anything about that now).

* next, you don't have to create a struct for serde if you don't want to. serde_derive is definitely cool and magical, but it can be too magical for one off scripts. Instead you could use serde_jaon::Value [0], which is roughly equivalent to when python's json parser would produce. * next, serde_json has a function called from from_reader [1], which you can use to parse directly from a `Read` type. So combined with Value you would get:

    let config: Value = serde::from_reader(file)
        .expect("config has invalid json");

* Next you could get the config values out with some methods on Value:

    let jenkins_server = config.get("jenkins_server")
        .expect("jenkins_server key not in config")
        .as_str()
        .expect("jenkins_server key is not a string");

There might be some other things we could simplify. Just let us know how to help.

[0]: https://docs.serde.rs/serde_json/enum.Value.html

[1] https://docs.serde.rs/serde_json/de/fn.from_reader.html

Hello everyone! Rust Community team member here. We would greatly appreciate a moment of your time to help us understand how we did over the past year, and how we can improve over the next year. We'd love any input from people both already inside our community, or people that are not using the language.

Thanks so much! The community team will be hanging out here to help answer any questions you might have.