openvibers/openvibe.link Commits

Node: profile verify, and pairing checks a community robot profile against Bot's signature (#40)

OP OpenVibers committed 30 days ago · tag v0.6.0 · 0 files, +0 −0

The Node side of Bot's community robots (plan T15: profiles are "reviewed and signed before they run on anyone's Node"). Bot signs a community profile when an OpenVibe admin approves it (Bot server/submissions.js) and publishes its key. Until now nothing checked the signature.

**`internal/profilesig`**
- Canonical JSON exactly as Bot signs it:
  - keys sorted by UTF-16 code units, no whitespace;
  - strings escaped as `JSON.stringify` escapes them (U+2028 raw, control characters as `\u00xx`);
  - numbers as Bot wrote them (`1e+21`).
- Verification checks the key id (SHA-256 of the SPKI DER, first 16 hex digits), that the signature names that key, and Ed25519 over the canonical bytes.
- `Check` fetches the profile and the key from Bot. It can pin a key id, and can require that a profile Bot sent the Node is the catalogue's signed one.
- The test fixture was produced by Bot's own `canonicalJson` and `loadKey` with a fresh key. It has keys out of order, escapes, non-ASCII, U+2028, a control character and exponent-form numbers.

**CLI**
- `openvibe-node profile verify community.<name> [--server URL] [--key-id ID]` says whether the profile is the one that was reviewed and names its `mapping.plugin`. A failure exits 1 with "do not install its driver".
- `pair` (code or Network) runs the same check when the robot uses a community profile. A failure is a warning, not a refusal: the plugin is installed by hand.

**Docs:** README, and a "Community plugins" section in docs/plugins.md.

**Tests:** `internal/profilesig` (canonical form vs Bot's, tampering, wrong or swapped keys, pinning, unsigned, a different profile at pairing, unknown and built-in ids); `TestProfileVerify` (the CLI).

This commit has no diff to show.