fedify-dev/fedify

Background MockFederation.setActorDispatcher() in packages/testing/src/mock.ts returns an object whose setKeyPairsDispatcher(), mapHandle(), mapAlias(), and authorize() return the MockFederation itself instead of the setters object. Other mock setters, such as those returned by setObjectDispatcher() and the collection dispatchers, return the federation from authorize() in the same way. So code that chains setters, as the Federation API allows, fails against the mock: federation .setActorDispatcher("/users/{identifier}", dispatcher) .setKeyPairsDispatcher(keyPairsDispatcher) .mapHandle(mapper); // TypeError: mapHandle is not a function mapPortableActorId(), added in #840, already returns the setters object, as does the real implementation. The actor setters also lack mapActorAlias(). Proposed work Make every setters object that the mock returns return itself from its methods, and add the missing mapActorAlias(). Tests chaining every actor setter in any order; chaining authoriz

Why outbox-listener-delivery-required and outbox-listener-delivery-not-awaited both decide which code in an outbox listener can run through collectReachableStatements() in packages/lint/src/lib/reachability.ts. The function already skips an if branch whose test is statically false, but two loop forms are handled inaccurately. CodeRabbit pointed both out while reviewing #1067, where the function was moved into the shared module unchanged; the behavior dates back to #1050. First, a loop whose test is statically false still has its body and update treated as reachable: while (false) { ctx.sendActivity(sender, inbox, activity); } for (;false;) { ctx.sendActivity(sender, inbox, activity); } for (let i = 0; false; ctx.sendActivity(sender, inbox, activity)) {} None of these ever delivers, yet outbox-listener-delivery-required accepts all three listeners, and outbox-listener-delivery-not-awaited reports the unawaited call in the first two although it never runs. A do…while (false) body ru

Why outbox-listener-delivery-required (@fedify/lint) skips a delivery call behind if (false) but counts one inside while (false). The two are equally dead, and isStaticallyFalsy(), the helper that decides the first case, already sits in the same file. federation .setOutboxListeners("/users/{identifier}/outbox") .on(Activity, async (ctx, activity) => { while (false) { await ctx.sendActivity({ identifier: ctx.identifier }, inbox, activity); } console.log(ctx.identifier, activity.id?.href); }); This listener never federates the posted activity, and the rule says nothing. It is a missed detection rather than a false report, so no valid code breaks today. The behavior predates the reachability rewrite in #1050 and is the same in every released version of the rule. Scope In collectReachableStatements(), skip the body of a WhileStatement or a ForStatement whose test is statically falsy. A ForStatement with no test loops forever, so prune only when a test is present

WorkersMessageQueue writes __fedify_ordering_key__ and __fedify_payload__ in enqueue() and enqueueMany(), then reads them back in processMessage(). The wrapper is a wire format with a queue in the middle, and nothing ties the two ends together. Every processMessage() test builds its input by hand: packages/cfworkers/test/mq.test.ts lines 248, 259, 268, 284, 313, 333, 357, and 380, and packages/cfworkers/src/mod.test.ts lines 331, 346, 381, and 389. The producer tests hard-code the same shape on their own side. Change both sides at once and the suite stays green. Add a round trip to packages/cfworkers/test/mq.test.ts. Enqueue a message, take the value that send() received, pass it to processMessage(), and check that the payload and the ordering key survive. Do the same for enqueueMany() with one item's body from the sendBatch() call, which also pins down that both producers agree on the shape. Use the vi.spyOn(env.Q1, …) pattern already in that file rather than adding a mock queu

When resolveFetchedKey in packages/fedify/src/sig/key.ts fetches the document at a keyId URL and parses it as a standalone CryptographicKey or Multikey, it does not check whether the object's id matches the requested URL: let key: T | null = null; if (object instanceof cls) key = object; else if (isActor(object)) { // …iterates keys and matches k.id?.href === keyId } The actor branch compares each candidate with k.id?.href === keyId before accepting it. The standalone branch skips that check. A document served at one URL can therefore declare a different id and still be cached under the requested URL. This came from a security report, but we closed the report because the mismatch does not provide a way to impersonate another actor. The verification path does not use the key document's id to establish the actor's identity. It checks the key's owner or controller against the activity's actor. The current behavior is nevertheless confusing: key.id may differ from the keyId used for th