fix: release QA hardening across processing, media, security, and CI gates (#649)

A release-readiness QA pass over the whole product. The commits split into
defects a user would hit and gates that were reporting green while measuring
nothing.

## Fixes that change behaviour

Rate limiting was bypassable on every install: TRUST_PROXY defaulted to true, so
request.ip came from a client-set header and a forged X-Forwarded-For got past
the login limiter. The default is now a private-network trust list.

A transient Postgres outage stranded in-flight jobs, leaving finished output on
disk with no row pointing at it. A reconciler now resolves those rows and adopts
the bytes rather than dropping the work.

A Redis connection that moved to a new address wedged every read-blocked
consumer, so completions stopped signalling while health still answered 200.
Socket timeouts plus subscriber pings recover it.

Installing more than one AI bundle left the shared venv multi-versioned and
silently broke three tools. The installer now reconciles distributions to one
version each.

Converting an image to JXL at quality 1 through 4 returned a 500, because
libjxl 0.7 rejects the distance those values compute. The quality is floored at
what the encoder honours. A missing ffmpeg was also reported to the user as a
corrupt upload; it now says the engine is unavailable.

RAW uploads reached an unpatched LibRaw on arm64, so it is built from source at
0.22.2, and the release scan was split so it can fail on an unfixed critical
instead of hiding it behind ignore-unfixed.

## Gates that could not fail

Two mutation lanes ran zero mutants because Stryker crawled the gitignored docs
build; coverage discarded its whole report on any failing test; the lint gate
skipped root tests, scripts, and two workspaces; and several generated matrices
counted a host missing ffmpeg as a passing tool. Each now measures what it
claims.

Full evidence and the outstanding release items are tracked locally and are not
part of this branch.
This commit is contained in:
SnapOtter
2026-07-27 15:37:30 +08:00
committed by GitHub
parent bc32f86a07
commit d10d0f544f
855 changed files with 54564 additions and 13092 deletions
+13 -10
View File
@@ -1,8 +1,9 @@
---
description: "Hantera användare, inbyggda och anpassade roller, behörigheter, API-nycklar, team, sessioner och granskningsloggen i SnapOtter."
i18n_source_hash: 5e28af686c96
i18n_source_hash: bea8955f3aff
i18n_provenance: human
i18n_output_hash: ce4e3c6f3ee8
i18n_output_hash: 9af24cfc9c89
i18n_hash_version: 2
---
# Användare, roller och behörigheter {#users-roles-permissions}
@@ -82,12 +83,12 @@ Alla 17 behörigheter. Full kontroll över instansen.
| `pipelines:all` | Visa och hantera alla användares pipelines |
| `settings:read` | Visa instansinställningar |
| `settings:write` | Ändra instansinställningar |
| `users:manage` | Skapa, uppdatera och radera användarkonton |
| `users:manage` | Skapa och hantera användarkonton inom aktörens behörighetsgräns |
| `teams:manage` | Skapa, uppdatera och radera team |
| `features:manage` | Installera och hantera AI-funktionsbuntar |
| `system:health` | Åtkomst till health- och readiness-slutpunkter |
| `audit:read` | Visa granskningsloggen och lista roller |
| `compliance:manage` | Hantera GDPR-livscykel och efterlevnadsfunktioner |
| `compliance:manage` | Hantera GDPR-livscykel- och efterlevnadsfunktioner; destruktiva användaroperationer förblir auktoritetsbundna |
| `webhooks:manage` | Konfigurera utgående webhooks |
| `security:manage` | Hantera säkerhetsinställningar (IP-tillåtelselista, SSO-tvingande) |
@@ -110,15 +111,17 @@ curl -X POST http://localhost:1349/api/v1/roles \
Rollnamn måste vara 2-30 tecken, gemena alfanumeriska med bindestreck och understreck.
### Administratörsreserverade behörigheter {#admin-reserved-permissions}
### Delegerade administrationsgränser {#delegated-administration-boundaries}
Tre behörigheter är reserverade för inbyggda roller och kan inte tilldelas anpassade roller:
Alla 17 behörigheter kan delegeras genom anpassade roller, men en administrativ behörighet gör inte den rollen likvärdig med den inbyggda `admin`-rollen. Användarmutationer godkända av `users:manage`, destruktiva operationer godkända av `compliance:manage` och anpassade rollhantering auktoriserad av `security:manage` begränsas av skådespelarens nuvarande auktoritet:
- `compliance:manage`
- `webhooks:manage`
- `security:manage`
- Inbyggda roller följer `admin` > `editor` > `user`; anpassade roller är under inbyggda roller.
- Målets behörigheter måste innehållas av skådespelarens **effektiva** behörigheter. En scoped API-nyckel kan därför inte utöva behörigheter som utelämnas från dess scope.
- En målrolls verktygsåtkomst ska innehållas av aktörens egen verktygsåtkomst.
- Ett inaktiverat konto kontrolleras mot sin ursprungliga roll när den rollen registreras som `disabled:<original-role>`.
- Att ta bort en anpassad roll kräver också behörighet att tilldela den inbyggda `user` reserv; funktionshindrade medlemmar förblir inaktiverade som `disabled:user`.
roles-API:et avvisar varje förfrågan som inkluderar dessa behörigheter. Endast den inbyggda `admin`-rollen har åtkomst till dem.
Globala autentiseringsuppgifter och konfiguration är strängare: utfärdande eller återkallande av SCIM-token och import av instanskonfiguration kräver den inbyggda `admin`-rollen med fullständig effektiv administratörsbehörighet.
### Behörigheter på verktygsnivå {#tool-level-permissions}