Run debugged Sieve scripts under the server's live limits #98

Merged
jcoffey-dev merged 1 commits from sieve-live-limits into main 2026-10-09 08:43:23 +00:00
Owner

The Sieve playground (#97) ran every script under its own permissive defaults: a 100,000-instruction CPU limit, while allowed, large sizes. A script that breaks the server's limits for its kind passed there and then failed on delivery.

Debug now reads the live settings of the interpreter that runs the script and passes them to the playground in the link:

  • Account scripts (x:SieveUserScript, JMAP SieveScript) read x:SieveUserInterpreter: every limit, notification URIs, protected headers, vacation subject/prefix, and the vacation and duplicate expiries (ms → s). Extensions are all except vnd.inbuxa.while and the disabled ones, as the server builds its account runtime.
  • System scripts read x:SieveSystemInterpreter: CPU, variable size, redirects, outgoing messages, nested includes, Received headers, duplicate expiry and noCapabilityCheck. They also get the compiler limits the server fixes in code, and lose the mailbox actions the server switches off (fileinto, vacation, duplicate, …).
  • What the server sets in code rather than from settings is repeated in src/lib/sieveLimits.ts, which points to crates/common/src/config/mailstore/scripts.rs. The capability list comes from the schema's SieveCapability enum, which matches sieve-rs's Capability::all() plus the two vnd.inbuxa.* extensions.
  • If the settings can't be read (permissions, network), the playground opens with its defaults as before.

Checked

  • typecheck, lint, i18n:check, test (656; mapping tests for both interpreters plus the link), build and notice-check all pass locally.
  • Run against the playground's WebAssembly: with the account settings, a while script fails with Capability 'vnd.inbuxa.while' has been disabled; with a 5,000 CPU limit, a long loop stops at the limit. In both cases the implicit keep still happens, as on the server.

No new strings.

The Sieve playground (#97) ran every script under its own permissive defaults: a 100,000-instruction CPU limit, `while` allowed, large sizes. A script that breaks the server's limits for its kind passed there and then failed on delivery. **Debug** now reads the live settings of the interpreter that runs the script and passes them to the playground in the link: - **Account scripts** (`x:SieveUserScript`, JMAP `SieveScript`) read `x:SieveUserInterpreter`: every limit, notification URIs, protected headers, vacation subject/prefix, and the vacation and duplicate expiries (ms → s). Extensions are all except `vnd.inbuxa.while` and the disabled ones, as the server builds its account runtime. - **System scripts** read `x:SieveSystemInterpreter`: CPU, variable size, redirects, outgoing messages, nested includes, Received headers, duplicate expiry and `noCapabilityCheck`. They also get the compiler limits the server fixes in code, and lose the mailbox actions the server switches off (fileinto, vacation, duplicate, …). - What the server sets in code rather than from settings is repeated in `src/lib/sieveLimits.ts`, which points to `crates/common/src/config/mailstore/scripts.rs`. The capability list comes from the schema's `SieveCapability` enum, which matches sieve-rs's `Capability::all()` plus the two `vnd.inbuxa.*` extensions. - If the settings can't be read (permissions, network), the playground opens with its defaults as before. **Checked** - typecheck, lint, i18n:check, test (656; mapping tests for both interpreters plus the link), build and notice-check all pass locally. - Run against the playground's WebAssembly: with the account settings, a `while` script fails with *Capability 'vnd.inbuxa.while' has been disabled*; with a 5,000 CPU limit, a long loop stops at the limit. In both cases the implicit keep still happens, as on the server. No new strings.
jcoffey-dev added 1 commit 2026-10-09 08:41:23 +00:00
Run debugged Sieve scripts under the server's live limits
ci / build (pull_request) Skipped
ci / publish (pull_request) Skipped
ci / notices (pull_request) Successful in 12s
github/ci (branch) GitHub Actions
ci / github (pull_request) Successful in 1m45s
90dd03af5e
The playground ran every script under its own permissive defaults: a
100,000-instruction CPU limit, loops allowed, generous sizes. A script
that breaks the server's limits for its kind passed in the playground
and then failed on delivery.

Debug now reads the interpreter that runs the script, live:
x:SieveUserInterpreter for account scripts (x:SieveUserScript and
JMAP SieveScript) and x:SieveSystemInterpreter for system scripts, and
passes its limits, notification URIs, protected headers, vacation
defaults and expiries to the playground. The extensions follow the
server too: account scripts get every capability but vnd.inbuxa.while
and the disabled ones; system scripts lose the mailbox actions the
server switches off for them. What the server sets in code (the system
compiler's limits, the lifted Received limit for account scripts) is
repeated in sieveLimits.ts, which names where it comes from.

When the settings can't be read, the playground keeps its defaults.

No new strings.
jcoffey-dev merged commit 15c9014858 into main 2026-10-09 08:43:23 +00:00
jcoffey-dev deleted branch sieve-live-limits 2026-10-09 08:43:23 +00:00
Sign in to join this conversation.