Pentest fixes and hardening

.dockerignore

@@ -1,4 +1,16 @@
+.git
+node_modules
+.venv
 env
+__pycache__
+*.pyc
+*.pyo
 enferno/media
 enferno/imports
 logs
+backups
+.env
+.env.*
+.DS_Store
+*.md
+docs/node_modules

.gitignore

@@ -30,3 +30,9 @@ backups/*
 cookies.txt
 
 *.egg-info/
+
+# Release signing: NEVER commit secret keys. The pinned public key is baked
+# into the installer/updater, not stored as a loose file in the repo.
+*.key
+bayanat-release.key
+bayanat-release.pub

CHANGELOG.md

@@ -1,5 +1,11 @@
 # Changelog
 
+## v4.0.1
+
+### Fixed
+
+- Bulk OCR: celery worker now consumes the `ocr` queue. The systemd unit written by the installer was only subscribing to the default `celery` queue, so tasks dispatched by bulk OCR (UI and `flask ocr process`) silently piled up in Redis. Single-media OCR was not affected. Existing installs can fix in place by adding `-Q celery,ocr` to `ExecStart` in `/etc/systemd/system/bayanat-celery.service`, then `systemctl daemon-reload && systemctl restart bayanat-celery`.
+
 ## v4.0.0
 
 ### Database Migrations (Alembic)

SAFE_EXPUNGING.md

@@ -0,0 +1,43 @@
+# Safe Expunging Process
+
+This document describes when and how history-altering operations are permitted on the Bayanat source repository, satisfying the SLSA v1.2 Source track "Safe Expunging Process" requirement.
+
+## Scope
+
+Applies to the public repository `sjacorg/bayanat` and the private release repository `sjacorg/bayanat.prod`, specifically to operations that remove or rewrite committed history on protected references (`main`, release tags matching `v*`).
+
+## Default
+
+History on protected references is append-only. Force-push, branch deletion, tag deletion, and retagging are blocked by repository rulesets.
+
+## Permitted Reasons to Expunge
+
+Expunging may be approved only for one of the following reasons:
+
+1. **Secret leak.** An unredacted credential, private key, or access token was committed.
+2. **Personal data leak.** Non-public personal data of an identifiable individual was committed.
+3. **Legal or safety order.** A verified order from counsel or a credible safety concern requires removal of specific content.
+4. **Malicious injection.** Attacker-introduced code or data must be removed as part of incident response.
+
+Bug fixes, style corrections, and cleanup are never valid reasons.
+
+## Approval
+
+Both maintainers must approve in writing, recorded in the security advisory created for the incident.
+
+## Procedure
+
+1. File a private security advisory at https://github.com/sjacorg/bayanat/security/advisories with the reason, affected commits, and proposed action.
+2. Record both maintainer approvals in the advisory.
+3. If the reason involves a secret, rotate it before rewriting.
+4. Rewrite with `git filter-repo` (not `filter-branch`), preserving commit signatures where possible.
+5. Temporarily bypass branch protection, force-update the protected reference, then re-enable protection.
+6. Invalidate and regenerate any affected release tags. Old tags are not reused.
+
+## Consumer Notification
+
+After any expunging action, publish a public security advisory that includes:
+
+- What was removed and why (redacted as needed).
+- New commit hashes and release tags that replace the expunged revisions.
+- Operator guidance (re-clone, re-verify signatures, check deployed commit against the new history).