rbrooks/Quest-Board
Watch
1
0
Fork
You've already forked Quest-Board
 0
Code Issues 58 Pull requests 7 Projects Releases 76 Packages Wiki Activity Actions

[Security] Campaign import reads data.json with no cap on its decompressed size #1054

New issue
Closed
opened 2026-10-03 23:29:21 +00:00 by claude-bot · 5 comments
claude-bot commented 2026-10-03 23:29:21 +00:00
Collaborator
Copy link

Found in the privacy review of #991 part 1. It predates that work and applies to every export schema version.

What

import_service reads data.json out of the uploaded zip with no limit on its decompressed size. Only the upload itself is capped, at 100 MB. A small, highly compressible file can therefore expand to far more than the backend's memory limit (512 MB, see #841) and take the worker down: a zip bomb.

Who can do it

Whoever may import a campaign: a signed-in user on New campaign's import, and an administrator on Admin → Import a campaign. It is not reachable signed out.

Fix

  • Refuse before reading: check the zip entry's declared file_size against a cap, and read through a bounded reader so a lying header cannot get past it.
  • Apply the same to any other entry the import reads (media, once #991 part 2 brings files).
  • The error is the usual 422 {"detail": ...}, in words: the file is too large to import.

Why now

Schema 17 (#991 part 1) stores more JSON as it arrives, and part 2 adds binary files, which is where a per-file and a total limit (the owner's Q145) have to be decided anyway. The data.json cap does not need that answer: a generous fixed bound is enough, and no genuine export comes near it.

Related: a sheet row's name and a sheet's data have no import limit beyond the row and roll counts.

Found in the privacy review of #991 part 1. It predates that work and applies to every export schema version. ## What `import_service` reads `data.json` out of the uploaded zip with no limit on its decompressed size. Only the upload itself is capped, at 100 MB. A small, highly compressible file can therefore expand to far more than the backend's memory limit (512 MB, see #841) and take the worker down: a zip bomb. ## Who can do it Whoever may import a campaign: a signed-in user on New campaign's import, and an administrator on Admin → Import a campaign. It is not reachable signed out. ## Fix - Refuse before reading: check the zip entry's declared `file_size` against a cap, and read through a bounded reader so a lying header cannot get past it. - Apply the same to any other entry the import reads (media, once #991 part 2 brings files). - The error is the usual 422 `{"detail": ...}`, in words: the file is too large to import. ## Why now Schema 17 (#991 part 1) stores more JSON as it arrives, and part 2 adds binary files, which is where a per-file and a total limit (the owner's Q145) have to be decided anyway. The `data.json` cap does not need that answer: a generous fixed bound is enough, and no genuine export comes near it. Related: a sheet row's name and a sheet's `data` have no import limit beyond the row and roll counts.
claude-bot commented 2026-10-04 05:12:07 +00:00
Author
Collaborator
Copy link

Progress, and a finding that keeps this open. The work is on feat/991-archive-on-disk (PR A of #991 part 2), not yet a PR.

What the branch does

  • The upload is spooled to disk and every read from the archive is bounded: upload size (an Admin setting, 1 GB by default, 100 MB to 4 GB), total decompressed bytes, data.json size, entry count, each picture.
  • A 1,000 MB import through nginx peaked at 349 MB in the 512 MB backend, with no OOM kill.

The finding
A data.json inside every bound can still get a backend worker OOM-killed:

  • The file: 32 MB, one long string with a single emoji in it. The upload is about 32 KB compressed.
  • Why: Python holds that text at four bytes a character, twice (the decoded text, then the parsed value). Measured extra peak: +193 MB for the string alone, +378 MB for the worst mix inside both bounds.
  • Headroom: a warm backend sits at about 336 MB of 512 MB.
  • Seen on the real stack: a 502 to the client, oom_kill 1, and the worker restarted.

Decision taken

  • Lower the caps: data.json to 12 MB (8 MB if the measurement says so) and 500,000 values. Production's whole database is 17 MB across 2 campaigns, so no real export is refused.
  • The worst case at the new caps is being measured in a 512 MB container before the PR opens.

What stays open here

  • Parse the import in the worker (1 GB), as a background import. That is the real fix and what would let the caps rise.
  • For the owner: raising the backend's mem_limit to 1g is the alternative. It changes what each host needs, so I have not done it.

The PR will say it addresses this issue, not that it closes it.

**Progress, and a finding that keeps this open.** The work is on `feat/991-archive-on-disk` (PR A of #991 part 2), not yet a PR. **What the branch does** - The upload is spooled to disk and every read from the archive is bounded: upload size (an Admin setting, 1 GB by default, 100 MB to 4 GB), total decompressed bytes, `data.json` size, entry count, each picture. - A 1,000 MB import through nginx peaked at 349 MB in the 512 MB backend, with no OOM kill. **The finding** A `data.json` inside every bound can still get a backend worker OOM-killed: - **The file:** 32 MB, one long string with a single emoji in it. The upload is about 32 KB compressed. - **Why:** Python holds that text at four bytes a character, twice (the decoded text, then the parsed value). Measured extra peak: +193 MB for the string alone, +378 MB for the worst mix inside both bounds. - **Headroom:** a warm backend sits at about 336 MB of 512 MB. - **Seen on the real stack:** a 502 to the client, `oom_kill 1`, and the worker restarted. **Decision taken** - Lower the caps: `data.json` to 12 MB (8 MB if the measurement says so) and 500,000 values. Production's whole database is 17 MB across 2 campaigns, so no real export is refused. - The worst case at the new caps is being measured in a 512 MB container before the PR opens. **What stays open here** - **Parse the import in the worker** (1 GB), as a background import. That is the real fix and what would let the caps rise. - **For the owner:** raising the backend's `mem_limit` to 1g is the alternative. It changes what each host needs, so I have not done it. The PR will say it addresses this issue, not that it closes it.
claude-bot commented 2026-10-04 06:56:51 +00:00
Author
Collaborator
Copy link

PR #1072 is merged. This issue stays open for one thing. CI was green on the merged commit.

Now bounded

  • Upload size: the Admin setting (1 GB by default, 100 MB to 4 GB), spooled to disk.
  • Total decompressed bytes: the same limit.
  • data.json: 8 MB and 400,000 values (commas, colons and opening brackets outside strings). These ended lower than the 12 MB and 500,000 in my earlier comment: 12 MB missed the memory target when measured.
  • Entries: 20,000, checked against the record zipfile itself reads.
  • Compression: only stored and deflated entries are read. A bzip2 or LZMA entry is refused at open; it decompressed without bound before.
  • Imports in flight: two per worker process, one per user, and a 120 s stall bound.

Measured

  • The dearest in-bounds data.json found costs about 117 MB while parsing, in a 512 MB backend.
  • On a real stack, 18 hostile in-bounds uploads (up to four at once) all answered and oom_kill stayed 0. The sampled peak reached 505 MB of 512 MB, so the margin is thin.

What keeps this open

  • Parse the import in the worker (1 GB), as a background import. That removes the thin margin and lets the data.json caps rise. A campaign that runs for years will reach 8 MB; its export still works, and its import is refused with a sentence.
  • For the owner: raising the backend's mem_limit to 1g is the quicker alternative. Not done.

Production (4.4.1) still has the original uncapped read until 4.5.0.

**PR #1072 is merged. This issue stays open for one thing.** CI was green on the merged commit. **Now bounded** - **Upload size:** the Admin setting (1 GB by default, 100 MB to 4 GB), spooled to disk. - **Total decompressed bytes:** the same limit. - **`data.json`:** 8 MB and 400,000 values (commas, colons and opening brackets outside strings). These ended lower than the 12 MB and 500,000 in my earlier comment: 12 MB missed the memory target when measured. - **Entries:** 20,000, checked against the record `zipfile` itself reads. - **Compression:** only stored and deflated entries are read. A bzip2 or LZMA entry is refused at open; it decompressed without bound before. - **Imports in flight:** two per worker process, one per user, and a 120 s stall bound. **Measured** - The dearest in-bounds `data.json` found costs about 117 MB while parsing, in a 512 MB backend. - On a real stack, 18 hostile in-bounds uploads (up to four at once) all answered and `oom_kill` stayed 0. The sampled peak reached 505 MB of 512 MB, so the margin is thin. **What keeps this open** - **Parse the import in the worker** (1 GB), as a background import. That removes the thin margin and lets the `data.json` caps rise. A campaign that runs for years will reach 8 MB; its export still works, and its import is refused with a sentence. - **For the owner:** raising the backend's `mem_limit` to 1g is the quicker alternative. Not done. Production (4.4.1) still has the original uncapped read until 4.5.0.
claude-bot commented 2026-10-05 05:45:47 +00:00
Author
Collaborator
Copy link

Owner's answer to Q153 (O33), 2026-10-05: (a), as recommended. Move the reading to the worker, which has 1 GB; an import then answers at once and finishes in the background.

Also answered, Q154 (O34): the limits are fine as they are. Two imports at once per process, one per person, a 120 s stall bound, 200 map pictures and 5,000 attachments per import, and the picture and GIF bounds.

What this means for the build

  • The import route stores the upload, answers with something to follow, and a worker task reads and writes the campaign.
  • The form shows progress and then the same result (the new campaign, what was left out, the rule links), or the reason it was refused.
  • The data.json caps can rise once the read is in the worker; by how much is to be measured there.
  • A killed worker must not leave half a campaign: the import stays one transaction, and #1075's sweep already removes files with no campaign.

Order: after #1095 lands, since both change import_service.py. To be recorded as a decision with today's other answers.

**Owner's answer to Q153 (O33), 2026-10-05: (a), as recommended.** Move the reading to the worker, which has 1 GB; an import then answers at once and finishes in the background. **Also answered, Q154 (O34): the limits are fine as they are.** Two imports at once per process, one per person, a 120 s stall bound, 200 map pictures and 5,000 attachments per import, and the picture and GIF bounds. **What this means for the build** - The import route stores the upload, answers with something to follow, and a worker task reads and writes the campaign. - The form shows progress and then the same result (the new campaign, what was left out, the rule links), or the reason it was refused. - The `data.json` caps can rise once the read is in the worker; by how much is to be measured there. - A killed worker must not leave half a campaign: the import stays one transaction, and #1075's sweep already removes files with no campaign. **Order:** after #1095 lands, since both change `import_service.py`. To be recorded as a decision with today's other answers.
claude-bot commented 2026-10-05 07:44:10 +00:00
Author
Collaborator
Copy link

Picking up the worker move (D281), on feat/1054-import-in-the-worker, now that #1101 has landed.

Shape

  • The upload arrives and is checked as today, then is kept in a private directory on the shared media volume.
  • The route answers 202 with a job's id. A new route gives the job's state to the person who started it.
  • A worker task reads the file and writes the campaign in one transaction, as the route does today.
  • The form shows that the import is being read, then today's result or today's refusal.

Adds

  • One small table for import jobs (an additive migration).
  • A sweep for uploads whose job is finished or lost.

Changes in meaning

  • "Two imports at once, one per person" is enforced from the job table, so it holds across the whole server. Today it is per backend process.
  • The data.json caps rise by what measurement in the worker allows, beside a map decode.

Before merging: an independent review, as for #1072.

**Picking up the worker move (D281)**, on `feat/1054-import-in-the-worker`, now that #1101 has landed. **Shape** - The upload arrives and is checked as today, then is kept in a private directory on the shared media volume. - The route answers 202 with a job's id. A new route gives the job's state to the person who started it. - A worker task reads the file and writes the campaign in one transaction, as the route does today. - The form shows that the import is being read, then today's result or today's refusal. **Adds** - One small table for import jobs (an additive migration). - A sweep for uploads whose job is finished or lost. **Changes in meaning** - "Two imports at once, one per person" is enforced from the job table, so it holds across the whole server. Today it is per backend process. - The `data.json` caps rise by what measurement in the worker allows, beside a map decode. **Before merging:** an independent review, as for #1072.
claude-bot commented 2026-10-05 11:58:37 +00:00
Author
Collaborator
Copy link

Done: PR #1104, merged to main (D281). CI was green on the merged commit.

  • An import is a background job. The upload is stored, the route answers 202, and the worker reads the file and writes the campaign in one transaction.
  • The backend's memory is flat during an import (380 → 384 MB in the stack run; on main the same import took it from 381 to 441 MB, where it stayed).
  • data.json may be 24 MB and 1,200,000 values, measured in the worker.
  • A memory stop ends an import that builds more than the worker can hold, with a sentence.
  • A killed or timed-out import ends "failed" exactly once and leaves no campaign, no files and no upload. Shown on a real worker.
  • "Two at once, one per person" is counted from the job table, so it holds across the server.
  • Migration: d1054a2b3c4e adds import_jobs.

Review: an independent review found no authorisation or path defect and seven robustness gaps; all are fixed. A real-worker run found one more (an import killed at its hard time limit was not redelivered); fixed.

Open after this

  • #1105: count what a file holds before building it. Waiting on the owner's Q162.
  • The sheet evaluator swallows the soft time limit; the hard limit ends such an import two minutes later.
  • An import with many large JPEGs has not been measured against the memory stop.
  • Not run after the fixes: an end-to-end pass through nginx for the slow upload, the memory stop and the account-deletion refusal.

Reaches dev with v4.5.0-rc8.

**Done: PR #1104, merged to main (D281). CI was green on the merged commit.** - **An import is a background job.** The upload is stored, the route answers 202, and the worker reads the file and writes the campaign in one transaction. - **The backend's memory is flat during an import** (380 → 384 MB in the stack run; on main the same import took it from 381 to 441 MB, where it stayed). - **`data.json` may be 24 MB and 1,200,000 values**, measured in the worker. - **A memory stop** ends an import that builds more than the worker can hold, with a sentence. - **A killed or timed-out import** ends "failed" exactly once and leaves no campaign, no files and no upload. Shown on a real worker. - **"Two at once, one per person"** is counted from the job table, so it holds across the server. - **Migration:** `d1054a2b3c4e` adds `import_jobs`. **Review:** an independent review found no authorisation or path defect and seven robustness gaps; all are fixed. A real-worker run found one more (an import killed at its hard time limit was not redelivered); fixed. **Open after this** - #1105: count what a file holds before building it. Waiting on the owner's Q162. - The sheet evaluator swallows the soft time limit; the hard limit ends such an import two minutes later. - An import with many large JPEGs has not been measured against the memory stop. - Not run after the fixes: an end-to-end pass through nginx for the slow upload, the memory stop and the account-deletion refusal. Reaches dev with `v4.5.0-rc8`.
rbrooks referenced this issue from a commit 2026-10-05 11:58:48 +00:00
chore(release): v4.5.0-rc8
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
feat/1328-fill-it-in
feat/1328-fill-frontend
feat/1328-fill-backend
feat/9-foundry-push
fix/9-foundry-live
feat/9-foundry-push-frontend
renovate/celery-5.x
feat/5-foundry-connect
feat/9-foundry-push-backend
feat/9-foundry-push-module
feat/5-foundry-frontend
feat/5-foundry-backend
feat/5-foundry-module
release/v4.8.0-rc1
docs/d341-convert-draft
feat/958-update-to-version
feat/958-convert-sheet
feat/958-pathbuilder-import-frontend
fix/1360-heading-order
feat/958-pathbuilder-import-backend
feat/11-weekly-digest
feat/1341-auto-update
docs/d332-superseded
chore/1345-names-cleanup
feat/1342-mentioned-pages
feat/1328-recipes
fix/1346-pgdg-key
perf/1247-shared-recording-stream
chore/132-gitleaks-allowlist
release/v4.7.1
spike/foundry-module
release/v4.7.1-rc1
docs/decisions-d332-d337
fix/bot-certifi
chore/release-4.7.0
chore/release-4.7.0-rc4
chore/deps-4.7.0
chore/release-4.7.0-rc3
fix/1280-quote-must-say-it
fix/1257-names-row-squeeze
chore/release-4.7.0-rc2
fix/1245-pg-upgrade-count
chore/release-4.7.0-rc1
feat/1257-names-in-prep
feat/1257-be
feat/1257-fe
feat/1257-rating-fixes
design/1328-fill-it-in
feat/1257-name-splits
fix/1326-redis-503
feat/1280-fact-suggestions
feat/1280-be
feat/1280-fe
design/1280-fact-suggestions
feat/1279-infobox
feat/1279-be
feat/1279-fe
feat/1321-shelf-copies
design/1279-infobox
feat/1243-table-find
feat/1257-who-rated
feat/1243-prep-drawer
feat/1243-sheet-pickers
design/1243-browse-in-place
feat/1315-hotwords-default
feat/1242-system-filters
feat/1257-more-name-styles
feat/506-leg3-hotwords
design/1242-system-filters
fix/1302-packs-polish
feat/1241-rules-library
design/1241-rules-library
feat/1245-postgres-18
integ/4.6.2
fix/1263-map-ui-2
fix/1263-map-server
fix/1263-map-ui-1
fix/1261-editor-link-menu
fix/1229-axe-4.14-name-mismatch
renovate/axllent-mailpit-1.x
renovate/eslint-monorepo
renovate/authlib-1.x
chore/release-4.6.0
chore/release-4.6.0-rc2
fix/460-rc2-screens
fix/460-rc2-server
fix/release-prerelease-exit
chore/release-4.6.0-rc1
feat/125-campaign-templates
feat/126-calendar
feat/1181-pictures-and-files
feat/1190-event-people
integ/4.6.0
feat/1191-line-of-the-night
feat/1200-starter-packs
chore/bot-multidict-and-playwright-group
fix/1202-this-week-answered-count
fix/122-124-leftovers
fix/1178-get-routes-that-write
fix/1203-journeys-check-names
design/125-campaign-templates
feat/126-calendar-engine
design/126-in-world-calendar
fix/1189-cited-stamp-in-range
fix/1189-v4-looser-check
fix/1189-richer-beats
fix/1113-export-bind-lists
fix/1154-release-notes-by-file
chore/release-4.5.0
chore/release-4.5.0-rc12
fix/1135-wiki-markup-as-text
fix/demo-usage-cost-in-window
chore/release-4.5.0-rc11
fix/1121-sheet-consistency
fix/1121-sheet-5e-terms-and-card-hp
copy/1122-busiest-pages
fix/1121-relevant-choices
fix/1121-wiki-create-npc-save-sheet-links
fix/1029-menu-stays-on-screen
docs/prototype-transcript-bin-wording
fix/1023-editor-save-row-back-scroll
fix/1020-search-exact-first
fix/1020-table-prep
fix/1020-shell-wordmark-footer-bell
fix/1020-wiki-article-party
fix/872-admin-kept-until-phone-tables
feat/l13-milestone-level-waiting
fix/1000-1001-bell-older-setup-context
fix/999-pronouns-in-prompts
fix/l19-other-class-feats
fix/1010-transcript-window-ordinary-confirm
docs/d254-d269-decisions
fix/702-member-search
fix/680-transcript-bin
fix/993-unidentified-prompts
fix/841-redis-timeouts
fix/990-binned-not-exported
fix/830-export-prep-shelf
fix/deps-audit-2026-10-01
fix/877-title-reads
fix/798-audio-received-at
build/lane11-17-j7
build/lane11-16-levelup
build/lane11-14-seams
build/lane11-14-seed
build/lane11-15-start
build/lane11-13-old-block-out
fix/980-review-r3
build/lane11-12-block
build/lane11-8-packs
fix/demo-seed-canonical-names
build/lane11-11-hot-half
docs/l11-decisions
build/lane11-7-convert
build/lane11-10-editing
fix/npm-audit-brace-expansion
build/lane11-9-sheet-page
fix/bot-pyjwt
build/lane11-6-content
fix/lane11-rank-names
build/lane11-2b-language
build/lane11-4-js-evaluator
build/lane11-3-server
build/lane11-5a-pf2e
build/lane11-5b-5e
feat/design-admin
build/lane11-2-evaluator
build/lane11-1-sheet-pieces
build/lane11-0-drawing
fix/943-quest-objectives-fk
fix/prepsheet-shelf-flake
fix/945-leftovers
build/demo-gm-copy
fix/901-email-landings
build/lane10-8-journeys
build/demo-seed-lanes-8-10
fix/887-gm-own-confirmation
build/lane9-5-j1-admin
fix/918-audience-click
fix/useasync-overtaken
ci/939-critical-path
test/937-backend-suite-speed
chore/claude-orchestration
fix/924-xp-gm-only
fix/session-stale-poll
docs/decisions-d239-d242
fix/930-pypdf
build/lane8-journeys
build/925-quest-editor
fix/894-private-page-pictures
build/lane8-p4-drafts
build/lane8-p7-map
build/lane8-p6-handouts-rules
fix/wiki-fixture-names
build/lane10-d227-test-usage
fix/rsvp-horizon-test-tuesday
fix/media-volume-owner
build/lane8-p3-editor
fix/912-unidentified-rename
build/lane8-p5-party-quests
build/lane8-handout-takeback
build/lane10-pickers
build/lane8-p2-article
build/lane8-6-map
build/lane10-7b-email-pages
build/lane8-5-handouts
build/lane10-7a-test-the-bot-pages
build/lane8-p1-pages
build/lane8-4-quests
build/lane8-2b-feeds
build/lane8-3-parties
build/lane8-2a-links
build/lane10-5-commands
build/lane9-6-seed
build/lane10-4b-reactions
build/lane9-4d-pages
build/lane9-4c-pages
build/lane10-4a-posts
build/lane10-3-email
fix/891-web-fonts
build/lane9-4b-pages
build/lane10-6-test-the-bot
build/lane10-2-notify-out
build/lane8-1-wiki-text
build/lane9-4a-frame
design/lane10-drawings
fix/j6-budget
fix/j5-phone-flake
fix/869-test-leaks
fix/843-record-start-followups
build/lane7-all
build/lane6-all
build/lane9-b2-server
chore/changelog-fragments
docs/decisions-d218
build/lane9-a-owner-overview
fix/rule-card-level-label
fix/834-retention-semantics
fix/o3c-record-without-announcement
docs/decisions-d179
docs/decisions-d131-d170
fix/851-commit-before-response
build/lane6-j3-seed
build/lane9-b1-d67-identity
fix/841-blocking-loop
build/lane9-c-backups-audit
fix/vote-race-and-start-commit
fix/recording-announcement
fix/proposal-read-leak
fix/last-admin-guard
build/lane6-p4c-planning
build/lane6-p4b-margin
build/lane6-p4a-sheet
build/lane5-j4-seed
build/lane6-base
build/lane7-pages-talk
build/lane5-pages
build/lane7-pages-safety
build/lane7-p3-safety
build/lane7-p2-notify
build/lane6-p3-planning
build/lane6-p2-history
build/lane6-p1b-items
build/lane7-p1-threads
build/lane5-p6-faces
build/lane6-p1a-sheet
build/lane5-p5-find
build/lane5-p4a-board
build/lane5-p4b-scenes
build/lane5-p3-live
build/lane5-base
build/lane5-p2-cards
docs/lane5-decisions
build/review-r2-wide
fix/review-r1
build/lane5-p1-scenes
build/demo-seed
build/lane4-journeys-j5
build/lane4-page-review-b
build/lane4-page-review-a
build/lane4-page-read
build/lane4-journeys
build/lane4-page-sess2
build/lane4-page-sess1
build/lane4-notes
build/lane4-discord-on-approval
build/lane4-scheduling
build/lane4-versions
build/760-session-number
build/lane4-decisions
build/797-erase-no-regenerate
build/test-race-audit
build/lane3-completions
build/794-dark-only
build/796-titles-scroll
build/791-retention-anchor
build/a11y-sweep
build/shell-followups
build/retention-preview
build/753-backup-readback
docs/d91-d93
build/lane3-j1
build/ci-harness-paths-selftest
fix/useauth-test-race
build/ci-harness-paths
build/777-ai-settings-read
build/lane3-settings-c
build/lane3-settings-b
build/lane3-j6
build/lane3-sessionform
build/lane3-settings-a
build/lane3-members
build/lane3-thisweek
build/lane3-story
chore/87-align-python-3.12
v4.8.0-rc1
v4.7.1
v4.7.1-rc1
v4.7.0
v4.7.0-rc4
v4.7.0-rc3
v4.7.0-rc2
v4.7.0-rc1
v4.6.2
v4.6.2-rc4
v4.6.2-rc3
v4.6.2-rc2
v4.6.2-rc1
v4.6.1
v4.6.1-rc1
v4.6.0
v4.6.0-rc2
v4.6.0-rc1
v4.5.3
v4.5.3-rc1
v4.5.2
v4.5.2-rc1
v4.5.1
v4.5.1-rc2
v4.5.1-rc1
v4.5.0
v4.5.0-rc12
v4.5.0-rc11
v4.5.0-rc10
v4.5.0-rc9
v4.5.0-rc8
v4.5.0-rc7
v4.5.0-rc6
v4.5.0-rc5
v4.5.0-rc4
v4.5.0-rc3
v4.5.0-rc2
v4.5.0-rc1
v4.4.1
v4.4.0
v4.3.0
v4.2.3
v4.2.2
v4.2.1
v4.2.0
v4.1.2
v4.1.1
v4.1.0
v4.0.1
v4.0.0
v3.11.4
v3.11.3
v3.11.2
v3.11.1
v3.11.0
v3.10.0
v3.9.1
v3.9.0
v3.8.0
v3.7.0
v3.6.1
v3.6.0
v3.5.0
v3.4.1
v3.4.0
v3.3.0
v3.2.0
v3.1.0
v3.0.0
v2.1.0
v2.0.0
v1.1.0
v1.0.0
v0.12.0
v0.11.0
v0.10.0
v0.9.1
v0.3.3
v0.9.0
v0.8.0
v0.3.2
v0.3.1
v0.3.0
v0.7.0
v0.6.0
v0.5.0
v0.4.0
v0.2.1
v0.2.0
v0.1.1
v0.1.0
Labels
Clear labels   
backend
Issue related to the backend

  
bot
Issue related to the bot

  
bug
Something is not working

  
duplicate
This issue or pull request already exists

  
enhancement
New feature

  
frontend
Issue related to the frontend

  
help wanted
Need some help

  
invalid
Something is wrong

  
question
More information is needed

  
recording
Issue related to the recording system

  
security
Security hardening / vulnerability work

  
wontfix
This won't be fixed

No labels
backend
bot
bug
duplicate
enhancement
frontend
help wanted
invalid
question
recording
security
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
rbrooks/Quest-Board#1054
No description provided.