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.