Libellus Potionis

This control is conditional on the project operating a CI/CD pipeline in which jobs are assigned permissions, and the project operates none. No CI/CD system or pipeline is configured in the repository (no Woodpecker, Forgejo Actions, GitHub Actions, GitLab CI, or other automation), so there are no pipeline jobs that could be granted more than the minimum privileges; the precondition never occurs. Releases are built and published manually with Fastlane, run locally by the sole maintainer on a trusted checkout. Should a CI/CD pipeline be introduced later, it will be configured to assign the lowest available permissions by default and elevate only where a specific task requires it — tracked in the project roadmap, alongside the related OSPS-AC-04.01 and OSPS-BR-01.04.

This control is conditional on the project operating CI/CD pipelines that accept trusted-collaborator input, and the project operates no CI/CD pipelines at all. No CI/CD system or pipeline is configured in the repository (no Woodpecker, Forgejo Actions, GitHub Actions, GitLab CI, or other automation), so there is no pipeline — and in particular none accepting manual collaborator/workflow input — whose input could require sanitizing or validation; the precondition never occurs. Releases are built and published manually with Fastlane, run locally by the sole maintainer on a trusted checkout. Should a CI/CD pipeline be introduced later, any collaborator or workflow inputs it accepts will be sanitized and validated before use, consistent with the related OSPS-BR-01.01/OSPS-BR-01.03 and OSPS-AC-04.01/OSPS-AC-04.02 (tracked in the project roadmap).

Every user-facing release has a unique version identifier. The app carries a three-part versionName (MAJOR.MINOR.PATCH) and a strictly increasing integer versionCode, both defined in android/app/build.gradle.kts. CONTRIBUTING.md requires that the versionName, the top CHANGELOG.md entry, the README title, and the proguard-rules.pro header all carry the same version string and that versionCode increases by at least 1 each release; the tools/release-check.sh release gate enforces this consistency automatically. The iOS port carries the same single version: tools/gen-ios-version.py derives its MARKETING_VERSION from the top CHANGELOG.md entry and its CURRENT_PROJECT_VERSION from the same versionCode, writing both to the generated ios/Version.xcconfig, so the two apps release under one identifier.

SECURITY.md defines a "Secrets and credentials" policy enumerating the secrets used (release signing keystore, Google Play upload credentials, and the maintainer's OpenPGP signing key) with guidelines for storing them (never hard-coded or committed; git-ignored with structure-only templates; environment-variable injection), accessing them (held solely by the single maintainer on trusted machines, not shared), and rotating them (Play credential/tokens rotated at will; OpenPGP key rotated by publishing a new key; the long-lived Android app-signing key rotated only on suspected compromise via the distribution channel's key-rotation process; any exposed secret revoked and replaced before the next release).

Releases are cryptographically signed with the maintainer's own Android app-signing key via reproducible builds; the private key is held only by the maintainer and is never stored on Codeberg, F-Droid, or any other distribution site. SECURITY.md ("Verifying releases") documents how users obtain the public key and verify a release: the F-Droid client verifies the signature automatically and the project's F-Droid metadata pins the allowed signing key; users can also compare the APK signing certificate SHA-256 fingerprint (7506f17184b31a2d67621305d190a73e497806b39f7d64463ff5dbc0afd8317b) via apksigner verify --print-certs, or reproduce the build and compare. The productive channels (Codeberg, F-Droid) use this author-signing model; the planned store channels follow each store's own model instead. With the Apple App Store the developer signs with a distribution certificate and App Store Connect re-signs the app with an Apple identity (and Google Play App Signing re-signs with a Google-held key), so on those channels the store, not the maintainer, holds the distribution key — a property of the platforms, not a project choice.

Releases are cryptographically signed with the maintainer's own Android app-signing key via reproducible builds; the private key is held only by the maintainer and is never stored on Codeberg, F-Droid, or any other distribution site. SECURITY.md ("Verifying releases") documents how users obtain the public key and verify a release: the F-Droid client verifies the signature automatically and the project's F-Droid metadata pins the allowed signing key; users can also compare the APK signing certificate SHA-256 fingerprint (7506f17184b31a2d67621305d190a73e497806b39f7d64463ff5dbc0afd8317b) via apksigner verify --print-certs, or reproduce the build and compare. The productive channels (Codeberg, F-Droid) use this author-signing model; the planned store channels follow each store's own model instead. With the Apple App Store the developer signs with a distribution certificate and App Store Connect re-signs the app with an Apple identity (and Google Play App Signing re-signs with a Google-held key), so on those channels the store, not the maintainer, holds the distribution key — a property of the platforms, not a project choice.

