rust-secure-code / wg

Coordination repository for the Secure Code Working Group

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Crate Owners Security Manual

pinkforest opened this issue · comments

I was wondering what else we could do as a WG to help crate maintainers to keep their crates secure.

This was in combination with some governance stuff I had to sort out at cargo-geiger.

And I was thinking maybe documentation / best practice or "guidelines" could enable the maintainers to do the right things (tm)

It does need a catchy marketable name too! And it should be pleasant, fun and enjoyable to read/consume vs beating the morals.

It should be in story form so people can relate the importance best.

First I am wondering about the scope this thing could potentially cover -

Maybe

  • Thou Shall Not Roll Your Own Crypto
  • All the Badges You Can Eat in your README.md
  • Release Process repo & crates.io
  • Maintenance and handover
  • Dependabot / dependency monitoring and importance of it with stories
  • Unsafe Dark Arts
  • ..... ?

Also we should come up with a simple requirements type checklist to help crate maintainers to test themselves on the above

Every topic should enable the crate maintainer to automate from get-go that encourages good patterns without questions and friction that would deter adoption.

It'd be good to have some best practices documentation for this.

I wonder if there's a place we could upstream this to, like the Rust Book. But perhaps we could start with a Markdown file in this repo.

I don't think the main book is a great place for this content, as the target audience for TRPL is anyone wanting to write any code in Rust, while this content's target audience is anyone who wants to release a crate on crates.io for general usage, a much smaller audience.

It sounds like this would be similar to https://github.com/rust-lang/api-guidelines ; I'm not sure where that is linked from currently.

commented

Some existing (but not necessarily complete) books that seem related (but not quite the same) are