Tracking issue for Security process update

[lehnberg]

This is a tracking issue for Security process update, mimblewimble/grin-rfcs#13

Steps:

• Make updates and changes to SECURITY.md as per the RFC.
• Move code reviews and audits section to a new page on the wiki
• Move chain splits section into a new issue on /grin
• Introduce canaries for each of the security contacts listed on SECURITY.md

Unresolved questions:

None so far

[lehnberg]

@j01tz feel free to pick this one up and keep us up to date with your progress ✌️

[j01tz]

Thanks @lehnberg I'll begin working on implementing the RFC changes into SECURITY.md 👍

[j01tz]

I had some thoughts on the chain splits and code reviews and audits sections:

Re: code reviews and audits section:

• what do we really want to say here that isn't already in the standard?
  • we don't have any formal mechanisms/protocols/budgets/timelines for future audits..
  • we do want to make it clear that future code reviews and audits depend on more funding
  • we do want to make it easy to find previous audit results
  • we do want security researchers to follow our standard for disclosure

Since there is no formal policy around code reviews and audits it may make sense to keep statements in this section broad until a policy is formalized via RFC or established by a relevant subteam. Also not entirely sure which section of the wiki makes sense for this page, maybe Basics?

Re: chain splits section:

• is this something the core team should be responsible for?
  • goes beyond "just writing software"...
• won't consensus rules handle chain splits?
• is something beyond "emergency coordination channel" really needed here?

Does it make sense to have this as an ongoing issue? If so should we seek the results of a policy, a software, a dedicated open discussion? Ultimately even if those things are in place it would still not address the fundamental issue in a decentralized way.

If the concern is ability to coordinate around an accidental chain split with the community, an emergency coordination channel should be sufficient here? Or is this discussion itself the reason we want to create a new issue?

[lehnberg]

what do we really want to say here that isn't already in the standard?

I read it as a call to arms and encouragement for security researchers to contribute and do audits / review of our code on a voluntary basis.

Also not entirely sure which section of the wiki makes sense for this page, maybe Basics?

Perhaps under Contributing?

Re: chain splits section:

What I meant there was to raise an issue for the aforementioned "chain split monitoring tool" so that it can be built or closed as a non-fix at some point. The rest does not need to be in an issue, I think.

[j01tz]

• Submitted a PR for the RFC implementation
• Added a wiki page for code reviews and audits
• Created an issue for chain split monitoring tool

[j01tz]

The remaining issues were addressed with mimblewimble/grin-security#1. I think we can close this once the updated mimblewimble/grin#3009 is merged.