Libellus Potionis

Pipeline jobs are assigned the lowest privileges available and none is elevated. .gitlab-ci.yml declares no secrets, no protected or masked variables, no privileged mode and no custom service account for any of its three jobs; each runs a read-only check over the checkout on a plain python:3-slim image and writes nothing back to the project. The one credential GitLab injects automatically, the CI job token, is restricted under Settings > CI/CD > Token Access to this project alone, so it cannot be used to reach any other project in the namespace. Releases are built and published manually with Fastlane, run locally by the sole maintainer on a trusted checkout, so no release credential is ever exposed to a pipeline. See also the related OSPS-AC-04.01 and OSPS-BR-01.04.

This control is conditional on CI/CD pipelines that accept input from trusted collaborators, and this project's pipeline accepts none. .gitlab-ci.yml has no manual jobs, no when: manual trigger, no pipeline inputs and no user-supplied variables: it is created only by a merge request targeting main and then runs three fixed commands over the checkout. There is consequently no collaborator or workflow input whose sanitizing or validation the control could require; the precondition never occurs. Should the pipeline later gain a manual trigger or an input, that input 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.

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 GitLab, 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 (GitLab, 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 GitLab, 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 (GitLab, 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 GitLab 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 merge-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 merge 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.cdx.json, normalized to be byte-stable and staged as <id>_<code>_android_sbom.cdx.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.cdx.json (make ios-sbom / make release-ios). Each published release on GitLab 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 (gitlab.com/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 takes the security requirements from SECURITY.md, 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 docs/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 are automatically evaluated against the project's documented dependency policy and blocked on violation, at two levels. PER CHANGE: the dependency-scan job in .gitlab-ci.yml runs osv-scanner (pinned to v2.4.0) as a scan source over the lockfiles committed in the tree (fastlane/Gemfile.lock, ios/PotillusKit/Package.resolved) on every merge request to main; with Merge requests > "Pipelines must succeed" enabled, a finding blocks the merge. Observed green at https://gitlab.com/godisch/potillus/-/pipelines/2700494992. PER RELEASE: the osv-scan-sbom gate in make/release.mk runs the same scanner over the COMPLETE transitive CycloneDX SBOM at staging, covering the Android app graph a source scan cannot see without Gradle. Both levels honour osv-scanner.toml as the documented triage allowlist (a finding assessed non-exploitable per SECURITY.md is recorded there with its reason; anything un-triaged still blocks), so a vulnerable dependency can neither enter main nor reach users.

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.