errors

errors

Typed varlink errors the hub can raise from Verdict.

Subclasses of asyncvarlink.TypedVarlinkErrorReply — the hub raises one of these on the four refusal paths, and clients pattern- match on the subclass instead of stringly-matching a message. All four share the org.terok.Clearance1 interface namespace.

UnknownRequest

Bases: TypedVarlinkErrorReply

Verdict referenced a request_id the hub didn't emit.

Fail-closed for the attacker's dream-up case: a peer connecting to the clearance socket synthesises a verdict for a block that was never broadcast. No binding, no action.

Parameters

Typed payload for the varlink error reply.

request_id instance-attribute

VerdictTupleMismatch

Bases: TypedVarlinkErrorReply

(container, dest) don't match the hub's pending record.

Cheap defence against replay attackers who sniffed a request_id on this connection but try to apply a verdict against a different destination. expected_* are what the hub recorded when it emitted connection_blocked; got_* are what the call carried.

Parameters

Typed payload for the varlink error reply.

expected_container instance-attribute

expected_dest instance-attribute

got_container instance-attribute

got_dest instance-attribute

InvalidAction

Bases: TypedVarlinkErrorReply

action wasn't one of allow / deny.

Parameters

Typed payload for the varlink error reply.

action instance-attribute

ShieldCliFailed

Bases: TypedVarlinkErrorReply

terok-shield allow|deny exited non-zero or timed out.

Clients render this as the red "Allow failed" / "Deny failed" popup variant: the user's click reached the hub but the firewall didn't accept it, so the notification's premise ("you decided X") is misleading. stderr is whatever terok-shield wrote, truncated to a reasonable length by the hub.

Parameters

Typed payload for the varlink error reply.

action instance-attribute

stderr instance-attribute