Libellus Potionis

The project uses a publicly readable, version-controlled Git repository with a stable URL: https://codeberg.org/godisch/potillus — readable without an account and cloneable over HTTPS.

The project's source repository uses Git, which inherently records, for every commit, what changed (the diff/tree), who made the change (author and committer identity), and when (author and commit timestamps). The full history is publicly browsable on Codeberg (commit list, diffs, and blame view) at https://codeberg.org/godisch/potillus/commits/branch/main

The repository contains ongoing interim development commits on the main branch between releases, not only final release snapshots, so work in progress is publicly available for collaborative review. The full commit history is browsable at https://codeberg.org/godisch/potillus/commits/branch/main

The project uses Git, the most widely used distributed version control system, hosted on Codeberg (Forgejo). Repository: https://codeberg.org/godisch/potillus

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 The iOS app shares the same single human-readable version: MARKETING_VERSION is derived from the top CHANGELOG.md entry (the same source of truth as Android's versionName), so a release carries one identical version string on both platforms.

Each release is identified within the version control system by a git tag on Codeberg. Every published version has a corresponding tag of the form v<versionName>, so any release can be located and checked out directly from the repository history. Tags are browsable at https://codeberg.org/godisch/potillus/tags

Each release is accompanied by human-readable release notes in CHANGELOG.md: a curated summary (not raw version-control log output), with a concise subject line plus prose describing the major changes, typically separating user-facing changes from internal ones so users can judge the upgrade impact. Localized store release notes are additionally maintained per versionCode under fastlane/metadata/android/<locale>/changelogs/. URL: https://codeberg.org/godisch/potillus/src/branch/main/CHANGELOG.md

Not applicable: to date there have been no publicly known run-time vulnerabilities in the project's own results (as opposed to its dependencies) that had a CVE assignment or similar at release time and were fixed in a release. As the criterion permits, N/A is selected because there have been no such publicly known vulnerabilities. Should this ever change, the fixed CVE(s) will be named in the corresponding CHANGELOG.md entry.

Users submit bug reports through the project's Codeberg issue tracker, with android@godisch.de offered as an alternative. This process is documented in the README's "Feedback & Contributing" section. URL: https://codeberg.org/godisch/potillus/issues (documented at https://codeberg.org/godisch/potillus/src/branch/main/README.md#feedback--contributing)

The project uses the Codeberg issue tracker to track individual issues. The tracker is enabled and public, and users are directed to it: the README ("Feedback & Contributing") and CONTRIBUTING.md §2 point bug reports and enhancement suggestions there, while SECURITY.md routes security-sensitive reports to a private channel instead. Issue tracker: https://codeberg.org/godisch/potillus/issues

No bug reports have been submitted in the last 2–12 months, so there are no unacknowledged reports; the requirement to acknowledge a majority of submitted bug reports is therefore satisfied. The Codeberg issue tracker is open and monitored for incoming reports: https://codeberg.org/godisch/potillus/issues

No enhancement requests have been submitted in the last 2–12 months, so there are none left unanswered; the requirement to respond to a majority (>50%) of enhancement requests is satisfied. Enhancement requests are accepted via the Codeberg issue tracker: https://codeberg.org/godisch/potillus/issues

Reports and responses are publicly archived and searchable in the Codeberg issue tracker: all issues and pull requests — open and closed — remain publicly visible, are full-text searchable, and are addressable by stable URLs for later reference. URL: https://codeberg.org/godisch/potillus/issues?q=&type=all&state=all

The process for reporting vulnerabilities is published in SECURITY.md at the repository root (which Codeberg/Forgejo surfaces as the project's security policy) and is linked from the README's "Security" section. Reporters are asked to disclose privately via PGP-encrypted e-mail to android@godisch.de rather than opening a public issue. URL: https://codeberg.org/godisch/potillus/src/branch/main/SECURITY.md

Private vulnerability reporting is the required path and SECURITY.md documents exactly how to send the information privately: a PGP-encrypted e-mail to android@godisch.de, using the maintainer's published key (fingerprint 1842 323B 4FCF 9B90 995F A17F A350 B991 F05A 4857), retrievable from the official Debian keyserver (hkps://keyring.debian.org:443). If a reporter cannot use PGP, the maintainer arranges a secure channel before any sensitive details are shared. URL: https://codeberg.org/godisch/potillus/src/branch/main/SECURITY.md

Not applicable: no vulnerability reports have been received in the last 6 months, so there is no initial response time to measure. SECURITY.md nevertheless commits to acknowledging any future vulnerability report within 14 days, so the requirement is covered in advance; this item will be marked Met once a report has been received and handled within that window.

The application is built from source with Gradle. The repository contains the full build definition (android/build.gradle.kts, android/app/build.gradle.kts, android/settings.gradle.kts), a checked-in Gradle wrapper (gradlew / gradlew.bat), and an orchestrating Makefile, so the software can be automatically rebuilt from source (e.g. ./gradlew assembleRelease). As independent evidence, F-Droid reproducibly builds the app from this same source (see fdroid/de.godisch.potillus.yml). Repository: https://codeberg.org/godisch/potillus On iOS, make ios regenerates the Xcode project with XcodeGen and builds via the Swift toolchain, so a single documented command produces the app.

The project builds with the standard, widely used Android toolchain: Gradle (with the Kotlin DSL) and the Android Gradle Plugin, the Kotlin compiler, and the checked-in Gradle wrapper, orchestrated by a Makefile. These are the conventional build tools for Android applications. The iOS app uses the standard Apple toolchain: the Swift compiler and Swift Package Manager for the PotillusKit package, an Xcode project generated declaratively by XcodeGen from ios/project.yml, all driven by the same Makefile. These are conventional iOS build tools.

The build toolchain itself is FLOSS: Gradle, the Gradle wrapper, the Android Gradle Plugin, and the Kotlin compiler are all Apache-2.0 licensed. F-Droid builds and distributes the app entirely within its free-software build pipeline (see fdroid/de.godisch.potillus.yml), demonstrating the project is buildable with FLOSS tooling. Note: some Android SDK components (build-tools, the platform android.jar) are under the non-OSI Android SDK License — a well-known caveat common to all Android apps — but the project itself introduces no proprietary build tools. The iOS build likewise relies on FLOSS or freely-available tooling: the open-source Swift toolchain and Swift Package Manager, XcodeGen (MIT), and SwiftLint (MIT); Xcode itself is the platform's free IDE.

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 iOS side mirrors this: a broad PotillusKit unit-test suite plus app-target tests, sharing golden vectors with Android so the two implementations are held to the same expected results.

The test suite is invoked in the standard way for a Gradle/Android project: ./gradlew test runs the JVM unit tests and ./gradlew connectedCheck runs the instrumented tests on a device or emulator. This conventional invocation is documented in CONTRIBUTING.md (Section 5, "Testing strategy", and the change-submission checklist in Section 2). URL: https://codeberg.org/godisch/potillus/src/branch/main/CONTRIBUTING.md The iOS tests are invoked the standard way too: swift test runs the PotillusKit unit tests, and the app-target tests run under xcodebuild. Both are wired into the Makefile's iOS targets.

The project has an automated test suite (JVM unit tests plus instrumented tests) covering the major functionality; statement coverage of the unit-testable code is ~97% (Kover), enforced via koverVerify.

The project has a written policy that new functionality ships with tests. CONTRIBUTING.md §5 ("Testing strategy") states that the domain layer is the coverage floor and that new domain logic ships with its own tests, and §2 (step 3) makes passing the tests and following the §5 testing conventions a precondition for accepting any change. See https://codeberg.org/godisch/potillus/src/branch/main/CONTRIBUTING.md#5-testing-strategy

The add-tests policy is demonstrably followed. The test tree mirrors the source almost one-to-one: each non-trivial domain and utility class has a dedicated test (AlcoholCalculator, DayResolver, ChartBucketing, Trend, LocaleDetector, BackupManager, CsvExporter, …), every ViewModel has its own test class, schema changes are guarded by MigrationTest, and new locales/strings are guarded by LocaleSyncTest, which fails the build if a translation is incomplete. Recent releases include this test and QA work (see CHANGELOG.md). The commit history shows feature changes landing together with their tests. Tests: https://codeberg.org/godisch/potillus/src/branch/main/android/app/src/test

The project's documented instructions for change proposals include the test-addition policy. CONTRIBUTING.md §2 ("Submitting changes"), step 3, states that per the mandatory test policy in §5, major new functionality MUST include automated tests covering it in the same change, and that ./gradlew test must pass and the release gate must stay green. The full policy is defined in §5. URL: https://codeberg.org/godisch/potillus/src/branch/main/CONTRIBUTING.md#2-submitting-changes

The project enables both a linter and strict compiler warnings, using FLOSS tools. Android Lint is run as a build gate (./gradlew lintDebug) configured in android/app/build.gradle.kts with abortOnError = true and warningsAsErrors = true, so lint warnings fail the build. In addition, the Kotlin compiler is configured with allWarningsAsErrors.set(true), promoting every compiler warning to a build-breaking error. The project deliberately uses no lint baseline (no silent suppression); the few exceptions are explicit and documented in the build file. See https://codeberg.org/godisch/potillus/src/branch/main/android/app/build.gradle.kts

Warnings are addressed by construction: because Android Lint is configured with warningsAsErrors = true and the Kotlin compiler with allWarningsAsErrors = true, any unaddressed warning breaks the build, so a release cannot be produced with outstanding warnings and the source tree stays warning-free. The few deliberate exceptions are explicit and reviewable in android/app/build.gradle.kts rather than hidden in a suppression baseline. See https://codeberg.org/godisch/potillus/src/branch/main/android/app/build.gradle.kts

The project is maximally strict with warnings. The Kotlin compiler runs with allWarningsAsErrors = true, so every compiler warning fails the build, and Android Lint runs with warningsAsErrors = true and abortOnError = true, promoting every lint warning to a build-breaking error. Rather than suppressing warnings, the project removes their causes and re-enables checks once underlying tooling bugs are fixed (e.g. the PluralsCandidate and WrongStartDestinationType lint checks were restored after workarounds were no longer needed). ktlint was additionally added as a style checker. URL: https://codeberg.org/godisch/potillus/src/branch/main/android/app/build.gradle.kts

The project's primary developer (a Debian Developer) knows how to design secure software, and the application embodies established secure-design principles: least privilege and minimized attack surface (no network permission at all, no camera/microphone/location, and API 30 chosen so that even storage runtime permissions are unnecessary); fail-safe/secure defaults and data minimization (offline-only, no analytics or crash reporting, data confined to the app sandbox and encrypted at rest); reliance on vetted cryptography rather than home-grown implementations (hardware-backed Android Keystore, encrypted DataStore); defensive input validation and fail-secure behaviour (the JSON backup importer rejects too-new files and reads optional fields defensively, enums deserialize via runCatching{…}.getOrDefault(…)); and open design (fully GPL-3.0-or-later open source and auditable).

A primary developer knows the common error classes that lead to vulnerabilities in an Android application (cf. the OWASP Mobile Top 10) and at least one mitigation for each, as reflected in the code: injection is avoided by using Room's parameterized queries rather than string concatenation; insecure data storage is mitigated by the app sandbox, encryption at rest, and keeping sensitive keys in the hardware-backed Android Keystore; unsafe deserialization / missing input validation is mitigated by defensive backup-import parsing (optional-field fallbacks, rejection of too-new files via VersionTooHigh, and runCatching{…}.getOrDefault(…) for enums); excessive attack surface is mitigated by a minimal permission profile with no network permission; insecure IPC is avoided by not exporting unnecessary components; and weak/home-grown cryptography is avoided by relying on the platform's vetted cryptographic facilities.

The only cryptography the software uses is AES-256 in GCM mode (AES/GCM/NoPadding) to encrypt the preferences at rest, with the key held in the Android Keystore. These are publicly published, expert-reviewed standards (NIST FIPS 197 for AES, NIST SP 800-38D for GCM); no proprietary or home-grown algorithms are used. See android/app/src/main/kotlin/de/godisch/potillus/data/security/KeystoreSecretStore.kt The iOS implementation likewise uses only published, standard algorithms (AES-256-GCM via Apple's CryptoKit); no proprietary cryptography is introduced.

The application's primary purpose is alcohol tracking, not cryptography. It calls only platform-provided cryptographic facilities — javax.crypto.Cipher and KeyGenerator, with keys managed by the Android Keystore via KeyGenParameterSpec/KeyProperties — and does not re-implement any cryptographic primitives. Key generation, IV generation, encryption/decryption, and the GCM authentication tag are all handled by the platform provider. See android/app/src/main/kotlin/de/godisch/potillus/data/security/KeystoreSecretStore.kt On iOS the same holds: the app calls only platform cryptography — Apple's CryptoKit (AES.GCM) for sealing the preferences and the Security-framework Keychain for the key — and re-implements no primitives. See ios/PotillusKit/Sources/PotillusKit/Data/PreferencesStore.swift and SecretKeyProviding.swift.

The only crypto-dependent functionality — encrypting the preferences at rest with AES-256-GCM through the standard JCA interface (javax.crypto.Cipher / KeyGenerator) — relies on open standards for which FLOSS implementations exist (e.g. BouncyCastle, Conscrypt). Nothing depends on a proprietary, non-replaceable cryptographic component, so all cryptography-dependent functionality is implementable using FLOSS.

The security mechanism uses AES with a 256-bit key (setKeySize(256) in the KeyGenParameterSpec), which far exceeds the NIST minimum keylength requirements through 2030. Smaller keylengths are not merely non-default but impossible: the key is generated at a fixed 256-bit size inside the Android Keystore and there is no configuration path to any smaller length, so shorter keylengths are completely disabled by construction. See android/app/src/main/kotlin/de/godisch/potillus/data/security/KeystoreSecretStore.kt The iOS side matches: the key is a CryptoKit SymmetricKey fixed at 256 bits (SymmetricKey(size: .bits256)), with no configuration path to a smaller length.

The default (and only) security mechanism uses AES-256-GCM; it depends on none of the broken algorithms named by the criterion (no MD4/MD5, single DES, RC4, or Dual_EC_DRBG). GCM is an AEAD cipher mode that is appropriate for the context (authenticated encryption of data at rest), used correctly with a fresh random 96-bit IV per encryption and a 128-bit authentication tag — not ECB and not a static IV. See android/app/src/main/kotlin/de/godisch/potillus/data/security/KeystoreSecretStore.kt On iOS the CryptoKit AES-GCM seal/open round-trip is covered by the PotillusKit test suite, so the encryption path is exercised, not just assumed.

The software's default security mechanisms use only strong, modern cryptography and none of the known-weak algorithms or modes. The encrypted preferences store uses AES-256 in GCM (authenticated encryption) — not ECB, CBC, DES/3DES, or RC4 — with the key held in the hardware-backed Android Keystore, a 96-bit random IV per encryption drawn from a cryptographically secure RNG, and a 128-bit authentication tag. No weak hash functions (e.g. MD5 or SHA-1) are used in the security mechanisms. URL: https://codeberg.org/godisch/potillus/src/branch/main/android/app/src/main/kotlin/de/godisch/potillus/data/security/KeystoreSecretStore.kt The iOS path uses the same modern AEAD construction (AES-256-GCM via CryptoKit), avoiding the broken or weak algorithms the criterion warns against.

Not applicable: the software performs no key agreement and has no network protocol or sessions. It only encrypts local data at rest using a symmetric AES-256-GCM key stored in the Android Keystore. Perfect forward secrecy concerns session keys derived via key-agreement protocols, which this application does not use, so the criterion does not apply.

Not applicable: the application does not authenticate external users and stores no passwords. It is a local, single-user app with no accounts, login, or server component. The optional biometric fingerprint lock is a device-local access gate via the Android BiometricPrompt API and stores or hashes no password, so there is no password storage to which this criterion could apply.

All cryptographic keys and nonces are generated by the platform's cryptographically secure provider, not by an insecure generator (e.g. java.util.Random). The AES-256 key is generated inside the Android Keystore via KeyGenerator/KeyGenParameterSpec, and the 96-bit GCM IV is produced fresh per encryption by the crypto provider (cipher.iv), enforced by setRandomizedEncryptionRequired(true); no caller-chosen or static IV is used. See android/app/src/main/kotlin/de/godisch/potillus/data/security/KeystoreSecretStore.kt On iOS the AES-256 key is created by CryptoKit's SymmetricKey(size: .bits256) and each GCM nonce is generated fresh by CryptoKit per seal (AES.GCM.seal), never caller-chosen or static — the same secure-provider guarantee.

The project uses MITM-resistant delivery for both source and application. The source repository is cloned and browsed over HTTPS (or SSH) from Codeberg. The app is distributed via F-Droid over HTTPS, and F-Droid additionally signs all packages and verifies the signature on install and update, protecting integrity even against a compromised transport path. Repository: https://codeberg.org/godisch/potillus — distribution: https://f-droid.org/packages/de.godisch.potillus

The project does not retrieve a cryptographic hash over HTTP and use it without a signature check. Distribution via F-Droid relies on cryptographically signed packages and a signed repository index, so integrity is verified through signatures rather than an unsigned hash fetched over HTTP; source is obtained from Codeberg over HTTPS. There is no point in the delivery process where an HTTP-retrieved hash is used without signature verification.

There are no unpatched vulnerabilities of medium or higher severity that have been publicly known for more than 60 days. No CVEs have been filed against the application, and its network-free, minimal-permission architecture keeps the attack surface small; dependencies are kept current. The maintainer confirms no such known unpatched vulnerabilities exist.

No critical vulnerabilities have been reported to date, so none remain unfixed. A process to handle them promptly is in place: SECURITY.md defines a private reporting channel with a 14-day acknowledgement commitment and coordinated fix/disclosure, and the project's regular release cadence demonstrates the ability to ship fixes quickly. See https://codeberg.org/godisch/potillus/src/branch/main/SECURITY.md

The public repository leaks no valid private credentials. It contains no keystore or private-key files (no .jks/.keystore/.pem/.p12, no real keystore.properties) and no hard-coded passwords or API keys. Release signing material and the Google Play service-account key are explicitly git-ignored (/android/keystore.properties, /fastlane/play-store-credentials.json) and marked "SECRET, never commit"; only a documented placeholder template (android/keystore.properties.example) is committed, and the Play key is referenced only by path/SUPPLY_JSON_KEY, never embedded.

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 The iOS counterpart is SwiftLint, pinned to a fixed version (0.65.0) and run in --strict mode as a release gate (check-swiftlint), so a warning fails the build; seven project-specific Python linters add header, localisation, and parity checks on top.

The static analysis tool used for static_analysis — Android Lint — includes a dedicated set of security detectors that look for common Android-environment vulnerabilities (e.g. exported components and permission issues, cleartext traffic, hardcoded credentials, weak cryptography, unsafe WebView/TrustManager patterns, and SQL-injection/path-traversal hints). The build runs Lint with abortOnError = true and warningsAsErrors = true, so such findings are enforced as build-breaking errors rather than merely reported. This is complemented by osv-scanner dependency scanning (SECURITY.md, "Dependency monitoring"). URL: https://codeberg.org/godisch/potillus/src/branch/main/android/app/build.gradle.kts

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

Not applicable. The software is written entirely in Kotlin running on the memory-safe JVM/ART runtime, with automatic memory management and no manual allocation, pointer arithmetic, or buffer handling. The project produces no memory-unsafe (C/C++/NDK) code, so there is no unsafe memory use for a dynamic analysis tool to detect.

Not met (SHOULD). The criterion targets fault detection during dynamic analysis (testing), not production. The produced code contains a small number of always-on Kotlin preconditions (require/check/error) that are checked whenever the code runs, including under the test suite, but not "many". Remediation (tracked in docs/ROADMAP.md): add invariant assertions in the JVM-testable domain and data layers using Kotlin assert(), which Gradle's unit-test task runs with assertions enabled (-ea) by default, so they are checked during dynamic analysis while remaining disabled in ART release builds.

Not applicable: the project's dynamic analysis (its instrumented and unit test runs) has not surfaced any exploitable vulnerabilities of medium or higher severity, so there are none to fix. Should any be found, the project's practice of blocking releases on failing tests means they would be addressed before the next release.