security proposal
=====
> дайте де

# Topic
Sensitive Software Update Proposal to reduce the "time to exploit" potential vulnerabilities in the network.

# Context

---
готово:
Sensitive Software Update Proposal позволит создать, голосовать и обсужать апдейт сети не раскрывая его широкой общественности через Proposal, что уменьшает возможность воспользоваться ещё не исправленной ошибкой в сети, изучив diff.

we continue хорошую полиси по avoid Disclosure Critical bug or security issue

Значимый пример - [Juno](https://twitter.com/assafmo/status/1511989375730688001?s=20&t=QgbDEYyNGx5mhLtk_eiFsA) который подвергся атаке, пока проходило голосование по принятию update

---

Sensitive Software Update Proposal will allow you to create, vote and discuss a network update without disclosing it to the general public through the Proposal, which reduces the opportunity to take advantage of an error that has not yet been fixed on the network by researching diff.

We continue a good policy to avoid Disclosure Critical bug or security issue.

A significant example is [Juno](https://twitter.com/assafmo/status/1511989375730688001?s=20&t=QgbDEYyNGx5mhLtk_eiFsA ) which was attacked while the vote on the adoption of the update was taking place

> Attackers used a known @CosmWasm bug to halt @JunoNetwork just a few hours before they deployed a patched version [name=Assaf]

[Global research](https://www.mandiant.com/resources/time-between-disclosure-patch-release-and-vulnerability-exploitation) on time to exploit show that a significant part of vulnerabilities were exploited **after** the patch was made public, thus, taking into account the Juno incident, it is clearly unsafe for the vulnerabities patch code as well as vulnerability description be public.

For 2019:

For these non-zero-day vulnerabilities, there was a very small window (often only hours or a few days) between when the patch was released and the first observed instance of attacker exploitation.

# Summary
Sensitive Software Update Proposal's code will be represented as a git patch file (diff with git commit history) in a IPFS, encrypted via the symmetric key, that is then redistributed among specific wallets via secret smart contract, ensuring only specific wallets (and their trusted personnel) as well as proposal's authors will be able to inspect the contents of the code that is to be applied to the network on successfully passing the proposal.

Current capability is trivially implemented as a **part of [Cosmovisor](https://github.com/cosmos/cosmos-sdk/blob/master/cosmovisor/README.md)** or a different **utility for inspecting encrypted diffs**.

digraph graphname {
    // This attribute applies to the graph itself
    // size="50,50";
    // The label attribute can be used to change the label of a node
    git [label="diff"];
    
    diff [label="encrypted diff"];
    // Here, the node shape is changed.
    ipfs [shape=box label="IPFS"];
    // These edges both have different line properties
    smart [label="smart contract"]
    
    1 [label="validators"]
    2 [label="devs"]
    3 [label="white hat"]
    
    eva [label="Eve"]
    
    git -> diff [color=blue]
    diff -> ipfs [color=blue]
    ipfs -> smart [color=blue label=" path"];
    smart -> 1 [label="key"];
    smart -> 2 [label="key"];
    smart -> 3 [label="key"];
    
    ipfs -> eva
    
    1 -> git [style=dotted]
    2 -> git [style=dotted]
    3 -> git [style=dotted]
    
    eva -> diff
}

# Variants of realisation
Choosing the best option may require discussion among the community

We see the need for 2 artifacts:

## for utility
* make new utility for working with encrypted diff
* fork Cosmovisor to extend functionality to handle Sensitive Software Update
## for network
* build smartcontract to publish update to a limited number of people
* write readme guide "how to make Sensitive Software Update" with a description about creating a new Sensitive Software Update massage
* make new type of proposal which will manage access to the encryption keys

The best solution we see is make new utility for working with encrypted diff and smartcontract to publish update to a limited number of people
In the future, it is possible to introduce this idea as part of the work of Cosmovizor to bring automatization and a new type of proposal.

# Motivation
------
готово:
Необходимо внести privacy в процес обновления сети. Not all data shood be exposed by default, и Sensitive Software Update среди них. Это глобальная практика открадывать публикацию информации об уязвимости до её исправления.

Начинаем с sicret т.к. тут уже есть необходимые инструменты. В будущем это решение можно будет интегрировать в cosmos sdk и распространить на все блокчейны сети Cosmos, это поможет сделать web3 более безопасным местом.

-------

It is necessary to introduce privacy into the network update process. We believe that not all data should be exposed by default, and Sensitive Software Update is among them. It is a global security practice to postpone the publication of information about a vulnerability until it is fixed.

We start with secret because there are already the necessary tools. In the future, this solution can be integrated into the cosmos sdk and distributed to all Cosmos blockchain networks, this will help make web3 a safer place.

## Motivation behind IPFS as a diff storage
Potentially, vulnerability fix may reach a significant size, which will make it quite cumbersome to store on a ledger, thus usage of a distributed storage protocol with additional encryption is necessary.

# Risks
* Low-trust towards the software update from stakers with voting power, but not the access towards the update's content.
* Remaining risks of validators exposing sensitive update information

# Benefits
* Significantly decreasing the lifetime of zero-day vulnerabilities