Etherlink 7.2 — undisclosed security upgrade via Fast governance on Wednesday, September 16th

This is a joint post from Nomadic Labs, TriliTech, and Functori

Hi everyone,

What is coming

As part of our continuous security review and hardening efforts on the Etherlink 7.1 (Ganesha) kernel, we will submit a new kernel, Etherlink 7.2, through Etherlink’s Fast governance mechanism on Wednesday, September 16th. It contains security patches that mitigate potential liveness attacks on Etherlink. No funds are at risk. It carries no new features: it is the Ganesha kernel currently running on Mainnet, plus these patches.

As we have done before with security issues found on Etherlink Mainnet, we cannot share the technical details of these patches ahead of the vote. This means bakers will not be able to reproduce the kernel’s root hash from public source before voting. Once the upgrade is activated and Mainnet is protected, we commit to publishing the source of the patches, the full changelog, and the reproduction instructions for the root hash, so that anyone can check that the kernel bakers voted on contains exactly what we said it contains.

Why fast-track

These issues are best fixed in the kernel rather than mitigated at the sequencer level, and there is no reason to leave them open for a full ten-day Slow governance cycle. Fast governance lets us close them in a single day, with full disclosure right after activation. We are posting now, ahead of time, so bakers have as much notice as possible, since fast governance voting windows are short.

:date: Voting periods

  • Proposal period: fast governance period 693, from L1 level #14,971,489 to #14,976,288. Expected to open on Wednesday, September 16 at ~08:31 CEST and close at ~16:31 CEST.

  • Promotion period: fast governance period 694, from L1 level #14,976,289 to #14,981,088. Expected to open at ~16:31 CEST on Wednesday, September 16 and close at ~00.31 CEST on Thursday, September 17.

The levels are fixed; the times are estimates and tend to drift later as blocks are produced slightly slower than the nominal schedule.

:backhand_index_pointing_right: Fast governance periods last ~8 hours. The Proposal period covers most of Monday’s working day and requires a 5% quorum to move to Promotion. The Promotion period runs into Monday evening and requires a 15% quorum and an 80% “yea” supermajority. If you can cast your upvote during the Proposal period and your “yea” vote in the evening, it will make a real difference.

:key: Kernel root hash: 009e07373751a43acbf0cd747b404f45130e0ad561c4b7da937e02eb812bd0f7e8

You can upvote the Etherlink 7.2 kernel during the Proposal period using the following Octez CLI command:

octez-client call KT19oUVQPnVLuUBYXrBVd46WJnNAMpqkKSwo from <baking_key or voting_key> \

  --entrypoint "upvote_proposal" \

  --arg "0x009e07373751a43acbf0cd747b404f45130e0ad561c4b7da937e02eb812bd0f7e8" \

  --burn-cap 0.11

If the Proposal period is successful, you will be able to vote for the kernel during the Promotion period:

octez-client call KT19oUVQPnVLuUBYXrBVd46WJnNAMpqkKSwo from <baking_key or voting_key> \

  --entrypoint "vote" --arg '"yea"' \

  --burn-cap 0.11

See How is Etherlink governed? | Etherlink documentation for further instructions on how to participate in Etherlink’s governance.

:folded_hands: Thank you for your continued support of Etherlink, and for helping strengthen its security posture.

4 Likes

`Once the upgrade is activated and Mainnet is protected`

This is the thirst security upgrade using fast track in only two months - which never happened before in L1. I`m once more telling my baker my vote is a NO on these things. Don`t get me wrong I have a big stake on Tezos since ICO, but on a moral side I prefer to see things getting destroyed than keep going with bad behaviour.

`We are posting now, ahead of time, so bakers have as much notice as possible, since fast governance voting windows are short.`

One day before notice now is `ahead of time.` :joy: Poor bakers cannot even go on vacation.

I, for one, am fully sick of the ‘trust me broh’ release cycle we’re on. I won’t participate in it any further.

(post deleted by author)

You know @skullzarmy, it’s not possible to disclose security vulnerabilities before the fixes are in production. Otherwise, you’re simply telling malicious actors what to exploit.

1 Like

fix the processes that are pushing vulnerabilities into production. this is the formal verification chain is it not?

if it is then even with a blind hash you can prove certain properties about the code are going to hold right? so do that