Libellus Potionis

The project provides a clear, low-friction upgrade path to newer versions. The app is distributed via F-Droid (with Google Play planned), where users receive and install updates through the store's normal update mechanism, with no manual steps. User data is carried forward automatically across versions by versioned Room database migrations, which are covered by an instrumented MigrationTest, so upgrading never loses data. Because the upgrade path is straightforward, no separate upgrade documentation is required; as a mobile app, only the newest version is distributed, so maintaining older versions in parallel is unnecessary.

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

Not applicable. No externally reported security vulnerabilities have been resolved in the last 12 months, so there are no reporters to credit. Should this change, the project's practice is to credit reporters of resolved vulnerabilities unless they request anonymity; the reporting channel is documented in SECURITY.md.

The project has a documented vulnerability-response process in SECURITY.md. It specifies a private, PGP-encrypted reporting channel to android@godisch.de (with the maintainer's published PGP fingerprint obtained from the official Debian keyserver) kept separate from the public issue tracker, states what a report should include, commits to acknowledging reports within 14 days followed by assessment and response, and defines the scope of what qualifies as a security issue. URL: https://codeberg.org/godisch/potillus/src/branch/main/SECURITY.md

The project identifies a specific coding style guide for its primary language and requires general compliance. CONTRIBUTING.md §4 ("Coding conventions") directs contributors to follow the official Kotlin coding conventions (kotlinlang.org/docs/coding-conventions.html) and adds project-specific rules (mandatory KDoc on public API, constant placement, default-value consistency, enum persistence by name). Compliance is required through the review process (§2 makes the documented conventions a merge condition) and is partly enforced automatically via Kotlin's allWarningsAsErrors and Android Lint's warningsAsErrors gates. URL: https://codeberg.org/godisch/potillus/src/branch/main/CONTRIBUTING.md#4-coding-conventions

The project automatically enforces its selected Kotlin coding style using ktlint (a FLOSS tool), integrated via the org.jlleitschuh.gradle.ktlint Gradle plugin. Style settings are defined in the repository-root .editorconfig (official Kotlin conventions). The ktlintCheck task runs as part of the standard check lifecycle and fails on violations, and ktlintFormat auto-formats sources; CONTRIBUTING.md §4 documents this for contributors. Enforcement is build-time only and not on the release-assembly path, so reproducible builds are preserved.

Not applicable. The project does not generate any native binaries: there is no externalNativeBuild, CMake, or NDK configuration and no C/C++ sources — the app is pure Kotlin/JVM. The only .so references are in a jniLibs packaging block that excludes two precompiled shared libraries shipped by AndroidX dependencies; the project compiles no native code itself, so there are no compiler/linker invocations to honor CC/CFLAGS/LDFLAGS.

Not applicable. The project generates no native binaries (no NDK/CMake/externalNativeBuild and no C/C++ sources), so there is no native debugging information to preserve or strip. Kotlin/JVM debugging metadata is handled by the standard toolchain rather than by native compiler flags.

The project builds with Gradle, not make. Gradle constructs a single directed acyclic task graph for the whole project during configuration and resolves dependencies across the entire build, which is the non-recursive build model this criterion calls for; the pitfalls of recursive make do not apply. The build comprises a single application module (:app) declared in settings.gradle.kts, so there is no recursive subdirectory building. (Because the project does not use make, N/A would also be a defensible selection.)

The project has a reproducible build and this is verified externally: the app is built from source and distributed via F-Droid, whose reproducible-builds process rebuilds the app and compares it bit-for-bit against the published artifact. The build is deterministic by design — the Gradle version catalog (libs.versions.toml) pins all dependency and plugin versions, and AGP/Kotlin/KSP are pinned. Determinism is actively protected: the foojay JDK auto-provisioning resolver was deliberately removed (and must not be re-added) because it would make builds network-dependent and non-reproducible, and build-time-only steps (SBOM generation, jniLibs packaging exclusions, and the newly added ktlint check) are kept off the release-assembly path so they do not affect the APK output.

The software is installed and uninstalled using the platform's standard convention for Android apps. Installation is via F-Droid (with Google Play planned), the platform's package-manager/app-store mechanism, or by side-loading the signed APK; uninstallation uses Android's built-in uninstall flow (long-press the app or Settings → Apps). The app installs no system or root components and stores all data in its sandbox, so a normal uninstall removes it completely. The README "Quick start" documents the installation path.

Not applicable. DESTDIR/PREFIX-style variables apply to make install-type installations into filesystem prefixes (typical of C/Autotools projects). An Android application has no such installation system: where the app is placed is decided by the operating system's package installer (F-Droid/Play/the Android package manager), not by a project-provided install step, so there is no location-selection stage that could honor DESTDIR or PREFIX.

It is easy to get started developing the software. The project is a standard Android Gradle project: cloning the repository and running the bundled Gradle wrapper (./gradlew) builds it with no manual Gradle installation, and all dependency and plugin versions are pinned in the version catalog with repositories preconfigured in settings.gradle.kts, so a fresh checkout builds without additional setup. Developers can import it into Android Studio or run ./gradlew assembleDebug and installDebug to see changes on an emulator or device. CONTRIBUTING.md (architecture, build/test commands, release checklist) and the README's "Technical Aspects" document the path from clone to a running build.

External dependencies are declared in a computer-processable, versioned form and are obtained automatically by a standard build. The Gradle version catalog (android/gradle/libs.versions.toml) pins every library and plugin version in its [versions], [libraries], and [plugins] tables, referenced via alias(libs.…) in the build scripts; settings.gradle.kts configures the repositories (google, mavenCentral, gradlePluginPortal), so ./gradlew resolves and downloads all declared dependencies with no manual steps. The build additionally generates a CycloneDX 1.6 JSON SBOM of the release dependencies as a standardized machine-readable inventory. URL: https://codeberg.org/godisch/potillus/src/branch/main/android/gradle/libs.versions.toml

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

The project uses externally-maintained components throughout, declared and version-pinned in the Gradle version catalog, with no vendored/convenience copies of third-party source that could silently go stale. The stack is kept current (modern AndroidX/Jetpack/Compose libraries, AGP 9 with built-in Kotlin, KSP), keeping it up to date is an explicit roadmap goal ("stay current and maintained"), and the documented pre-release osv-scanner check (see SECURITY.md, "Dependency monitoring") prevents the project from locking itself into outdated versions with known vulnerabilities, since findings are resolved by upgrading. URL: https://codeberg.org/godisch/potillus/src/branch/main/android/gradle/libs.versions.toml

The project avoids deprecated or obsolete APIs and enforces this automatically: Kotlin's allWarningsAsErrors and Android Lint's warningsAsErrors promote deprecation warnings to build-breaking errors, so using a deprecated API fails the build. The technology stack is modern and actively maintained (current Jetpack Compose/AndroidX APIs, KSP instead of the older kapt, minSdk 30 avoiding legacy-compatibility workarounds), and the roadmap goal of staying current keeps the interfaces in use aligned with upstream releases. URL: https://codeberg.org/godisch/potillus/src/branch/main/android/app/build.gradle.kts

Met. For well over 50% of the bugs fixed in the recent release history, the project added a regression test or an automated check that prevents recurrence. Examples of regression tests: LocaleFormattingInstrumentedTest (added with the fix for incorrect system-language number/date formatting in exports on API 30–32), NumberFormatTest (pinning the decimal separator after a locale-dependent formatting bug), and a white-box assertion in BackupRepositoryInstrumentedTest added with a backup fix. In addition, defect fixes were routinely paired with new invariants in the automated release-check gate (tools/release-check.sh) — e.g. version-string and locale-consistency checks and current-version locale-coverage checks — and with re-enabled lint checks (such as PluralsCandidate) that catch the class of bug going forward. Together these mean the majority of recent fixes are covered by automated regression protection.

The JVM unit-test suite reaches ~97% statement (line) coverage, measured with Kover over the unit-testable code. Android-runtime-bound code (Compose UI, Room database/DAOs, DataStore preferences, Keystore, PDF/WebView rendering, and MediaStore import/export) is excluded from this figure and verified instead by the instrumented suite (src/androidTest). A build-breaking 90% line floor is enforced by the koverVerify Gradle task in the release gate (make cover-check). Methodology: CONTRIBUTING.md §5; scope/enforcement: app/build.gradle.kts.

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'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 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 implements secure design principles. Least privilege / minimal attack surface: the app holds no network permission and requests no camera, microphone, location, contacts, or runtime-storage permissions. Secure defaults: it is offline-only with no tracking, analytics, or ads by design; data stays in the app sandbox; and the preferences store is sealed with an AES-256-GCM key in the hardware-backed Android Keystore. Economy of mechanism: a small, focused architecture with a framework-free domain layer and no unnecessary services. Fail-safe input handling: importers validate input and the CSV exporter neutralizes formula injection (OWASP "CSV Injection"), with migration tests protecting data integrity. Defense in depth: an optional biometric lock supplements the platform sandbox. These are documented in SECURITY.md ("Security model") and PRIVACY.md. URL: https://codeberg.org/godisch/potillus/src/branch/main/SECURITY.md#security-model

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

Not applicable. The application processes no authentication credentials (no passwords, tokens, logins, or network authentication) and stores no key files. Its only cryptographic key is an AES-256-GCM key generated inside the hardware-backed Android Keystore; the raw key material never leaves the secure hardware and is never written to a file, so there are no user-managed credential or key files to store separately or replace without recompilation. (For context, the Keystore key is already isolated from configuration, database, and logs and could be rotated by deleting its alias, but this is not user-facing credential management.)

Not applicable. The application performs no network communication: it does not declare the INTERNET permission, works entirely offline, and transmits no data. There are therefore no network protocols whose security could be assessed.

Not applicable. The application does not use TLS because it performs no network communication at all (no INTERNET permission, offline-only). There is no TLS configuration or version to assess.

Not applicable. The application does not use TLS and performs no network communication (no INTERNET permission, offline-only), so there are no TLS connections and no certificate verification to assess.

Not applicable. The application does not use TLS and performs no network communication (no INTERNET permission, offline-only); it never sends HTTP headers or any private information over a network, so there is nothing to verify before transmission.

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

Release tags are cryptographically signed and verifiable. Per the CONTRIBUTING.md §7 release checklist, each release tag is created as a GPG-signed annotated tag (git tag -s) using the maintainer's key (fingerprint 1842 323B 4FCF 9B90 995F A17F A350 B991 F05A 4857, available from keyring.debian.org — the same key used for security reports); the checklist also documents enabling git config tag.gpgSign true so annotated tags are signed automatically. SECURITY.md ("Verifying releases") documents how to import the key and verify a tag with git tag -v. URL: https://codeberg.org/godisch/potillus/src/branch/main/SECURITY.md#verifying-releases

The application validates inputs from its potentially untrusted sources using an allowlist approach. JSON backup/import is validated on restore (structure and values) and invalid or foreign data is rejected, covered by BackupRepositoryInstrumentedTest. Numeric user inputs (drink amounts, body weight, limits) are checked for valid ranges/format, with the amount dialog entering a controlled error state rather than accepting bad values, and locale-dependent number parsing is handled deliberately (regression-tested by NumberFormatTest). Room migrations validate the database schema on upgrade (MigrationTest). As output-side hardening, the CSV exporter neutralizes formula injection (OWASP "CSV Injection"). Since the app uses no network, its untrusted inputs are essentially user entries and imported files, both of which are validated.

Met. Release builds apply R8 code shrinking and obfuscation (isMinifyEnabled = true) with resource shrinking and the optimizing ProGuard configuration. The manifest sets android:allowBackup="false" to prevent backup-based data exfiltration, and the app applies WindowManager FLAG_SECURE by default from cold start to block screenshots, screen recording, and Recents-thumbnail exposure. The permission set is minimal (no network or telephony; only USE_BIOMETRIC) and only the launcher activity is exported. These complement the hardware-backed Keystore at-rest encryption and the warnings-as-errors/lint gate. URL: https://codeberg.org/godisch/potillus/src/branch/main/android/app/build.gradle.kts

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

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

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.