lavamoat / tss-snap Goto Github PK

View Code? Open in Web Editor NEW

52.0 52.0 9.0 2.72 MB

Threshold signatures snap for MetaMask

Home Page: https://tss.ac

License: GNU General Public License v3.0

Rust 28.60% HTML 0.37% JavaScript 2.01% Makefile 0.33% TypeScript 67.98% Dockerfile 0.67% Shell 0.04%

ethereum metamask mpc threshold-signature

tss-snap's Introduction

LavaMoat

LavaMoat is a set of tools for securing JavaScript projects against a category of attacks called software supply chain attacks.

This genre of attack occurs when a malicious dependency makes its way into a developer's application. An attacker could use the dependency to then steal important secrets (like credit card numbers, private keys, or data) or make the application vulnerable to a range of other attacks.

These attacks have already hit e.g. the cryptocurrency ecosystem and present a significant risk for the developers and users of wallets and apps.

In order to help mitigate the risk of such an attack we are building a suite of tools that aim to tackle the supply chain security at various stages of software lifecycle i.e. at the installation of the package, at build time and most of all - at runtime.

The goal of LavaMoat is to bring added protections to modern JavaScript apps without having to rewrite them from scratch and automate a good first-start security configuration.

Watch the introduction video

How to secure your app against supplychain attacks

disable/allow dependency lifecycle scripts (eg. "postinstall") via @lavamoat/allow-scripts
run your server or build process in lavamoat-node
build your ui with LavaMoat for Browserify

Even starting with adding just step 1 - the allow-scripts is a great improvement to your supply chain security.

How LavaMoat works

Install scripts

Lavamoat's allow-scripts configures your project to disable running install scripts by default and gives you a configuration section in package.json where the allowed ones can be listed. It also installs a package with an install script that fails installation as early as possible if the configuration is accidentally removed.

No new install scripts showing up in your dependencies will run unexpectedly. That way you eliminate the most popular attack vector of malicious packages in recent years.

Runtime protections

You can use lavamoat to prevent malicious code introduced into a package from running.

The LavaMoat runtime reduces the supply chain risk by:

Prevent modifying JavaScript's primordials (Object, String, Number, Array, ...)
Limit access to the platform API (window, document, XHR, etc) per-package

Both are provided by SES containers. Platform API access is granted by a policy file that LavaMoat can generate and allow the project to selectively customize. All details of policy file structure are documented in the Policy file explained doc.

SecureEcmaScript (SES)

SES is the sandbox used in LavaMoat. See SES's secure computing guide to learn more about the risks of untrusted javascript.

LavaMoat runtime protection in Node.js

Run your server or app building code with protections via LavaMoat Node

LavaMoat runtime protection in the browser

When using LavaMoat in the browser, you can just use your favorite bundler if there is an available plugin.

App bundles have two major components:

Runtime (aka kernel / loader / prelude / trusted computing base) This is the code that initializes and runs the bundle. For example, the implementation of the require function.
Module sources This includes the js content of the module sources, and sometimes some config information like module name aliases.

LavaMoat modifies the bundle's runtime to enforce the configured constraints.

LavaMoat Browserify

lavamoat-viz

[!WARNING] lavamoat-viz is currently unmaintained; we have tentative plans to resume development in the future.

lavamoat-viz is a tool to visualize an application's dependency graph and assess its security risk.

Scuttling security feature

LavaMoat offers further (yet advanced) security enhancement to LavaMoat protection which is known as scuttling - an optional feature which is turned off by default and can enhance the security LavaMoat will apply to your application. Before using it, make sure to get yourself familiar with it and with the implications of using it by reading its doc file.

Supporters

Made with love by MetaMask

Funded by ConsenSys

Runs on Agoric

tss-snap's People

Contributors

Stargazers

Watchers

Forkers

kumavis isabella232 t0m1sacat davidlucid 0xyao bitbeen bonnai2112 luca992 seanpm2001

tss-snap's Issues

Websocket issue while using docker

Seeing the following error on browser console on page load: index.js:2 WebSocket connection to 'wss://0.0.0.0/demo' failed:

Handle over-subscription

When parties is reached do not allow new connections to join the group.

Harden MessageCache

Use the round identifier to segregate peer messages in MessageCache and protect against messages being received out of order.

