[ProjectTracking] Security Release Process Step 1: Build a "trusted validators group"

[Ekleog-NEAR]

Goals

Background

Our current security release process is currently the following:

1. We make a patch
2. We sparsely test it
3. We send it to Bowen
4. Bowen manually sends it to the top 34%-stake-owning validators
5. Once enough these validators have deployed it, we publish the patch

This proposal focuses on the “distributing the patch” part (steps 3-5) of this process. The “testing” part (step 2) is orthogonal to this proposal, as whatever we choose to do, we need to test with the patch still being secret.

Why should NEAR One work on this

The current security release process places too much stress on Bowen. In particular, it currently cannot work properly without Bowen’s involvement, which could be problematic eg. in case Bowen were to be unreachable.

What needs to be accomplished

This first step aims to build a trusted validators group, used only for emergencies (so it is high-signal for them), that release managers can use to directly warn of a code red vulnerability. Having this group will also help us actually vet the validators once, and not have to worry about who to send the patch to each time.

We would need to:

• Define a vetting process to enter this group
  • Ask the Validator Working Group about how they want to define the membership criteria, and merge that with our requirements
  • Example criteria set:
    • Run a validator, not a chunk-only producer
    • Have at least 6 months since joining mainnet
    • Well-known in the community (ie. other already-in community members can vouch for them)
  • Other criteria example, that we may or may not go with:
    • Has a legal entity (or be a named individual) in a country that we know of? (Some community members are probably not structured around a legal entity)
    • Signs an NDA for stuff we send on this group (that only lasts for eg. 1 week, as responsible disclosure goes)? If we go with an NDA we should make sure it has a short embargo duration, as otherwise we’d be encouraging leaks
    • Basically, the idea is to have someone to sue if something were to go wrong
• Create the group with only vetted points of contact
• Make sure that there is at least 1/3rd (50% for a safety margin) of the total stake in this group, to be able to stall the chain in case of attack. It would probably be better to ensure there are 2/3rds (80% for a safety margin) in case we need a protocol upgrade, but we should most importantly reduce the likelihood of an attacker in the group to the utmost minimum.
• Use this group instead of mail-from-Bowen for any future security patches we need to send. We could implement this group as one of a Telegram group, a Signal group (better encryption, but publishes phone numbers), or an email group (basically no encryption unless we implement heavy machinery like the oss-security ML)
• When we have a security release to make:
  • We send the patch to the trusted validators group as TLP:RED, thus triggering the NDA
  • Once enough validators upgraded (and maybe once the protocol version upgraded on mainnet, if necessary to fix the issue), we send the patch to the regular unvetted validator community as TLP:GREEN
  • After 1-2 days, we can release the patch on github (so, as TLP:CLEAR)
  • Depending on the severity of the issue, we can decide to skip one or more of these steps. In particular, we can skip the TLP:GREEN step for very severe protocol-level / money-forging vulnerabilities, because the validator community could contain an attacker, the public needs to be informed as quickly as possible for very severe vulnerabilities, and the TLP:RED step should be enough to mitigate anyway. Or we could skip the TLP:RED step for not-so-severe DoS-the-validator vulnerabilities.
• Optionally, we could make a nearcore-trusted repository, where we could publish the patch and where we would invite the validators, for easier tracing than manually sending patches to the group, especially with bigger patches? It might also make testing easier, but the way of sending patches to the group is not relevant for this proposal.

Main use case

The use case will be invisible until we need to do a security release with Bowen unreachable. However, the reason for processes is to not have to think during a crisis, and instead to just use the process that was carefully crafted ahead-of-time. Hence, we should craft this process before the need arises.

In addition, having the requirements clearly stated and the security release process documented, would help us clarify our stance towards validators, and avoid validators wondering why they did not receive the security patch ahead-of-time. It would thus help with our transparency.

Links to external documentations and discussions

Discussion has already started on the full design document.

Estimated effort

The node team is expected to work on this project, as they have the best contact with the validator community. The estimated time is 1-2 weeks-person, depending on the number of comments.

Assumptions

None

Pre-requisites

None

Out of scope

None

Task list

### Tasks
- [ ] define the exact vetting process to enter the trusted validator group
- [ ] create the group itself, with the validators we have vetted, making sure we have at least 50~80% of the total stake in the group
- [ ] write down a security release process document, that can mostly be copy-pasted from this project description, explaining in simple terms what exactly needs to be done during a security release
- [ ] optionally make a nearcore-trusted repository, shared with trusted validators