SECURITY.md includes a "Support" section describing the scope and duration of support for each release. The project is a single-maintainer rolling release in which only the latest version is supported; support consists of best-effort bug fixes and security updates shipped in new releases via F-Droid, with no back-porting; each release is supported until the next supersedes it; and support is obtained through the Codeberg issue tracker (or the vulnerability-reporting process for security issues).

The "Support" section of SECURITY.md states when versions stop receiving security updates. A given version stops receiving security updates as soon as a newer release supersedes it, because security fixes are shipped in new releases rather than back-ported; if the project is discontinued this will be announced in the repository, after which no further security updates are provided.

docs/GOVERNANCE.md documents an enforceable policy that code collaborators are reviewed before being granted escalated permissions to sensitive resources. Write/merge access to the canonical repository and access to release secrets or credentials are granted only after the maintainer has reviewed and approved the individual, considering their track record of contributions reviewed through the normal pull-request process, a justifiable lineage of identity, and the mandatory 2FA. Permissions are granted at the lowest level needed and escalated only as further need is demonstrated; until such a grant, all contributions go through pull requests merged only by the maintainer, so no contributor holds escalated permissions without this review.

Every released version is delivered with a CycloneDX software bill of materials, one per platform. The Android build generates its SBOM alongside the release artifact — make release-android/make bundle run the cyclonedxDirectBom Gradle task, producing android/app/build/outputs/sbom/libellus-potionis-sbom.json, normalized to be byte-stable and staged as <id>_<code>_android_sbom.json — and the iOS build generates an equivalent CycloneDX 1.6 SBOM from ios/PotillusKit/Package.resolved via tools/gen-ios-sbom.py, normalized by the same tools/sbom-normalize.py and staged as <id>_<code>_ios_sbom.json (make ios-sbom / make release-ios). Each published release on Codeberg is accompanied by the platform SBOM(s) as downloadable release assets. Attaching the SBOM is a documented step in the release checklist. Users can thus obtain a standardized, auto-generated SBOM for each release of either app.

This control applies only to a release comprising multiple source code repositories, and Libellus Potionis is a single-repository project. The entire application is built from one canonical repository (codeberg.org/godisch/potillus), with no submodules, subprojects, or additional source repositories compiled into the release, so there are no subprojects that could need to enforce security requirements as strict as the primary codebase; the precondition never occurs. This is consistent with the single-repository answer given for the related OSPS-QA-04.01.

The project ships a substantial automated test suite, released as FLOSS under GPL-3.0-or-later in the same repository: JVM unit tests in android/app/src/test/ (domain, data, l10n, util, and ViewModel layers, plus LocaleSyncTest) and instrumented tests in android/app/src/androidTest/ (Room migration validation, Compose UI components, on-device locale formatting), and, for the iOS port, XCTest suites in ios/PotillusKit/Tests/ (the shared domain, data and presentation layers) plus the app-target and UI-test suites under ios/PotillusTests/ and ios/PotillusUITests/, using FLOSS test frameworks (JUnit, AndroidX/Compose testing, XCTest). Both suites additionally assert against the shared golden vectors in test-vectors/, so the two ports cannot silently diverge. How to run the tests is documented in CONTRIBUTING.md §5 "Testing strategy" (./gradlew :app:test for unit tests, ./gradlew :app:connectedAndroidTest for instrumented tests) and §7.

The project has a formal written policy mandating tests for new functionality. CONTRIBUTING.md §5 ("Test policy (mandatory)") states that as major new functionality is added, automated tests covering it MUST be added to the project's automated test suite as part of the same change, and that a change introducing significant new behavior without accompanying tests will not be merged. This is reinforced by the domain-layer coverage-floor rules in the same section.

