A formalized process for issuing **critical** Cosmos SDK software updates

Okay, third of three :sweat_smile:
Figment Networks is looking for community consideration and feedback on our draft governance proposal for a formalized process for issuing critical Cosmos SDK software updates.
Thank you, thank you, thank you!

1 Like

As I understand this is concerning upgrades in which a security fault is found and a fix for it is required. I think in this case a clear distinction between “critical” and “emergency” (referred to in this other draft proposal - A formalized process for issuing **emergency** Cosmos SDK software updates) is required since they can be interchangeable.

A distinction should be made between mandatory and non-mandatory software upgrades. For example, a few days back Zaki’s validator had a problem which was determined to be DNS related. They issued a non-mandatory update and validators were free to choose if they upgrade this or not.

A mandatory update, on the other hand, might be required in the case in which something wrong is identified in the blockchain that could potentially result in a problem with the state or that jeopardises the security of ecosystem in some way.

In both of these cases, I am somewhat unsure of setting a specific time or even of using an expedited governance process at all. Once a bug is identified, a malicious user can try to use it to attack the network or a validator. Setting a fixed time in which the update is made public (i.e. the vulnerability is also made public) and voted on, could simply provide malicious parties with enough time to act.

One way of possibly dealing with this, is to have a community elected group that is responsible for handling these situations.

As an aside, I remember reading about a similar situation that occurred on the Zcash blockchain, where the team mainly responsible for developing Zcash stealthily introduced a fix to a vulnerability without notifying anyone beforehand.