@openvtc/trust-tasks 0.26.26 → 0.26.28

package/CHANGELOG.md

@@ -11,6 +11,72 @@ The package versions over **its own API** — what a consumer compiles against
 not over `SPEC.md`. Below 1.0 a breaking change bumps the leading non-zero
 component.
 
+## 0.26.28 — 2026-10-21
+
+
+### Fixed
+
+- **voting**: Each trustee step on the board is the trustee's signed request (#853)
+
+The board recorded each step of the trustees' ceremony as its payload alone, so nothing on it
+  showed who took a step. A ballot box could enrol or deal in a trustee's name — a polynomial of its
+  own choosing, with matching shares sealed to that trustee's transport key — and every check the
+  community, the trustees and certification run would pass while the ballot box held the election
+  key, able to open sealed ballots before close. The defence was only that the ballot box runs
+  honestly, which VTI-VOT-062 does not let a deployment assume.
+
+  - A new board entry, `trusteeStep` (appended), carries the trustee's `voting/trustees/enrol`,
+    `deal`, `confirm` or `justify` request exactly as the ballot box received it, proof included.
+    The `transportKey`, `dealing`, `confirmation` and `justification` kinds are no longer appended,
+    and a consumer refuses a board holding one.
+  - CONVENTIONS §9.6: whoever replays the ceremony takes a step only when its type, community and
+    election are right, its issuer is the trustee the manifest names at the payload's index, and
+    its proof is the issuer's. A `partials` entry needs no signature: its Chaum–Pedersen proofs
+    already tie it to the trustee's share. `voting/trustees/status` is never evidence of who took a
+    step.
+  - `vtc/elections/show` item 6: the community forms the key itself by replaying the ceremony from
+    the board (open to it on any board), never from `voting/trustees/status`.
+  - `vtc/elections/certify` item 8 states the encrypted levels' recount: ceremony, casts and
+    partials, from the board alone.
+
+## 0.26.27 — 2026-10-21
+
+
+### Added
+
+- **vtc/config**: Did-hosting/list 0.1 — the hosting servers the community's VTA can publish its identities through (#849)
+
+A community's administrator chooses where the identities it mints (its groups'
+  and its own rooms') are published. The community either serves each `did:webvh`
+  log itself, or has its VTA publish it on a hosting server registered there.
+  Without a list of those servers the choice is typed blind.
+
+  - vtc/config/did-hosting/list/0.1: for holders of `vtc.config.admin`. The
+    community asks its own VTA (`vta/webvh/servers/list`), as itself, over the
+    link it keeps to it. It answers with each server's `id`, `did` and `label`,
+    and nothing else of the VTA's record. A server whose id the configuration
+    could not name is left out.
+  - Codes: noKeyHolder (no VTA link), keyHolderUnavailable (no answer,
+    retryable), keyHolderRefused (the VTA's own code and message in `details`).
+
+
+
+### Fixed
+
+- **voting**: Encrypted elections on a private board — trustees read their ceremony, voters get the key from vtc/elections/show (#852)
+
+On a private board the ballot box answered voting/trustees/status only to the community and
+  its auditors, so no trustee could take its next step (transport keys, dealings and targets are
+  read from status) and no voter could obtain the election key: a sealed or tallied-encrypted
+  election on a private board could not run.
+
+  - CONVENTIONS §4 gains the rows the trustee tasks were missing; voting/trustees/status
+    answers every trustee the manifest names on any board. Nothing the ceremony publishes is
+    secret (§9.6, "Who reads the ceremony").
+  - vtc/elections/show carries electionKey (optional, appended) once formed, read from the
+    ballot box and refused unless the qualified dealings in the same answer form it. A voter
+    gets it from the community it already asks for its ticket.
+
 ## 0.26.26 — 2026-10-20
 
 

package/dist/_shared/components.d.ts

@@ -388,7 +388,7 @@ export type BlobRef = DigestMultibase;
 /**
  * One leaf of a board. A leaf's hash is the RFC 9162 leaf hash of the JCS canonicalization of this object. Entries carry no time of arrival: the order is the board's, and a timestamp would hand anyone who reads the board the timing the registrar's log would need to pair a ticket with its cast.
  */
-export type BoardEntry = CastEntry | ReplacementEntry | LifecycleEntry | ResultEntry | EncryptedCastEntry | TransportKeyEntry | DealingEntry | ConfirmationEntry | JustificationEntry | ElectionKeyEntry | PartialDecryptionsEntry | UnsealedEntry | SpoiledEntry;
+export type BoardEntry = CastEntry | ReplacementEntry | LifecycleEntry | ResultEntry | EncryptedCastEntry | TransportKeyEntry | DealingEntry | ConfirmationEntry | JustificationEntry | ElectionKeyEntry | PartialDecryptionsEntry | UnsealedEntry | SpoiledEntry | TrusteeStepEntry;
 /**
  * `public`: anyone reads the board. `private`: the community, the auditors the manifest names and, for one cast's inclusion, the holder of its receipt (VTI-VOT-052).
  */
@@ -4574,14 +4574,23 @@ export interface EncryptedCastEntry {
     kind: "encryptedCast";
     cast: EncryptedCast;
 }
+/**
+ * Not appended: each enrolment, dealing, confirmation and justification is a `trusteeStep` entry carrying the trustee's signed request (CONVENTIONS §9.6). A consumer MUST refuse a board holding this kind.
+ */
 export interface TransportKeyEntry {
     kind: "transportKey";
     transportKey: TransportKey;
 }
+/**
+ * Not appended: each enrolment, dealing, confirmation and justification is a `trusteeStep` entry carrying the trustee's signed request (CONVENTIONS §9.6). A consumer MUST refuse a board holding this kind.
+ */
 export interface DealingEntry {
     kind: "dealing";
     dealing: Dealing;
 }
+/**
+ * Not appended: each enrolment, dealing, confirmation and justification is a `trusteeStep` entry carrying the trustee's signed request (CONVENTIONS §9.6). A consumer MUST refuse a board holding this kind.
+ */
 export interface ConfirmationEntry {
     kind: "confirmation";
     trustee: TrusteeIndex;
@@ -4590,6 +4599,9 @@ export interface ConfirmationEntry {
      */
     complaints: TrusteeIndex[];
 }
+/**
+ * Not appended: each enrolment, dealing, confirmation and justification is a `trusteeStep` entry carrying the trustee's signed request (CONVENTIONS §9.6). A consumer MUST refuse a board holding this kind.
+ */
 export interface JustificationEntry {
     kind: "justification";
     dealer: TrusteeIndex;
@@ -4621,6 +4633,13 @@ export interface SpoiledEntry {
     kind: "spoiled";
     leafIndex: number;
 }
+/**
+ * One step of the trustees' ceremony — an enrolment, a dealing, a confirmation or a justification — as the trustee's own signed request, so that anyone reading the board can tell who took it (CONVENTIONS §9.6).
+ */
+export interface TrusteeStepEntry {
+    kind: "trusteeStep";
+    request: SignedRequest;
+}
 /**
  * A board's tree head (RFC 9162 §2.1). A head is signed by being carried in a document the ballot box signs; whoever keeps a head keeps that whole document.
  */
@@ -9998,6 +10017,11 @@ export interface SigmaProof {
     c: GroupScalar;
     z: GroupScalar;
 }
+/**
+ * A whole Trust Task request document — `id`, `type`, `issuer`, `payload` and every other member, `proof` included — exactly as the ballot box received it, never re-serialised: its proof is taken over its members, and a re-serialised copy does not reliably reproduce them. Typed as an open object so every member survives; CONVENTIONS §9.6 gives the checks that make it a trustee's step.
+ */
+export interface SignedRequest {
+}
 /**
  * One signing-key delegation, as its holder sees it. A delegation confers nothing of its own: it names an identity that already holds whatever standing it holds, and a document signed by the key is authorized by that identity's standing read at execution time.
  */