Signing error in Javascript (undefined is not iterable)

console.info:  client2 transition 0 to KEYGEN_ROUND_1
console.info:  client3 transition 0 to KEYGEN_ROUND_1
console.info:  client3 transition 1 from KEYGEN_ROUND_1 to KEYGEN_ROUND_2
console.info:  client3 Got incoming messages with length 2
console.info:  client3 Got incoming messages [Object,Object]
console.info:  client1 transition 1 from KEYGEN_ROUND_1 to KEYGEN_ROUND_2
console.info:  client1 Got incoming messages with length 2
console.info:  client1 Got incoming messages [Object,Object]
console.info:  client2 transition 1 from KEYGEN_ROUND_1 to KEYGEN_ROUND_2
console.info:  client2 Got incoming messages with length 2
console.info:  client2 Got incoming messages [Object,Object]
console.info:  client2 transition 2 from KEYGEN_ROUND_2 to KEYGEN_ROUND_3
console.info:  client2 Got incoming messages with length 2
console.info:  client2 Got incoming messages [Object,Object]
console.info:  client1 transition 2 from KEYGEN_ROUND_2 to KEYGEN_ROUND_3
console.info:  client3 transition 2 from KEYGEN_ROUND_2 to KEYGEN_ROUND_3
console.info:  client1 Got incoming messages with length 2
console.info:  client3 Got incoming messages with length 2
console.info:  client3 Got incoming messages [Object,Object]
console.info:  client1 Got incoming messages [Object,Object]
console.info:  client1 transition 3 from KEYGEN_ROUND_3 to KEYGEN_ROUND_4
console.info:  client1 Got incoming messages with length 2
console.info:  client1 Got incoming messages [Object,Object]
console.info:  client2 transition 3 from KEYGEN_ROUND_3 to KEYGEN_ROUND_4
console.info:  client2 Got incoming messages with length 2
console.info:  client2 Got incoming messages [Object,Object]
console.info:  client3 transition 3 from KEYGEN_ROUND_3 to KEYGEN_ROUND_4
console.info:  client3 Got incoming messages with length 2
console.info:  client3 Got incoming messages [Object,Object]
console.info:  client1 transition 4 from KEYGEN_ROUND_4 to KEYGEN_ROUND_5
console.info:  client2 transition 4 from KEYGEN_ROUND_4 to KEYGEN_ROUND_5
console.info:  client3 transition 4 from KEYGEN_ROUND_4 to KEYGEN_ROUND_5
console.info:  client1 transition 0 to SIGN_ROUND_0
console.info:  client2 transition 0 to SIGN_ROUND_0
console.info:  client1 transition 1 from SIGN_ROUND_0 to SIGN_ROUND_1
console.info:  client2 transition 1 from SIGN_ROUND_0 to SIGN_ROUND_1
console.info:  client1 transition 2 from SIGN_ROUND_1 to SIGN_ROUND_2
console.info:  client2 transition 2 from SIGN_ROUND_1 to SIGN_ROUND_2
console.info:  client2 transition 3 from SIGN_ROUND_2 to SIGN_ROUND_3
unhandled error: client2 undefined is not iterable (cannot read property Symbol(Symbol.iterator))

Consider e2e private/public key storage

Remove webpack dependency

The parcel production build appears to be working as expected now.

Create dummy signed message for public key extraction

At the end of the key generation phase:

const secp256k1 = require('secp256k1')
const util = require('ethereumjs-util')

// secp256k1.ecdsaVerify(sigObj.signature, 'hello world', pubKey)

const sigObj = {
  "r": "9269546768ee97fdcfede9f9db143f73a942a093e5eee3a400637b997c8dc584",
  "s": "26358533f4a3244fc17a67500322bbaf50ffcdf691ec9aa635afbc77da958858",
  "v": 1
}

const msgHash = Buffer.from('35a0acc238f6db52c770d9f85a57eb594879cad404143dc571aed338513f9604', 'hex')
const sig = Buffer.concat([Buffer.from(sigObj.r, 'hex'), Buffer.from(sigObj.s, 'hex')])
const publicKey = Buffer.from(secp256k1.ecdsaRecover(sig, sigObj.v, msgHash, false)).slice(1)

