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. See https://codeberg.org/godisch/potillus/src/branch/main/CONTRIBUTING.md#7-versioning--release-checklist

SECURITY.md defines a "Secrets and credentials" policy — https://codeberg.org/godisch/potillus/src/branch/main/SECURITY.md#secrets-and-credentials — 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. URL: https://codeberg.org/godisch/potillus/src/branch/main/SECURITY.md#verifying-releases

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. URL: https://codeberg.org/godisch/potillus/src/branch/main/SECURITY.md#verifying-releases

SECURITY.md includes a "Support" section describing the scope and duration of support for each release — https://codeberg.org/godisch/potillus/src/branch/main/SECURITY.md#support . 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 — https://codeberg.org/godisch/potillus/src/branch/main/SECURITY.md#support . 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 — https://codeberg.org/godisch/potillus/src/branch/main/docs/GOVERNANCE.md#repository-access-and-account-security . 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: https://codeberg.org/godisch/potillus/releases . Attaching the SBOM is a documented step in the release checklist: https://codeberg.org/godisch/potillus/src/branch/main/CONTRIBUTING.md#7-versioning--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 (https://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), using FLOSS test frameworks (JUnit, AndroidX/Compose testing). 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. See https://codeberg.org/godisch/potillus/src/branch/main/CONTRIBUTING.md#5-testing-strategy

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. URL: https://codeberg.org/godisch/potillus/src/branch/main/CONTRIBUTING.md#5-testing-strategy

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). URL: https://codeberg.org/godisch/potillus/src/branch/main/docs/ASSURANCE_CASE.md [assurance_case]

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 — https://codeberg.org/godisch/potillus/src/branch/main/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 — https://codeberg.org/godisch/potillus/src/branch/main/COPYING.md . Together these define the remediation threshold for SCA findings.

The project periodically checks its external dependencies for known vulnerabilities. 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. URL: https://codeberg.org/godisch/potillus/src/branch/main/SECURITY.md#dependency-monitoring

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. See https://codeberg.org/godisch/potillus/src/branch/main/android/app/build.gradle.kts

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. See https://codeberg.org/godisch/potillus/src/branch/main/android/app/build.gradle.kts