The step-up for SSO accounts asks the provider for a new login with
`prompt=login`, but a provider that ignores it answers from its existing
session, so anyone at an unlocked desktop could link a phone. When the
ID token's `auth_time` is older than the step-up, the re-auth is now
refused.
The step-up's failure count was keyed on the cookie slot, which the
client chooses, so a session could spread guesses over 50 slots; and
even one key allowed 480 failures a day, well above Stalwart's ban of
100 a day per address, which would ban the webmail's own IP for every
user. Failures now count per server and login name, 5 per 15 minutes
and 20 a day.
The mobile handoff returned the provider's token endpoint and the
webmail's client id as they were. With a confidential client the phone
could not renew (it has no secret), and a provider on another host was
refused by the app outright. The handoff now returns the same bundle a
paired phone gets: such grants renew through `/api/auth/pair/token` with
a sealed refresh token.
"Link Mobile App" only appeared for OAuth sessions, its step-up could
only go through the identity provider (which failed without an OAuth
client and bounced password+TOTP users to the provider's login page),
and it handed the phone the desktop's own refresh token. Revoking that
token on sign-out, or a rotating provider, signed the phone out too; a
confidential client stopped the phone at its first token expiry; and an
identity provider on another host was refused by the app.
The step-up now mints the phone's own grant:
- Password and password+TOTP accounts confirm the current password (and
code) in the dialog. The server uses it once to get an OAuth grant
from Stalwart's structured login for the app's own client, retries
with the webmail's client when the server insists on a registered one,
and falls back to an app password ("Bulwark mobile (paired <date>)")
or, on servers that offer neither, the verified password. Failed
attempts are limited per account so the webmail's address cannot be
banned by guessing through it.
- SSO accounts keep the provider round trip, now with `offline_access`
where offered; its fresh tokens become the phone's grant instead of
being thrown away, and must belong to the account being paired.
- The account and server always come from the slot's verified session
context, never from the request.
Grants live 5 minutes server-side, codes 2 minutes, both single use; the
store is pinned on `globalThis`. Redeem answers `invalid_code`,
`expired_code` or `used_code`, and the desktop polls a separate status
id to replace the QR with "Signed in on your phone". A phone whose
client is confidential, or whose provider is on another host, renews
through `/api/auth/pair/token` with a sealed refresh token, so current
app builds work unchanged. Signing out discards a pending grant but no
longer affects a paired phone.
The dialog shows for every account (not in Lite), with a copyable
sign-in link, a TOTP field when needed, and the app's own "Scan a
sign-in code" wording.
The step-up for linking a device sends the user to the identity
provider with `prompt=login`. The login route accepted that pending
state too, so a code from the re-auth could be spent there and sign this
browser in as whichever account answered the prompt. It now refuses a
re-auth state; only the pairing route completes one.
The callback page also handles its code once. React's development
double effect ran it twice: the second pass no longer saw the re-auth
flag and raced the pairing route for the single-use code.
With custom JMAP endpoints allowed, the password+TOTP login posted the
admin's client secret to `/auth/token` on whatever server the user
named. The secret now only goes to admin-configured servers.
The password+TOTP login drove Stalwart's structured login (`/api/auth`,
then `/auth/token` with PKCE) inline. Linking the mobile app needs the
same exchange to mint a phone's own grant, so it now lives in
`lib/auth/stalwart-password-login.ts` and the route only maps its
result to the responses it always gave.
The Stalwart bundle's README told admins to use
`releases/latest/download/bulwark-lite-stalwart.zip` as `resourceUrl`.
Stalwart re-downloads that URL on its own schedule and checks no hash or
signature, so whatever the newest release held would run as script on
the Stalwart origin next to the web admin.
The README now installs from the tagged release, explains updating by
moving `resourceUrl` to the next tag, and describes the floating URL as
an opt-in with that risk spelled out. Release runs upload a `.sha256`
next to each Lite zip.
The static export's header policy has to allow inline scripts (the
hydration scripts differ per page and one header cannot list them all),
so any injected inline script ran. The Stalwart bundle had no policy at
all: Stalwart sends no security headers for an Application, and nothing
stopped another site from framing it.
- Postbuild gives every page of the static target a `<meta>` CSP that
allows exactly the page's own inline scripts; enforced together with
the host's header, it takes away `'unsafe-inline'`. `verify` fails a
page whose inline scripts are not all pinned.
- The Stalwart entry document carries a `<meta>` CSP (no plugins, eval,
foreign scripts or moved `<base>`; its shells are rewritten at runtime,
so hashes are not possible there) and refuses to run inside a frame
of another origin.
- The nginx and Caddy examples send the same CSP as `_headers`.
Signing out of Lite only deleted the refresh token from web storage, so
a copy taken from the browser kept working until it expired. Sign-out
now revokes it at the endpoint the mail server (or, for an external
provider, its discovery document) advertises, once the token is gone
from storage.
A password login whose token exchange failed for any reason fell back to
Basic auth and kept the password in sessionStorage. The password is now
only kept for the tab when the server has no token login at all (or
cannot be reached for it); otherwise the Basic session lives in memory
and a reload asks to sign in again.
The mock JMAP server behind `/api/dev-jmap` accepts any password and
shipped in every image, held back only by `DEV_MOCK_JMAP=true` at
runtime. It now also needs the flag at build time (inlined through
`next.config.ts`), so a build made without it cannot switch the mock on,
and the Docker image drops the route before building.
Several endpoints answered anyone with what fingerprints a deployment:
`/api/health?detailed=true` (versions, memory), the update status
(exact version and the text of a pending security advisory, even with
`loginShowVersion` off), `/api/plugins` (installed plugins and the hosts
they may reach), the admin policy (push relays, sidebar app URLs,
plugin lists) and `/api/config` (every domain each server serves).
Visitors without a session now get:
- the plain liveness answer from `/api/health`;
- the update status only where the login page shows the version, and
never the advisory text;
- a 401 from `/api/plugins`, which the client only syncs after signing
in;
- the policy without plugin lists, push relays and sidebar apps, marked
`X-Bulwark-Policy-Scope: public`; the client fetches the full policy
once it signs in;
- server domain lists only when servers are picked by domain.
A mailbox session, a remembered session cookie or the admin session
counts as signed in. Deployments without a session secret cannot tell
sessions apart and keep the old answers.
A full sign-out emptied the stores but left the accounts' traces in the
browser for the next person at the computer: search history, open tabs
with message subjects, Files favourites and recent files, calendar
alert acknowledgements, and attachment bytes a plugin had staged for an
upload that never started. Other open tabs kept showing the signed-out
accounts' mail, and the boot snapshot of the mailbox list was restored
for whichever account happened to be active next.
- A full sign-out now removes those keys and the staged files, and
tells the other tabs through a `storage` event so they leave for the
login page.
- The boot snapshot names its account and is only restored for it.
- The login form only remembers the username for suggestions when the
user did not decline "remember me".
Device preferences and `template-storage` stay: with settings sync off
they exist only on this browser.
`api.storage` kept one `plugin:<id>:` namespace for everyone signed in
to the browser and left it behind after signing out, so a plugin read
what it had stored for the previous account, such as quick-notes'
notes on someone else's mail.
Keys now carry the account (`plugin:<id>:@<account>:<key>`). Signing an
account out or removing it deletes its keys, and a full sign-out
deletes all plugin storage. Keys written before this change are handed
to the first account that uses the plugin. Uninstalling a plugin still
removes everything under its prefix.
A WOPI token carries the user's credentials to the editor server and
stayed valid for its whole six-hour lifetime, so an editor opened
before signing out could still read and save the document afterwards.
Each token now records the browser (a random id in an HttpOnly cookie,
hashed) and account slot that opened it. Signing out records a
revocation time for that browser and slot, or for every slot on a full
sign-out, and WOPI calls with a token minted before it are refused.
Signing out on another device leaves this browser's editors alone.
Revocations live in the state directory, so they survive a restart and
reach replicas sharing the state volume, and are dropped once the
tokens they cover have expired.
`/api/auth/verify` checked any username and password against the JMAP
server without a limit. Every probe reaches the server from the
webmail's own address, so the route was a password oracle and enough
wrong passwords could trip Stalwart's authentication ban against the
webmail itself, locking out every user.
Wrong passwords now use up a budget of five per client and thirty
across all clients per fifteen minutes; right ones are refunded. Over
budget the route answers `inconclusive` and the browser probes the JMAP
server itself, as it did before the pre-check existed.
Used impersonation token ids were only remembered in process memory, so
a captured handoff link could be redeemed a second time within its five
minute lifetime once the process restarted, or on another replica. Each
used id now also leaves a marker file in the state directory, created
exclusively, which every replica sharing the state volume sees; markers
are pruned once the token could no longer verify.
The absolute session limit comes from the eight-hour app password that
Stalwart itself expires.
The startup banner printed `/setup?token=...`, so the one-hour bootstrap
token that grants the setup wizard landed in reverse-proxy access logs,
Referer headers and browser history. The link now carries the token in
the fragment, which never leaves the browser, and the wizard removes it
from the address bar as soon as it reads it. Old `?token=` links still
work and are cleaned up the same way.
A manual run of the release image workflow tagged `latest` on whatever
ref it was dispatched from, and the demo deploy and every Watchtower
install follow `latest`. It now moves only for a published stable
release or a dispatch on a stable `v*` tag.
- `static-lite.yml` gave the whole workflow `contents: write`, including
the build job that runs pull-request code. The build is read-only
now; a separate release job with no checkout uploads the zips.
- `docker-publish.yml` passes the ref name through `env` instead of
interpolating it into the shell script.
The inline sidebar apps hand their origins to the proxy through a
client-written cookie, which the proxy merges into `frame-src`. Any
same-site sibling host could set that cookie too. Over HTTPS the cookie
is now `__Host-bulwark_app_frame_origins`, which only this exact host
can set, and the proxy ignores the unprefixed name there. Plain HTTP
(local development) keeps the old name.
`/api/favicon` is unauthenticated and answers on the webmail origin,
and it passed the upstream Content-Type through unchecked. Should the
favicon service ever return `image/svg+xml` or `text/html`, opening
that URL on its own would run script as the webmail. Only raster image
types are served now, with `nosniff` and a sandboxing CSP; anything
else falls back to the transparent placeholder.
Paths the proxy skips (static files, `/_next`, `/api`) got no security
headers at all, so the not-found shell rendered for a missing
`/foo.html`, `/branding/x` or an unknown `/api` route could be framed
by any site. Skipped responses now carry `nosniff` and
`X-Frame-Options: DENY`, and non-API ones `frame-ancestors 'none'`;
API routes keep setting their own CSP.
The standalone trace excluded only `repos/`. It follows the runtime's
file reads, so building from a checkout that had been run copied
`data/` (admin password hash, plugin signing key, audit log, synced
settings), `local-data/` and `.env` files into `.next/standalone`, and
the Docker build context did not exclude `data/` or `local-data/`
either. Both now leave them out.
Bulwark Lite deleted the remembered refresh token on any non-5xx error
from `/auth/token`, so a 429 or 408 during a busy moment signed the
user out for good. Like the server build, it now clears the token only
when the server refuses it (400, 401, 403) and treats everything else
as an outage.
Tagging and pinning replaced the message's whole keyword set with a
copy built from the list row. When the row was stale - the mail had
been read or answered on another device since - the write cleared
`$seen` or `$answered` again, and removed tags were written as `false`,
which a JMAP keyword map may not hold.
Keyword writes now go out as `keywords/<name>` patches for just the
keywords that change, removals as `null`, through the call that
reports a refused update. The local row gets the same patch.
Clicking a new-mail notification opened `/mail/message/<id>` in
whichever account was active. With several accounts signed in, that
looked the id up in the wrong account: nothing opened, or a different
message did and was marked read.
The preview API now returns the cookie slot of the login that owns the
notified account, the service worker adds it to the permalink (or links
that account's Inbox for a group notification), and the app switches to
the login on that slot before opening the message.
Signing out switches sync off for the signed-out account. When another
account stayed signed in, the app switched to it without turning sync
back on, so every later settings change stayed local and was replaced
by the server copy on the next load. Sign-out now resumes sync for the
account it switches to, the same way an account switch does.
Drafts were saved without In-Reply-To and References, and a draft
re-opens in compose mode, where the composer has no original message to
rebuild them from. A reply that was saved and re-opened, or sent and
brought back with Undo, therefore went out as a new conversation.
`createDraft` now stores the threading headers, the composer saves them
with every draft of a reply, and re-opening a draft carries them into
the composer for later saves and the send.
Marking read, starring, tagging, emptying a folder and cancelling a
scheduled send only checked that the request came back. A `/set` the
server refused - `notUpdated`, `notDestroyed` or a method-level
`error` - resolved as if it had worked: the list showed the new state,
and a cancel the server rejected looked cancelled while the message
still went out.
These writes now go through one check that throws on any of those, so
the store keeps the old state and shows the server's reason.
`getEmails` and `getSomeEmails` caught every failure and answered with
an empty result. A refresh during a server hiccup therefore emptied the
message list, and a push delta whose follow-up read failed treated every
updated row as gone from the folder while still moving the sync state
past those changes, so the missed mail only came back on a full reload.
Both now throw. A refresh that fails keeps the list on screen, a delta
that cannot be read falls back to the full refresh, and the unified
views already record per-account failures instead of showing nothing.
`formatRecipient` writes a quote inside a display name as `\"`, but
the parsers that read recipient strings back took every `"` as the end
of the quoted name. A sender named `Support", ceo@corp.example, "x`
came back from the draft stash (or the dirty check) as three
recipients, one of them an address the user never chose. The
splitter and its helpers now skip escaped characters inside quotes.
Daily expansion advanced its period anchor day by day and kept the
time a DST gap pushed it to: 02:30 became 03:30 on the spring-forward
night, and an all-day event's midnight became 01:00 where the change
happens at midnight (Chile, Brazil). Every later day then failed the
implicit byHour, so the series vanished from that night on.
Each daily candidate is now built from the start's wall-clock time on
its day and matched against that time, so the gap day still shows its
occurrence (moved past the gap) and the days after it are back at the
normal time.
The unified inbox, cross-account views, tag view and "All folders"
search load the next page of every account with the merged list's
length as its position. The list interleaves the accounts, so each
account skipped the rows between its own count and the merged length:
two accounts of 120 mails showed 140 after scrolling to the end.
The fan-out loaders now take a per-account position map, and load
more passes the number of rows each account already has in the list.
The state poll puts two method calls per session account, plus
calendars and filters, into one request. From seven accounts on (the
server's default limit is 16 calls) Stalwart refused the whole request,
and the failure was swallowed, so new mail and folder changes stopped
showing up for users with many shared accounts. The poll now goes out
in batches of `maxCallsInRequest`, one after the other.
The composer took its client, identities and active account live from
the stores. Switching accounts with a draft open moved it: autosave
created the draft in the other account, and replacing the previous
save sent that account a delete for the old draft's id, which there
names an unrelated message. The composer now stays on the account it
was opened in; the other account's identities and client are ignored
until it is closed.
The Account Security store was never reset on an account switch, and
the settings page only fetches while it has no verdict yet. After a
switch it kept showing the previous account's 2FA state, app passwords
and API keys, and "Remove" sent that account's credential ids through
the new account's session.
`clearAllStores` now resets the store, so the page re-probes and loads
the new account, and its fetches drop answers that arrive after the
stores were cleared for another account.
A folder or filter fetch started for one account and answered after a
switch wrote its result into the stores the next account had just
filled. The sidebar then showed the old account's folders, and the
filter store kept the old account's rules and script id, so the next
save uploaded them - a redirect to someone else's address included -
to the new account's server.
Clearing the stores for another account now bumps a store epoch.
`fetchMailboxes` and the email list's view check drop results from an
older epoch, and the filter store drops any fetch that is no longer the
latest one.
Clicking account B and then C before the first switch finished ran
both switches side by side, each holding the account that was active
when it started. The later one then snapshotted B's live stores under
A's key, so switching back to A restored B's identities (and mail) and
never re-fetched them: replies went out with B's From address.
Each switch now takes a generation and stops at its next await once a
newer switch has started, the outgoing account is read when the
snapshot is taken, and stores another switch already cleared are not
snapshotted over the cached state.
Persisted calendar subscriptions were matched to an account by the bare
JMAP account id, or not at all for subscriptions saved by older builds,
and to their calendar by a bare id. Stalwart hands out the same small
ids on every server, so refreshing a subscription through another login
diffed away the events of an unrelated calendar there, and "Remove"
destroyed that calendar. The secret feed URLs also stayed in
localStorage after signing out.
- new subscriptions record their owner (server plus login name), and
refresh, rename and remove act only through that login
- a subscription without an owner is adopted only when its calendar id
and name both exist in the account; otherwise it is left alone and
removing it only drops the local record
- signing out forgets that login's subscriptions, and a full sign-out
clears them all
Linus Rath