// const publicKey2 = util.ecrecover(msgHash, 27 + sigObj.v, sig.slice(0,32), sig.slice(32))

console.log('public:', publicKey.toString('hex'))
// console.log('public:', publicKey2.toString('hex'))
console.log('address:', util.pubToAddress(publicKey).toString('hex'))

Support key recovery passphrase mnemonic

Create playwright test specs

https://playwright.dev/

Restore wallet connect function

Optimize the performance of the wasm version of the multi-party-ecdsa library

Hello, I found that after I converted the multi-party-ecdsa library to wasm, its performance dropped by more than ten times. Do you have any good methods to further improve its performance? I tried to use the automatic vectorization of rust to optimize the performance. Perhaps it was a problem of operation. I did not make substantive progress.

Server is emitting sessionSignup multiple times

Which is why we need the runningSession hack on the client.

Here are some server debug statements to illustrate:

Sending threshold notify event sessionSignup for Keygen
Sending threshold notify event sessionSignup for Keygen
Sending threshold notify event sessionSignup for Sign

Support gg20 protocol

[Bug] Cannot sign (party 4 out of 4)

Console logs: tss.ac-1679991450832.log

Return recid in sign result

Try without threads and SharedArrayBuffer

Now that this issue has been addressed: rayon-rs/rayon#861

Support configurable parties / threshold per group in UI

