Key verification available

Verifies

Requires an AI engine: Users of the end-to-end messaging feature can verify each other's keys through the interface and are warned when a contact's identity key changes, without the application trusting the new key automatically.

Inputs

Non-test code files of the checkout (JavaScript, TypeScript, Python, PHP). Verification signals: safety number, fingerprint, verification code, QR, SAS, emoji verification, cross-signing, verified flags; key-change signals: identity key changed, untrusted identity, key mismatch, trust-on-first-use handling, re-verification; user-facing signals: screens, routes, components, dialogs, alerts. The files carrying the signals (at most 24) are sent together in one assessment call to the chosen engine through the platform ai service; at most 160000 estimated tokens. Paths listed in excludes (test, spec and tmp files, __tests__, __mocks__, fixtures, test, tests and audit-scripts folders) are never analysed. Every model call (rubric, repository context and files) stays under 120000 characters; a candidate set that does not fit is sent in parts, each part bounded by what the chosen engine serves in one call (the engine publishes that budget; a call is never filled up to the transport cap).

Decision rule

Not applicable without a messaging feature or without an end-to-end protocol. FAIL (HIGH) when no verification signal exists anywhere, or when no key-change signal exists anywhere. Verification vocabulary present only in non-user-facing code is MEDIUM (blocks in this Extended suite). The model must establish with confidence of at least 0.8 that verification is reachable by the user and that a key change is surfaced without automatic trust: an unsatisfied or undecided assessment is a FAIL, a HIGH finding is a FAIL, an unparseable answer is a FAIL. PASS only with a satisfied assessment and nothing blocking. When the candidate set goes in parts, a HIGH finding in any part is a FAIL and the assessment is unsatisfied when any part says so, satisfied only when a part establishes it and none denies it. A messaging feature exists only with a message or conversation model, a chat transport, a messaging protocol library, a chat UI or end-to-end keys in a messaging folder somewhere in the checkout: messaging vocabulary alone is not-applicable with the reason (1.0.2). Without an AI engine the check is not executed (requires an AI engine).

Type

ai-assisted · engine chosen by the organisation · medium

1.0.4: `assess` mode cuts the candidate set to what the chosen ENGINE serves in ONE call (`ctx.ai.maxInputChars`, published by the engine per its catalogue budget; `ENGINE_CALL_MAX_CHARS` = 32 000 when an older sandbox does not publish it), instead of filling the call up to the TRANSPORT cap of the proxy (`spec.promptMaxChars`, unchanged at 120 000). On a 1 319-file checkout the old packing produced single prompts of 17 672 / 26 709 / 29 351 tokens and the platform GPU answered "CUDA out of memory": the check ended in `error`. Every call of the same run under ~24 000 characters was answered normally. The part aggregation of 1.0.1 is unchanged: a HIGH in any part is a FAIL, an unsatisfied part is a FAIL, undecided never passes. (1.0.3: requires an AI engine (spec.requiresEngine: true): the check needs judgement and is executed only when the organisation provides an engine; the core catalogue runs without one. (1.0.2: applies only to a real messaging feature: a message or conversation model, a chat transport (socket, channel or pub/sub events of a conversation), a messaging protocol library (Signal, MLS, Olm/Megolm, XMPP) or a chat UI; messaging vocabulary alone (an error message pushed to a queue, a notification channel, a case signal route) is not-applicable with the reason; never analyses temporary files (*.tmp.*; spec.excludes follows AUDITOR_ANALYSIS_EXCLUDES). (1.0.1: never analyses test, spec, fixture and mock paths nor the auditor's own scripts (spec.excludes = AUDITOR_ANALYSIS_EXCLUDES); a fixture-looking secret (sk_test_, example, dummy) in real code is LOW, informative; every model call stays under the engine prompt cap (spec.promptMaxChars = AUDITOR_AI_PROMPT_MAX_CHARS): assess mode sends the candidate set in parts and aggregates the verdicts (a HIGH in any part is a FAIL, an unsatisfied part is a FAIL).)))

The full script is disclosed on request in a read-only viewer (never published on GitHub); the attestation binds to this exact hash.