TLDR: We should create a new Security Working Group to focus on the security of the Rust language and ecosystem.
I’d like to propose starting a new working group focusing on security. The group’s mandate would be twofold: First, to make sure that it is easy to write secure software in Rust and, second, to make sure that the infrastructure of the Rust project is secure. In particular, this would include things like:
Identifying reasons that programmers use unsafe in practice and creating crates to provide the same functionality behind safe, well-vetted APIs.
Identifying common security-sensitive tasks and creating crates to provide the same functionality behind safe, well-vetted APIs. This could be low-level and general like cryptography, or high-level and specific like some of what Rocket and Diesel do with certain kinds of sanitization and escaping.
Creating best practices around how to design security APIs that are difficult to misuse.
Making sure that the language makes it easy to write security-sensitive code. This includes features like a well-defined memory model (already covered by the Unsafe Code Guidelines Working Group) and first-class support for constant time operations (which are necessary for cryptography).
Tooling to automatically reason about the correctness of unsafe Rust code.
Improving the security of various Rust infrastructure such as artifact signing on crates.io, reproducible builds, build sandboxing (for build.rs scripts), etc.
What I’d like from members of the community:
Volunteer to be a member of this WG!
Give feedback on these focus areas, or propose new focus areas.
What I’d like from members of the core team: Tell me if I’m doing this right Is there any official process that I need to go through first, or is this proposal sufficient on its own?
After the dust settles, we can move on to more low-level logistics of when/how/how frequently we’ll meet and things in that vein.
Would this group also be charged with security infrastructure, such as https://github.com/rust-lang/crates.io/issues/75 and typosquatting/namesquatting policies? Or are you mainly proposing a secure coding group?
My idea was that security infrastructure would be under the group's purview, yes, although there's of course the question of how much we can bite off in practice. @bascule has expressed interest in this group, and I'd imagine that he would be interested in taking that on as part of the group's work.
I'm quite new to this community, so apologies if I am suggesting something that already exists.
I like all of these ideas! Something I would very much like to see added is: A public and maintained list of safe and high-quality crates that can be used for security-critical operations. Here I am especially thinking of crates providing cryptographic functionality. This list would contain crates that have been "vetted" by this WG. I see this going hand-in-hand with:
Identifying common security-sensitive tasks and creating crates to provide the same functionality behind safe, well-vetted APIs.
So that there could be made a list of "When you need X, use Y.". Describing common tasks and recommending high-quality crates for those. For example: "Recommended multipurpose cryptographic library: ring".
I like this idea as well. I would like to participate, but am a relative newcomer to Rust and the community.
I’m curious what the WG would do about FFI-type crates and functionality?
From my POV, the basic bindings are fairly repetitive and similar in quality - its the code that wraps the bindings and presents a safe® Rust api over top that can be of concern. I’m mostly concerned that I made a mistake somewhere in the binding itself, and it can be hard to test raw FFI bindings without a lot of effort on tests that actually make sense.
I could certainly see room for "official recommendations," or, at the very least, officially supported crates which the WG puts its effort behind improving/maintaining.
We'd love to have you
That's a great question. Personally, I've recently toyed around a bit with the idea of a 2-layer FFI crate. Basically, the lower layer is the real, raw FFI, and the higher layer provides essentially the exact same API, but safely. E.g., a pointer/length pair becomes a slice, a function which initializes uninitialized memory becomes a constructor which returns an object by value, etc. I'd certainly be curious to see if that pattern could extend to other FFIs and become a general pattern used elsewhere in the ecosystem. More generally, I agree that "safe FFI" is a worthwhile thing to spend effort on.
So I guess, given my practical, bleeding edge experience in it, I can at least speak to FFI-related secure type stuff. (All the crates I'm working on are still heavily in the development stage yet and aren't ready for wider use yet, so please don't use them yet.)
I'd also like to volunteer and try to contribute as best I can. I don't know how much time I'll be able to put aside exactly, as I haven't received my course plans yet. Meetings will prob. be difficult for me, depending on where they are located.
Yep, that's exactly the layout I've got. I'd certainly be interested in trying to standardize on that pattern and maybe provide some helper utilities. For example, here are some low-level utilities I wrote to help make writing these safe wrappers more sane. It's definitely a first draft, but something like it could be useful to the community.
This looks great! In general we're happy for WGs to form organically.
Some WGs have a primary repo in the rust-lang github org, while others have set up their own org. Let me know if you want help with any of that. Please include the standard Rust Code of Conduct and licensing.
We can also have some regular coordination between this WG and the core team, if it would be helpful to pass along issues/concerns/priorities.
Ah, fantastic! I think I’ll wait until the first meeting to make those administrative decisions (both on the repo and also on coordination with the core team) so I can get folks’ input, but I’ll let you know as soon as we’ve figured it out!
I have doubts this is possible, and often people's goals with this is misguided. I'll confess my outspoken support for an API to do this was misguided as well.
Is there any official process that I need to go through first, or is this proposal sufficient on its own?