Drop the official flag from a hidden attendee (#138)

[theobong]

Part of civfix/issue-tracker#138

What changed

On an event's member list, a person whose identity is hidden from you no longer carries the official CivFix check mark. Web and mobile.

Before you start

• Where: staging (civfix.dev and a staging mobile build) after the main push
• Sign in as: two citizens, A and B, who both said "Going" to the same event

Verify

The official CivFix account cannot join an event or be blocked, so no screen can show it as a hidden member; "Not covered" says how it was checked.

Regression

A blocked person on an event's member list — [Web] [Mobile]

1. As A, open the event and tap "Message crew".
2. Tap the member count under the chat title — Expect: "Chat info" opens and lists B by name and @handle.
3. Tap "More options for B", then "Block", then "Block this person".
4. Go back and open "Chat info" again — Expect: B's row reads "Community member", with no @handle and no check mark.
5. Open "Settings", then "Privacy & safety", then "Blocked accounts", and tap "Unblock" next to B.
6. Open the event's "Chat info" again — Expect: B's name and @handle are back.

Not covered

• The official account as a hidden member: checked by the unit suite, which lists it hidden and expects "Community member" with no official mark.

[greptile-apps]

Confidence Score: 3/5

Unsafe to merge: the inbound-mail authentication change permits unauthorized public report updates.

What we checked:

• Reproduced the authentication-related proof for P1, producing authentication-results reproduction, baseline output, forged message effects, and focused inbound test outputs.
• Validated the P2 migration proof by running the migration script, capturing seed and result outputs, and reviewing the focused PostgreSQL test outcomes.
• Validated the API runtime contract and CI-harness-like reproduction by building the image and running the smoke test inside, yielding image-smoke success and a runtime-layout-ok with pnpm/corepack absent.
• Demonstrated a header provenance test using a spoofed inbound message; the focused unit run reported authVerdict 'pass' and 109 passing tests, noting that header provenance is not covered by focused tests.
• Completed the PostgreSQL integration run, showing inbound/outbound deliveries for two test cases and 18 tests passing.

_{Reviews (1) · Last reviewed commit: "Drop the official flag from an attendee ..."}

[greptile-apps]

Comments Outside Diff

These findings sit on lines the diff does not cover, so they could not be posted inline. Each one leaves this list once its file changes.

•   Forged auth stamp accepted services/api/src/adapters/inbound-mail.cf.ts:150 ▶

  An attacker can put Authentication-Results: mx.cloudflare.net; dmarc=pass header.from=<city domain> directly in a raw email. This code accepts that sender-supplied text as proof of authentication, then treats the reply as affiliated and lets it update a report’s public status and chat. Anyone able to address a valid reply-token mailbox can impersonate a jurisdiction contact.

  How this was verified: A forged raw message received a passing verdict and produced public report effects.

•  Backfill picks arbitrary verdict services/api/drizzle/0181_mail_messages_auth_verdict.sql:10 ▶

  This update joins a message to every matching delivered event without choosing one deterministically. When a message has both passing and failing delivery events, PostgreSQL can persist either value based on join order. This is a non-blocking data-quality concern, but it can make the admin inbox show an inaccurate authentication result and lead to incorrect operator review decisions.