Implement security-process RFC

[j01tz]

This PR implements RFC-003.

[lehnberg]

Thanks for this @j01tz!

Thinking a bit more about the canary,

1. does it belong in SECURITY, or could it perhaps be broken out to its own section?
2. does it make sense to review who's supposed to sign the canary? I'm happy to be on there, but I would find it more useful if @yeastplume or @antiochp were included. Also Igno is away so will likely not show up to sign a canary any time soon.

[j01tz]

The canary could definitely have its own section. Qubes uses a dedicated repo: https://github.com/QubesOS/qubes-secpack/tree/master/canaries

I tried to change as little as possible to include the canary, but a dedicated section could maybe make it a little easier to verify a signature or review previously issued canaries. It could also reduce some clutter in the base security policy.

Ideally anyone with ability to push code to the Grin repo would sign. At the minimum I think we want anyone listed as a disclosure contact to sign. Regardless of who the signers are if we do commit to keeping the canary alive it is important to keep updated regularly. If we can keep the canary alive with more signatures that have repo access, even better. I think it's about finding the right tradeoff between security, consistency and friction here.

My thinking with restricting it to the disclosure contacts was that due to the sensitive nature of disclosures it is even more important to have a canary there as opposed to a general canary for a repo (where releases should already be pgp signed) with a much higher number of contributors that come and go. If we can get both, even better to the extent that it doesn't cause too much headache.

[lehnberg]

Nice work, LGTM 👍