The project provides a security assurance case in docs/ASSURANCE_CASE.md (linked from SECURITY.md). It states the security requirements, describes the threat model (assets, in-scope adversaries/attacks, and explicit out-of-scope residual risks), identifies the trust boundaries (app sandbox, hardware-backed Keystore, FLAG_SECURE screen boundary, device/biometric authentication, the export boundary, and the absence of a network boundary), argues that secure design principles were applied (least privilege, secure defaults, economy of mechanism, defense in depth, fail-safe), and maps common implementation weakness classes to their countermeasures (injection, insecure storage, cryptography, input validation, network exposure, memory safety, tampering, and upgrade data integrity).

Vulnerabilities in dependencies that do not affect the project are accounted for in a standardised, machine-readable VEX document, openvex.json (OpenVEX v0.2.0), which augments the vulnerability report with per-advisory non-exploitability details. The document is empty of statements while the dependency set is clean (nothing to declare); when a non-exploitable advisory is triaged, it is recorded there as a not_affected statement with a machine-readable justification and the affected product's PURL. Because the enforced scanner (osv-scanner) does not yet consume VEX, the same triage is also expressed as an ignore in osv-scanner.toml (the gate mechanism); a dedicated check, tools/check-vex.py (wired into make check-static), fails the build if an advisory is ignored in osv-scanner.toml without a matching VEX statement, so the two never drift. Documented in SECURITY.md, 'Dependency monitoring'. A continuously published VEX feed (versus this in-repo document) and native scanner consumption are tracked in docs/ROADMAP.md, to follow once osv-scanner ships VEX support.

The project applies a documented approach to remediating software-composition-analysis (SCA) findings for both vulnerabilities and licenses. Vulnerabilities: dependencies are scanned before each release with osv-scanner against the CycloneDX SBOM and triaged so that exploitable vulnerabilities are remediated (upgraded or mitigated) before release and non-exploitable ones are recorded (documented in SECURITY.md, "Dependency monitoring"). Licenses: every third-party dependency is verified to be under a license compatible with the project's GPL-3.0-or-later distribution and documented as such, so a dependency with an incompatible license is not shipped (documented in licenses/NOTICES.md). Together these define the remediation threshold for SCA findings.

The project checks its external dependencies for known vulnerabilities before every release, enforced at staging. As documented in SECURITY.md ("Dependency monitoring") and enforced by the CONTRIBUTING.md §7 release checklist, dependencies are scanned before each release with osv-scanner (a FLOSS scanner querying the OSV database) against the CycloneDX SBOM the build generates. Reported issues are triaged: exploitable vulnerabilities are fixed by upgrading or mitigating the affected dependency; non-exploitable ones are recorded as such.

All changes to the codebase are automatically evaluated against the project's documented dependency policy and blocked on violation. The Woodpecker CI pipeline (.woodpecker.yml, the dependency-scan step) runs osv-scanner as a scan source over the committed lockfiles on every pull request to main; a finding fails the step, and branch protection on main requires that check to pass before merge, so a vulnerable or malicious dependency blocks the change. The scanner honours osv-scanner.toml, the documented triage allowlist (a finding assessed non-exploitable per SECURITY.md is recorded there with its reason; anything un-triaged still blocks). The per-change CI check is backed by a second enforced scan at release staging over the COMPLETE transitive SBOM (osv-scan-sbom in make/release.mk), which additionally covers the Android app graph a lockfile-only source scan cannot see without Gradle. Together these evaluate every change and every release against the policy and block on violation.

Findings from static analysis cannot reach a release: Android Lint runs as a release gate with abortOnError = true and warningsAsErrors = true, so any reported issue breaks the build and must be fixed (or made an explicit, reviewable exception) before a release can be produced. Timely remediation is thus enforced by construction, and no exploitable medium-or-higher findings are currently outstanding. The Lint release gate is configured in android/app/build.gradle.kts. On the iOS side SwiftLint — a FLOSS linter pinned to version 0.65.0 — runs as a make ios gate over the Swift sources, so lint findings are caught before a build ships.

Android Lint, a FLOSS static analysis tool that goes well beyond compiler warnings and safe-language modes (it analyzes code, resources, the manifest, API usage, correctness, performance, and security across hundreds of rules), is applied to every release as a build gate: android/app/build.gradle.kts configures lint { abortOnError = true; warningsAsErrors = true } and the release process runs ./gradlew lintDebug, so a release cannot be produced while Lint reports any issue. On the iOS side SwiftLint — a FLOSS linter pinned to version 0.65.0 — runs as a make ios gate over the Swift sources, so lint findings are caught before a build ships.