Test: Add Better Test Harness

[sephynox]

Summary

The device returned an invalid Ed25519 public key from GET_PUBLIC_KEY, so Ed25519 addresses were wrong and signatures could not be verified against the network. This went unnoticed because no test checked device output against a reference implementation. This PR fixes the encoding and adds a round-trip suite that verifies every supported algorithm against both the Rust node (node-rs) and the TypeScript client (keetanet-client), plus CI updates needed to build against Ledger's current toolchain images.

Related Issues

• Fix: Address Generation Issues #21

Changes Made

• Ed25519 GET_PUBLIC_KEY now returns the compressed RFC 8032 key
• Ed25519 Keeta addresses derive from the corrected key
• Round-trip tests verify all three algorithms against both nodes
• Rust and TS verifier fixtures replace the old JS block fixture
• Ledger SDK crates updated for the C SDK v26.5.0 build container
• CI pins the verifier build to stable Rust and locks cargo-audit

Breaking Changes

Ed25519 public keys and addresses reported by the device change. Any address derived from a previous build's Ed25519 output must be re-derived. secp256k1 and secp256r1 outputs are unchanged.

---

Note

High Risk
Ed25519 public keys and Keeta addresses change for integrators, and signing/crypto paths are validated against new reference verifiers and a moving node-rs branch—high impact on wallet compatibility and signature correctness.

Overview
Fixes Ed25519 GET_PUBLIC_KEY / address derivation by compressing the Ledger SDK’s uncompressed point with cx_edwards_compress_point_no_throw and exposing the RFC 8032 32-byte key—breaking prior Ed25519 addresses and pubkeys; secp256k1 and secp256r1 are unchanged.

Replaces the old JS block-builder fixture with round-trip functional tests that sign on-device (sign_message / sign_block for all three algorithms) and verify via new Rust (verify_signature_rs / node-rs) and TypeScript (verify_signature_ts / keetanet-client) CLIs. Shared pytest helpers (SET_REP_BLOCK, _stream_sign, sign_message) and CI steps build/cache the Rust verifier and install the TS fixture.

Dependency bumps include ledger_device_sdk / ledger_secure_sdk_sys, node-rs on feat/block, and minor CI/tooling tweaks (cargo +stable install cargo-audit, .gitignore target/).

^{Reviewed by Cursor Bugbot for commit 55d592f. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit abc08fc. Configure here.}

[xescure]

Great to have caught this now. I'm glad I test everything with small amounts first.

@sephynox Can you sanity check me on this as well? This seems like an invalid address (keeta_aaaa... prefix) and it's being used as the target value for the screen tests.

https://github.com/KeetaNetwork/ledger-device-application/blob/test/signing-algos/tests/snapshots/snapshots/nanox/test_sign_block_review/00004.png

It seems to be indicative of some kind of double-type-prefix display-only issue for addresses parsed from blocks.

[sephynox]

Great to have caught this now. I'm glad I test everything with small amounts first.

@sephynox Can you sanity check me on this as well? This seems like an invalid address (keeta_aaaa... prefix) and it's being used as the target value for the screen tests.

https://github.com/KeetaNetwork/ledger-device-application/blob/test/signing-algos/tests/snapshots/snapshots/nanox/test_sign_block_review/00004.png

It seems to be indicative of some kind of double-type-prefix display-only issue for addresses parsed from blocks.

Yes, I fixed this as well here: #21

[xescure]

Might be worth flagging that this entry in Cargo.toml

ledger-device-application/Cargo.toml

Line 39 in 55d592f

keetanetwork-block = { git = "https://github.com/KeetaNetwork/node-rs", branch = "feat/block", default-features = false }

has a branch tag, but this lockfile previously did not. The old lockfile was invalid and considered to be for a different entry because of the branch tag, so a new lockfile would resolve to the head of the branch. All this to say, there’s a chance this version bump was not intentional.

Could consider adding cargo metadata --locked as an explicit pipeline step to catch this in the future.

fyi @sephynox