Yawning Angel

> should clients provide additional pers strings? it might be more secure if used properly, but will people know (how) to use it? I like having an integrated way to...

> > Go: Use github.com/oasisprotocol/oasis-core/go/common/crypto/signature for Ed25519. > > [Isn't this already the case?](https://github.com/oasisprotocol/oasis-sdk/blob/main/client-sdk/go/crypto/signature/ed25519/ed25519.go) Yeah, just being thorough.

Looking over the JS/TS case, applying the retrofit to tweetnacl is non-trivial. I don't know of any JS/TS libraries that both provide what is required, that I have high confidence...

> can we still use tweetnacl to sign consistently with the rust and go libraries? Signing behavior is consistent across basically every Ed25519 implementation, yes.

There probably should be documentation somewhere that SDK developers will see concerning our Ed25519 verification semantics just so people don't try to do something exotic and end up surprised. All...

Wait, why did you close this? It is 100% possible to produce signatures that will pass validation with the js/ts code that will not anywhere else, because `ts-web/core/src/signature.ts` is flat...

Go and Rust have been done via https://github.com/oasisprotocol/oasis-sdk/pull/306

> we'll have to have an additional step to separate the public key types. but are we moving away from batch signature verification in general? Why would we be? It...

For posterity, this is a Debian + derivatives issue stemming from this patch: https://salsa.debian.org/debian/libedit/-/blob/master/debian/patches/update-soname.diff

``` $ patchelf --replace-needed libedit.so.2 libedit.so.0 libLLVM-14.so.1 ``` Alters the copy of LLVM shipped along side releases to look for the correctly named libedit, instead of the Debian stupidity.