Proposal: Security Working Group


#121

Don’t forget:


#122

OK, I’ve scheduled a meeting for tomorrow - Tuesday, Sept 25th - at 11:00 am - 12:00 pm PST (18:00 - 19:00 UTC).

You can join on Google hangouts (you do not have to be logged in) or call by phone: +1 417-429-4644 (PIN: ‪213 570#‬).

As I mentioned in the previous comment, this meeting’s purpose will be to discuss what we want the focus of the WG to be. I’ll prioritize ideas that have been discussed in this thread, so if you have a new idea you’d like to discuss, please post it here so people can read it first.

See you all tomorrow!


#123

Thanks for getting something on the calendar. I’m looking forward to it.

Edit: The link doesn’t appear to work.


#124

Try now?


#125

That did it. Thank you.


#126

Anyone has notes from the meeting?, I couldn’t assist it this week.


#127

Joshua took detailed notes. I believe he said he will post them later.


#128

I wasn’t planning on posting the notes themselves since they are pretty noisy, but certainly the summary. I’m just waiting to figure some last things out so I can post all at once rather than a series of small posts. This thread is long enough as is :stuck_out_tongue:


#129

Argh, apparently missed notification that there was going to be a meeting yesterday. Ah well, next time!


#130

What’s the status of the summary?

In other news, here is another great article about national cybersecurity:


#131

We just met with the core team yesterday, and we’re waiting for them to make some decisions about administrative details. We should have more for you in the next day or so.


#132

@joshlf At the very least you should be able to post the meeting notes for those who weren’t able to attend the meeting.


#133

Cool. Glad to see it being official and all. As such matters should.


#134

OK, heard back from the core team. It’s on!

Mission and Scope

The WG’s mission is to make it easy to write secure code in Rust. We have the following concrete goals:

  1. Most tasks shouldn’t require dangerous features such as unsafe. This includes FFI.
  2. Mistakes in security code should be easily caught.
  3. It should be clear to programmers how to use security-sensitive APIs correctly.
  4. Security-critical code which is relied on by Rust programmers should be bug free.

Here are some examples of some work that we might do in service of these goals. All of these examples are possibilities, but we aren’t guaranteeing that we’ll tackle any given work item, and the list isn’t exhaustive.

  • Most tasks shouldn’t require dangerous features such as unsafe. This includes FFI.
    • Identify common uses of unsafe or other dangerous features, and write crates/stdlib features/language features to provide the same functionality behind safe APIs
  • Mistakes in security code should be easily caught.
    • Write clippy lints for common security mistakes
    • Make sure it’s easy to integrate new static analysis tools into Rust
  • It should be clear to programmers how to use security-sensitive APIs correctly.
    • Contribute to documentation of security-sensitive APIs in crates/stdlib
    • Write guidelines on how to design security-sensitive APIs
  • Security-critical code which is relied on by Rust programmers should be bug free.
    • Encourage/participate in bug hunting in stdlib/crates
    • Take ownership of the RustSec project

Out of Scope

Cryptography will be explicitly outside of the scope of the WG. There is interest from some in starting a Cryptography Working Group, but that will be left for other efforts.

The following responsibilities were proposed at various times in the preceding discussion, but we decided not to take those on as responsibilities for the WG:

  • Curating “approved” crates
    • Reasoning: It’s too early to get behind single solutions for many security problems, and important to leave room for more innovation and exploration. This may make sense in the future if there’s community consensus, but it doesn’t make sense now.
  • Support for memory corruption mitigations (stack canaries, CFI, etc)
    • Reasoning: Our efforts are better spent on improving memory safety and its adoption, which makes these mitigations unnecessary.
  • Fuzzing
    • Reasoning: There’s already a well-established fuzzing effort.
  • Rust security book
    • Reasoning: It’s unclear what would go in here, and in any case, not high enough priority to focus on right now.

Administrative

The WG will report to the core team.

Naming

We want to make sure that people don’t mistakenly think that we’re in charge of things like triaging security issues (that’s the core team’s job). Some have expressed concern that the name “Security Working Group” might lead people to believe that we’re in charge of all security for the Rust project. As such, we’re going to try coming up with a different name, but we need suggestions! The name should be short and pithy, and should be consistent with our mission to make writing secure code easy. Some alternatives that have been proposed:

  • Secure Code WG
  • Ecosystem Security WG

If you have ideas, join the discussion on Twitter.


#135

Nice!

Is anything decided on the communication channels? Basically, now that it’s a thing, how do I participate?


#136

We’re still working on that. We’ve got a GitHub org set up, but we’re working on communication besides that. Our administrative repo will have details once we’ve gotten the other stuff set up.


#137

Sounds like a bootstrapping problem. How about if contributors want to help set things up?


#138

It’s getting a bit hard to coordinate with all of the cooks in the kitchen at this point, but I appreciate the offer! That said, we’re looking to design a logo if that’s the sort of thing you’re into!


#139

Sure, no problem, it’s called bootstrapping for a reason - pulling yourself up by your own bootstraps. The visibility of the process from my viewpoint is almost zero, though.

If you need the help, throw more tasks on this thread.


#140

Now that we have a GitHub repo, I’d suggest opening issues there rather than putting them here:

Things are easily lost in the shuffle here, and are easier to track and link to on GitHub. I’ll open another to get things rolling… where to chat!