Files
flamenet-messenger-android/client
Paul Hitt ff975bf36d Trust the relay you typed, pin the relays that are ours
Correcting a rule I got wrong earlier today. I had the client accept a named
account service only if it was on a pinned list containing exactly
accounts.flamenet.io — which is safe and breaks the case the server already
supports: a self-hoster running Messenger and Files together, with their own
account service holding the one account across both. The file server has taken
ENCLAVE_ACCOUNTS_URL for exactly that since it shipped, and main's relay makes
FN_ACCOUNTS_URL configurable for the same reason. A client refusing the answer
would make "run both" mean "run them with two separate logins".

The rule is asymmetric, and the asymmetry is the point:

  - For flamenet.io and its aliases the account service is PINNED in the client
    and whatever those relays advertise is ignored. Compromising one of ours
    must not let it redirect its users' passphrase-derived secrets.
  - Every other relay is believed. The user typed that hostname themselves; a
    server they chose naming its own account service is a choice they already
    made, and it cannot redirect anybody else's users.

Two tests, one for each half: a pinned relay advertising an attacker's service
still authenticates against ours, and a self-hosted relay may name its own.
2026-08-24 15:39:29 -04:00
..
2026-08-23 15:37:59 -04:00