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.
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.
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:
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:
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:
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.
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].
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.
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.
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]).
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:
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/...