Panic during signing (Incorrect Alice's range proof in MtA)

panicked at 'Incorrect Alice's range proof in MtA: InvalidKey', /Users/muji/.cargo/git/checkouts/multi-party-ecdsa-a285231579811539/c80c87d/src/protocols/multi_party_ecdsa/gg_2020/state_machine/sign/rounds.rs:156:14

Stack:

init/imports.wbg.__wbg_new_693216e109162396@http://localhost:8080/wasm_pkg_ecdsa_wasm_js.index.js:350:19
@http://localhost:8080/d2877673594000572e95.wasm:wasm-function[832]:0xbe1e3
@http://localhost:8080/d2877673594000572e95.wasm:wasm-function[233]:0x884f9
@http://localhost:8080/d2877673594000572e95.wasm:wasm-function[613]:0xb8f52
@http://localhost:8080/d2877673594000572e95.wasm:wasm-function[641]:0xb9812
@http://localhost:8080/d2877673594000572e95.wasm:wasm-function[480]:0xaaa71
@http://localhost:8080/d2877673594000572e95.wasm:wasm-function[43]:0x295b3
@http://localhost:8080/d2877673594000572e95.wasm:wasm-function[191]:0x7ab85
signProceed@http://localhost:8080/wasm_pkg_ecdsa_wasm_js.index.js:156:20
callback@http://localhost:8080/vendors-node_modules_comlink_dist_esm_comlink_mjs.index.js:115:48

Research WASM file size with async runtime

Compare tokio, async-std and smol.

See: ZenGo-X/multi-party-ecdsa#139 (comment)

Sign multiple times

Update the UI and flow to sign multiple messages

Key generation does not always complete (gg2020)

A question about safe primes

Due to performance issues in the browser environment, it is not practical to use safe primes in wasm, and all tss-ecdsa schemes recommend safe primes, but I have seen some discussions that safe primes do not seriously affect security.

https://security.stackexchange.com/questions/73505/use-of-safe-prime-in-rsa-digital-signature-scheme
https://acsc.cs.utexas.edu/libpaillier/
https://crypto.stackexchange.com/questions/47729/safe-primes-in-rsa

Not sure what you guys think about this, given that wasm environments can only use schemes that are not safe primes.

Key share is null error (gg2020)

Intermittent error when signing:

Uncaught (in promise) TypeError: keyShare is null
    signMessage http://localhost:8080/index.js:87202
    step http://localhost:8080/index.js:87184
    verb http://localhost:8080/index.js:87165
    __awaiter http://localhost:8080/index.js:87159
    __awaiter http://localhost:8080/index.js:87155
    signMessage http://localhost:8080/index.js:87193
    sign http://localhost:8080/index.js:86625
    step http://localhost:8080/index.js:86605
    verb http://localhost:8080/index.js:86586
    __awaiter http://localhost:8080/index.js:86580
    __awaiter http://localhost:8080/index.js:86576
    sign http://localhost:8080/index.js:86613
    onSignMessage http://localhost:8080/index.js:86355
    step http://localhost:8080/index.js:86253
    verb http://localhost:8080/index.js:86234
    fulfilled http://localhost:8080/index.js:86225
    promise callback*step http://localhost:8080/index.js:86227
    __awaiter http://localhost:8080/index.js:86228
    __awaiter http://localhost:8080/index.js:86224
    onSignMessage http://localhost:8080/index.js:86346
    onceWrapper http://localhost:8080/index.js:31158
    emit http://localhost:8080/index.js:31068
    WebSocketClient http://localhost:8080/index.js:85368
    step http://localhost:8080/index.js:85296
    verb http://localhost:8080/index.js:85277
    __awaiter http://localhost:8080/index.js:85271
    __awaiter http://localhost:8080/index.js:85267
    onmessage http://localhost:8080/index.js:85349
index.js:87202:42

Audit notes

Verify the k value computation during signing

Research libp2p integration

For cross device p2p communication.

Pass in string hex value for message

Protection against rushing adversary

Links to join sessions could include a unique party identifier that would prevent the participant from joining the same session multiple times.

Valid threshold in create parameters is being flagged as over the parties

Next button on signing fails silently sometimes

Sometimes when viewing the "Sign Message" or "Sign Transaction" screens and clicking "Next" nothing happens and no error occurs.

Need to figure out why this is happening. Refreshing and re-connecting to the snap seems to resolve the issue.

Sign error panic

panicked at 'called `Result::unwrap()` on an `Err` value: Error("invalid type: integer `1`, expected a tuple of size 2", line: 1, column: 1)', src/sign.rs:313:58

Stack:

init/imports.wbg.__wbg_new_693216e109162396@http://localhost:8080/wasm_pkg_ecdsa_wasm_js.index.js:480:19
@http://localhost:8080/ab5894b4f045b988426e.wasm:wasm-function[491]:0xc98f4
@http://localhost:8080/ab5894b4f045b988426e.wasm:wasm-function[1290]:0xe91ca
@http://localhost:8080/ab5894b4f045b988426e.wasm:wasm-function[422]:0xc1734
@http://localhost:8080/ab5894b4f045b988426e.wasm:wasm-function[882]:0xe3d01
@http://localhost:8080/ab5894b4f045b988426e.wasm:wasm-function[1052]:0xe799a
@http://localhost:8080/ab5894b4f045b988426e.wasm:wasm-function[1080]:0xe7f26
@http://localhost:8080/ab5894b4f045b988426e.wasm:wasm-function[898]:0xe45c3
@http://localhost:8080/ab5894b4f045b988426e.wasm:wasm-function[51]:0x2fb47
signRound2@http://localhost:8080/wasm_pkg_ecdsa_wasm_js.index.js:175:20
callback@http://localhost:8080/vendors-node_modules_comlink_dist_esm_comlink_mjs.index.js:115:48

Delete message proof is failing

The success message is shown but the message proof is not being deleted and still exists in the snap state.

React error during signing (running test.sh)

console.error:  client1 The above error occurred in the <Sign> component:

    at Sign (http://localhost:8080/index.js:86506:70)
    at Routes (http://localhost:8080/index.js:73787:5)
    at WorkerProvider (http://localhost:8080/index.js:87725:111)
    at div
    at App (http://localhost:8080/index.js:85472:72)
    at WebSocketProvider (http://localhost:8080/index.js:85412:117)
    at Router (http://localhost:8080/index.js:73721:15)
    at HashRouter (http://localhost:8080/index.js:73243:5)
    at Provider (http://localhost:8080/index.js:71131:20)

Consider adding an error boundary to your tree to customize error handling behavior.
Visit https://reactjs.org/link/error-boundaries to learn more about error boundaries.
unhandled error: client1 Cannot read properties of null (reading 'label')
unhandled error: client3 Cannot read properties of null (reading 'label')
unhandled error: client2 Cannot read properties of null (reading 'label')
console.info:  client1 [webpack-dev-server] Hot Module Replacement enabled.
console.error:  client3 The above error occurred in the <Sign> component:

    at Sign (http://localhost:8080/index.js:86506:70)
    at Routes (http://localhost:8080/index.js:73787:5)
    at WorkerProvider (http://localhost:8080/index.js:87725:111)
    at div
    at App (http://localhost:8080/index.js:85472:72)
    at WebSocketProvider (http://localhost:8080/index.js:85412:117)
    at Router (http://localhost:8080/index.js:73721:15)
    at HashRouter (http://localhost:8080/index.js:73243:5)
    at Provider (http://localhost:8080/index.js:71131:20)

Consider adding an error boundary to your tree to customize error handling behavior.
Visit https://reactjs.org/link/error-boundaries to learn more about error boundaries.
unhandled error: client3 Cannot read properties of null (reading 'label')
console.error:  client2 The above error occurred in the <Sign> component:

    at Sign (http://localhost:8080/index.js:86506:70)
    at Routes (http://localhost:8080/index.js:73787:5)
    at WorkerProvider (http://localhost:8080/index.js:87725:111)
    at div
    at App (http://localhost:8080/index.js:85472:72)
    at WebSocketProvider (http://localhost:8080/index.js:85412:117)
    at Router (http://localhost:8080/index.js:73721:15)
    at HashRouter (http://localhost:8080/index.js:73243:5)
    at Provider (http://localhost:8080/index.js:71131:20)

Consider adding an error boundary to your tree to customize error handling behavior.
Visit https://reactjs.org/link/error-boundaries to learn more about error boundaries.
unhandled error: client2 Cannot read properties of null (reading 'label')
console.info:  client3 [webpack-dev-server] Hot Module Replacement enabled.
console.info:  client2 [webpack-dev-server] Hot Module Replacement enabled.

Public address computation is non-deterministic

Sometimes this error is thrown.

Fix WASM tests

When these were run outside the wasm module in common they worked ok, but in the context of the wasm module this error is generated running wasm-pack test --node. If the tests are run in the browser (wasm-pack test --firefox) then there is an error with Crypto.getRandomValues().

Error: executing `wasm-bindgen` over the wasm file

Caused by:
    0: failed to generate bindings for import of `__wbindgen_placeholder__::__wbindgen_module`
    1: `wasm_bindgen::module` is currently only supported with `--target no-modules` and `--target web`
error: test failed, to rerun pass '--test aes'
Error: Running Wasm tests with wasm-bindgen-test failed
Caused by: failed to execute `cargo test`: exited with exit status: 1
  full command: "cargo" "test" "--target" "wasm32-unknown-unknown"

This error is due to requiring the --target web option for rayon support.

Production ready server code

Handle all error conditions
Support tracing library
Handle over subscription (#24)
Verify group parameters (parties >= 2 && threshold > 0)
Switch structopt to clap:3 (with macros feature)
Fix bug #49

Verify session identifiers

See: https://github.com/binance-chain/tss-lib#how-to-use-this-securely

Fix sessionMessage listener leak when signing multiple times

Currently we are not removing this listener before creating a new sink.

Keygen panic

wasm_pkg_ecdsa_wasm_js.index.js:362 panicked at 'called `Result::unwrap()` on an `Err` value: HandleMessage(MsgOverwrite)', src/gg2020/keygen.rs:37:36

Stack:

Error
    at imports.wbg.__wbg_new_693216e109162396 (http://localhost:8080/wasm_pkg_ecdsa_wasm_js.index.js:350:19)
    at http://localhost:8080/4f8c011425f1d30d7c1b.wasm:wasm-function[833]:0xb907c
    at http://localhost:8080/4f8c011425f1d30d7c1b.wasm:wasm-function[233]:0x8596e
    at http://localhost:8080/4f8c011425f1d30d7c1b.wasm:wasm-function[614]:0xb3deb
    at http://localhost:8080/4f8c011425f1d30d7c1b.wasm:wasm-function[642]:0xb46ab
    at http://localhost:8080/4f8c011425f1d30d7c1b.wasm:wasm-function[482]:0xaac70
    at http://localhost:8080/4f8c011425f1d30d7c1b.wasm:wasm-function[261]:0x9328c
    at Object.keygenHandleIncoming (http://localhost:8080/wasm_pkg_ecdsa_wasm_js.index.js:190:10)
    at callback (http://localhost:8080/vendors-node_modules_comlink_dist_esm_comlink_mjs.index.js:115:48)


imports.wbg.__wbg_error_09919627ac0992f5 @ wasm_pkg_ecdsa_wasm_js.index.js:362
$func833 @ 4f8c011425f1d30d7c1b.wasm:0xb918d
$func233 @ 4f8c011425f1d30d7c1b.wasm:0x8596e
$func614 @ 4f8c011425f1d30d7c1b.wasm:0xb3deb
$func642 @ 4f8c011425f1d30d7c1b.wasm:0xb46ab
$func482 @ 4f8c011425f1d30d7c1b.wasm:0xaac70
$keygenHandleIncoming @ 4f8c011425f1d30d7c1b.wasm:0x9328c
keygenHandleIncoming @ wasm_pkg_ecdsa_wasm_js.index.js:190
callback @ vendors-node_modules_comlink_dist_esm_comlink_mjs.index.js:115
index.js:91498 Uncaught (in promise) RuntimeError: unreachable
    at 4f8c011425f1d30d7c1b.wasm
    at 4f8c011425f1d30d7c1b.wasm
    at 4f8c011425f1d30d7c1b.wasm
    at 4f8c011425f1d30d7c1b.wasm
    at 4f8c011425f1d30d7c1b.wasm
    at 4f8c011425f1d30d7c1b.wasm
    at Object.keygenHandleIncoming (wasm_pkg_ecdsa_wasm_js.index.js:190:10)
    at callback (vendors-node_modules_comlink_dist_esm_comlink_mjs.index.js:115:48)

The ecrecover function sometimes fails

Uncaught (in promise) Error: Public key could not be recover
    ecdsaRecover http://localhost:8080/index.js:80234
    ecrecover http://localhost:8080/index.js:30708
    getPublicKey http://localhost:8080/index.js:85499
    getPublicAddress http://localhost:8080/index.js:85502
    getPublicAddressString http://localhost:8080/index.js:85505
    sign http://localhost:8080/index.js:86232
    step http://localhost:8080/index.js:86208
    verb http://localhost:8080/index.js:86189
    fulfilled http://localhost:8080/index.js:86180
    promise callback*step http://localhost:8080/index.js:86182
    __awaiter http://localhost:8080/index.js:86183
    __awaiter http://localhost:8080/index.js:86179
    sign http://localhost:8080/index.js:86217
    componentDidMount http://localhost:8080/index.js:85799
    step http://localhost:8080/index.js:85701
    verb http://localhost:8080/index.js:85682
    __awaiter http://localhost:8080/index.js:85676
    __awaiter http://localhost:8080/index.js:85672
    componentDidMount http://localhost:8080/index.js:85788
    emit http://localhost:8080/index.js:31068
    WebSocketClient http://localhost:8080/index.js:85352
    step http://localhost:8080/index.js:85296
    verb http://localhost:8080/index.js:85277
    __awaiter http://localhost:8080/index.js:85271
    __awaiter http://localhost:8080/index.js:85267
    onmessage http://localhost:8080/index.js:85333
    connect http://localhost:8080/index.js:85333
    tsx http://localhost:8080/index.js:85394
    __webpack_require__ http://localhost:8080/index.js:91726
    fn http://localhost:8080/index.js:91951
    tsx http://localhost:8080/index.js:85527
    __webpack_require__ http://localhost:8080/index.js:91726
    fn http://localhost:8080/index.js:91951
    tsx http://localhost:8080/index.js:85418
    __webpack_require__ http://localhost:8080/index.js:91726
    <anonymous> http://localhost:8080/index.js:92808
    <anonymous> http://localhost:8080/index.js:92810
index.js:80234:17

Implement key rotation

Null party signup during keygen (demo)

Just came across this running the test suite using test.sh:

console.info:  client1 transition 0 to KEYGEN_ROUND_1
console.error:  client3 panicked at 'called `Result::unwrap()` on an `Err` value: Error("invalid type: null, expected struct PartySignup", line: 1, column: 4)', src/gg2020/keygen.rs:51:50

Stack:

Error
    at imports.wbg.__wbg_new_693216e109162396 (http://localhost:8080/wasm_pkg_ecdsa_wasm_js.index.js:350:19)
    at http://localhost:8080/6f05be4d15933ff7c6d2.wasm:wasm-function[831]:0xb9e3f
    at http://localhost:8080/6f05be4d15933ff7c6d2.wasm:wasm-function[233]:0x89369
    at http://localhost:8080/6f05be4d15933ff7c6d2.wasm:wasm-function[612]:0xb4bae
    at http://localhost:8080/6f05be4d15933ff7c6d2.wasm:wasm-function[640]:0xb546e
    at http://localhost:8080/6f05be4d15933ff7c6d2.wasm:wasm-function[481]:0xaba77
    at http://localhost:8080/6f05be4d15933ff7c6d2.wasm:wasm-function[212]:0x84a36
    at Object.keygenInit (http://localhost:8080/wasm_pkg_ecdsa_wasm_js.index.js:183:10)
    at callback (http://localhost:8080/vendors-node_modules_comlink_dist_esm_comlink_mjs.index.js:115:48)


console.info:  client2 transition 0 to KEYGEN_ROUND_1
unhandled error: client3 unreachable

Support pre-signatures

So that users can generate pre-signatures ahead of time and reduce the time spent during the signing phase when signing a message or transaction.

Signing does not complete (out of sync)

This is the logs when the test spec hangs:

console.info:  client1 transition to KEYGEN_ROUND_1
console.info:  client2 transition to KEYGEN_ROUND_1
console.info:  client3 transition to KEYGEN_ROUND_1
console.info:  client1 transition from KEYGEN_ROUND_1 to KEYGEN_ROUND_2
console.info:  client2 transition from KEYGEN_ROUND_1 to KEYGEN_ROUND_2
console.info:  client3 transition from KEYGEN_ROUND_1 to KEYGEN_ROUND_2
console.info:  client1 transition from KEYGEN_ROUND_2 to KEYGEN_ROUND_3
console.info:  client2 transition from KEYGEN_ROUND_2 to KEYGEN_ROUND_3
console.info:  client3 transition from KEYGEN_ROUND_2 to KEYGEN_ROUND_3
console.info:  client1 transition from KEYGEN_ROUND_3 to KEYGEN_ROUND_4
console.info:  client2 transition from KEYGEN_ROUND_3 to KEYGEN_ROUND_4
console.info:  client3 transition from KEYGEN_ROUND_3 to KEYGEN_ROUND_4
  ✘  tests/keygen-sign.spec.mjs:25:1 › create key shares and sign message (30s)
console.info:  client2 transition from KEYGEN_ROUND_4 to KEYGEN_FINALIZE
console.info:  client3 transition from KEYGEN_ROUND_4 to KEYGEN_FINALIZE
console.info:  client1 transition to SIGN_ROUND_0
console.info:  client2 transition to SIGN_ROUND_0
console.info:  client1 transition from SIGN_ROUND_0 to SIGN_PARTICIPANTS
console.info:  client2 transition from SIGN_ROUND_0 to SIGN_PARTICIPANTS
console.info:  client2 transition to SIGN_ROUND_1
console.info:  client1 transition to SIGN_ROUND_1
console.info:  client2 transition from SIGN_ROUND_1 to SIGN_ROUND_2
console.info:  client1 transition from SIGN_ROUND_1 to SIGN_ROUND_2
console.info:  client1 transition from SIGN_ROUND_2 to SIGN_ROUND_3
console.info:  client2 transition from SIGN_ROUND_2 to SIGN_ROUND_3
console.info:  client1 transition from SIGN_ROUND_3 to SIGN_ROUND_4
console.info:  client2 transition from SIGN_ROUND_3 to SIGN_ROUND_4
console.info:  client1 transition from SIGN_ROUND_4 to SIGN_ROUND_5
console.info:  client2 transition from SIGN_ROUND_4 to SIGN_ROUND_5
console.info:  client2 transition from SIGN_ROUND_5 to SIGN_ROUND_6
console.info:  client1 transition from SIGN_ROUND_5 to SIGN_ROUND_6
console.info:  client1 transition from SIGN_ROUND_6 to SIGN_OFFLINE_STAGE
console.info:  client1 transition to SIGN_ROUND_8
console.info:  client2 transition from SIGN_ROUND_6 to SIGN_OFFLINE_STAGE
console.info:  client2 transition to SIGN_ROUND_8
console.info:  client1 transition from SIGN_ROUND_8 to SIGN_PARTIAL

Notice that client1 is proceeding to the sign partial stage before client2 has finished the offline stage.

These are the logs when it completes successfully:

console.info:  client2 transition to KEYGEN_ROUND_1
console.info:  client1 transition to KEYGEN_ROUND_1
console.info:  client3 transition to KEYGEN_ROUND_1
console.info:  client2 transition from KEYGEN_ROUND_1 to KEYGEN_ROUND_2
console.info:  client1 transition from KEYGEN_ROUND_1 to KEYGEN_ROUND_2
console.info:  client3 transition from KEYGEN_ROUND_1 to KEYGEN_ROUND_2
console.info:  client2 transition from KEYGEN_ROUND_2 to KEYGEN_ROUND_3
console.info:  client1 transition from KEYGEN_ROUND_2 to KEYGEN_ROUND_3
console.info:  client3 transition from KEYGEN_ROUND_2 to KEYGEN_ROUND_3
console.info:  client2 transition from KEYGEN_ROUND_3 to KEYGEN_ROUND_4
console.info:  client1 transition from KEYGEN_ROUND_3 to KEYGEN_ROUND_4
console.info:  client3 transition from KEYGEN_ROUND_3 to KEYGEN_ROUND_4
console.info:  client1 transition from KEYGEN_ROUND_4 to KEYGEN_FINALIZE
  ✓  tests/keygen-sign.spec.mjs:25:1 › create key shares and sign message (6s)
console.info:  client3 transition from KEYGEN_ROUND_4 to KEYGEN_FINALIZE
console.info:  client1 transition to SIGN_ROUND_0
console.info:  client2 transition to SIGN_ROUND_0
console.info:  client1 transition from SIGN_ROUND_0 to SIGN_PARTICIPANTS
console.info:  client1 transition to SIGN_ROUND_1
console.info:  client2 transition from SIGN_ROUND_0 to SIGN_PARTICIPANTS
console.info:  client2 transition to SIGN_ROUND_1
console.info:  client1 transition from SIGN_ROUND_1 to SIGN_ROUND_2
console.info:  client2 transition from SIGN_ROUND_1 to SIGN_ROUND_2
console.info:  client2 transition from SIGN_ROUND_2 to SIGN_ROUND_3
console.info:  client1 transition from SIGN_ROUND_2 to SIGN_ROUND_3
console.info:  client2 transition from SIGN_ROUND_3 to SIGN_ROUND_4
console.info:  client1 transition from SIGN_ROUND_3 to SIGN_ROUND_4
console.info:  client1 transition from SIGN_ROUND_4 to SIGN_ROUND_5
console.info:  client2 transition from SIGN_ROUND_4 to SIGN_ROUND_5
console.info:  client1 transition from SIGN_ROUND_5 to SIGN_ROUND_6
console.info:  client2 transition from SIGN_ROUND_5 to SIGN_ROUND_6
console.info:  client1 transition from SIGN_ROUND_6 to SIGN_OFFLINE_STAGE
console.info:  client2 transition from SIGN_ROUND_6 to SIGN_OFFLINE_STAGE
console.info:  client1 transition to SIGN_ROUND_8
console.info:  client2 transition to SIGN_ROUND_8
console.info:  client2 transition from SIGN_ROUND_8 to SIGN_PARTIAL
console.info:  client1 transition from SIGN_ROUND_8 to SIGN_PARTIAL

Installing `wasm-pack` throws an error saying "The package requires the Cargo feature called `edition2021`, but that feature is not stablized in this version of Cargo (1.56.0-nightly (cc17afbb0 2021-08-02))."

Steps to reproduce

Fresh clone the repository.
Go into the repository directory and run cargo install --version 0.10.2 wasm-pack.
The command throws the error described in the title.

Rust dependencies

➜  demo-gg20-wasm git:(wallet) ✗ rustup --version

rustup 1.25.1 (bb60b1e89 2022-07-12)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.56.0-nightly (ccffcafd5 2021-08-11)`

Other relevant information

Host OS: M1 Mac Monterrey
VM OS: ARM64 Ubuntu 22.04 (VM in Parallels Desktop)

Notify non-participants in the group when a message is signed

So that they can update the proposals list rendering and keep everything in sync.