Clients suspend partner shares for good on refusals that may be temporary #1283

Both clients suspend a partner share on a lookup refusal they read as a verdict about the recipient, and a suspended share stays suspended until the owner revokes it or shares again. Two refusals come from something temporary on the partner or admin side, so a routine action pauses every share to that partner for good, one item at a time, as each is next saved. Both cases share the same client fallback: stop the save instead of suspending, as for an unreachable partner. This issue merges #1284, whose full text is kept below. Related: #1262 (resume a suspended partner share).

• A partner's root renewal answers untrusted_root, with no way to re-pin (this issue).
• Turning outbound sharing off for a partner answers not_a_partner (Turning outbound sharing off for a partner suspends every share to it on the next save #1284).

A partner's root renewal suspends every share to it, with no way to re-pin

Problem

A partner's root CA is pinned once, when the partnership is added: FederationPartnerService::add stores rootFingerprint (:219), and nothing updates it later. When the partner renews its root (CACertificateController::renewRoot), its chain no longer leads to the pinned fingerprint, so the browser's certificate check answers untrusted_root.

Both clients treat untrusted_root as a verdict about the recipient and suspend the share in the save (web app src/services/shareSave.js, extension browser-extension/src/vault/share-save.ts). A suspended share stays suspended until the owner revokes it or shares again, so one routine renewal on the partner's side pauses every share to that partner, for good, on the next save of each item.

Proposed solution

• A way to re-pin a partner's root: an admin action that previews the new fingerprint and confirms it, as adding a partner does.
• Optionally, partners announce a renewal (the old root signing the new one), so the server can offer the re-pin itself.
• Until then, clients could tell an untrusted_root on a known partner apart from other refusals and stop the save instead of suspending, like an unreachable partner.

Anything else?

Found in the rereview of the browser extension's move to share-save (ext-share-sync, #1249).

Merged from #1284: Turning outbound sharing off for a partner suspends every share to it on the next save

Problem

Turning off outbound sharing for a partner makes FederationPartnerService::outboundPartnerForRemote return null (:319), so the partner certificate lookup answers 403 not_a_partner. Both clients read not_a_partner as "no longer a partner" and suspend the share in the save (web app src/services/shareSave.js PARTNER_GONE, extension browser-extension/src/vault/share-save.ts).

A suspended share stays suspended until the owner revokes it or shares again. So a toggle an admin may mean as temporary ends every share to that partner for good, one item at a time, as each is next saved.

Proposed solution

• Answer a partner whose outbound sharing is off with its own reason, such as outbound_disabled, and have clients stop the save there instead of suspending, as they do for an unreachable partner.
• Or have the toggle itself say, before an admin confirms, that existing shares to that partner are paused on their next save.

Anything else?

Found in the rereview of the browser extension's move to share-save (ext-share-sync, #1249).