Libellus Potionis

Projects that follow the best practices below can voluntarily self-certify and show that they've achieved an Open Source Security Foundation (OpenSSF) best practices badge.

There is no set of practices that can guarantee that software will never have defects or vulnerabilities; even formal methods can fail if the specifications or assumptions are wrong. Nor is there any set of practices that can guarantee that a project will sustain a healthy and well-functioning development community. However, following best practices can help improve the results of projects. For example, some practices enable multi-person review before release, which can both help find otherwise hard-to-find technical vulnerabilities and help build trust and a desire for repeated interaction among developers from different companies. To earn a badge, all MUST and MUST NOT criteria must be met, all SHOULD criteria must be met OR be unmet with justification, and all SUGGESTED criteria must be met OR unmet (we want them considered at least). If you want to enter justification text as a generic comment, instead of being a rationale that the situation is acceptable, start the text block with '//' followed by a space. Feedback is welcome via the GitHub site as issues or pull requests There is also a mailing list for general discussion.

We gladly provide the information in several locales, however, if there is any conflict or inconsistency between the translations, the English version is the authoritative version.
If this is your project, please show your baseline badge status on your project page! The baseline badge status looks like this: Baseline badge level for project 13480 is baseline-2 Here is how to embed the baseline badge:
You can show your baseline badge status by embedding this in your markdown file:
[![OpenSSF Baseline](https://www.bestpractices.dev/projects/13480/baseline)](https://www.bestpractices.dev/projects/13480)
or by embedding this in your HTML:
<a href="https://www.bestpractices.dev/projects/13480"><img src="https://www.bestpractices.dev/projects/13480/baseline"></a>


These are the Baseline Level 1 criteria. These are criteria version v2026.02.19.

Baseline Series: Baseline Level 1 Baseline Level 2 Baseline Level 3

        

 Basics

  • General

    Note that other projects may use the same name.

    Libellus Potionis is a privacy-first, free, open-source, ad-free alcohol-consumption tracker that helps users monitor, pace, and manage their drinking habits entirely offline. It needs no invasive device permissions — no camera, microphone, or location access — and works completely without network connectivity.

    Key features

    • Intelligent logging: predefine custom beverages or use internationally common presets, and log drinks instantly or retroactively with precise timestamp corrections.
    • Concurrent limit tracking: set three simultaneous boundaries — a daily limit (grams of pure alcohol), a rolling 7-day weekly limit (grams), and a maximum number of drinking days per week — with visual progress bars in real time.
    • Blood-alcohol (BAC) estimation: enter your body weight for a live BAC approximation based on the established Widmark formula.
    • Addiction-counseling reports: generate a clear, well-organized two-page PDF report designed for consultations and counseling appointments.
    • Data portability: export your complete dataset as a standard CSV file for external processing (e.g. in LibreOffice Calc), or create secure JSON backups to migrate data between devices.
    • Granular adjustments: customize your "day start" time so late-night drinks count toward the correct evening, and define custom evaluation start dates for clean restarts.

    A comprehensive User's Guide is fully accessible in-app. The app is available on F-Droid.

    Please use SPDX license expression format; examples include "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "GPL-2.0+", "LGPL-3.0+", "MIT", and "(BSD-2-Clause OR Ruby)". Do not include single quotes or double quotes.
    If there is more than one language, list them as comma-separated values (spaces optional) and sort them from most to least used. If there is a long list, please list at least the first three most common ones. If there is no language (e.g., this is a documentation-only or test-only project), use the single character "-". Please use a conventional capitalization for each language, e.g., "JavaScript".
    The Common Platform Enumeration (CPE) is a structured naming scheme for information technology systems, software, and packages. It is used in a number of systems and databases when reporting vulnerabilities.

    Libellus Potionis is a privacy-first, offline, ad-free Android app for tracking, pacing, and managing alcohol consumption. It requests no network permission and no camera/microphone/location access; all data stays on the device in the app's private, sandboxed storage, encrypted at rest (AES-256-GCM via the Android Keystore), with an optional biometric lock. It is Free Software under GPL-3.0-or-later, developed openly on Codeberg and distributed through F-Droid. The project is deliberately maintained as a teaching-quality codebase: every source file carries a license header and KDoc, and a release gate (tools/release-check.sh) enforces documentation, version consistency, English-only source, and translation completeness. Quality is guarded by a broad automated test suite (JVM unit tests plus instrumented Room-migration, Compose-UI, and locale tests) and by Android Lint and Kotlin compiler warnings promoted to build-breaking errors.

 Controls 24/24 ●

  • Controls


    Enough for a badge!

    When a user attempts to read or modify a sensitive resource in the project's authoritative repository, the system MUST require the user to complete a multi-factor authentication process. [OSPS-AC-01.01]
    Enforce multi-factor authentication for the project's version control system, requiring collaborators to provide a second form of authentication when accessing sensitive data or modifying repository settings. Passkeys are acceptable for this control.

    Write (push) access to the canonical repository (hosted on Codeberg) requires two-factor authentication as a documented project policy: docs/GOVERNANCE.md ("Repository access and account security") states that any account with write access MUST have cryptographic 2FA enabled. Currently the sole maintainer is the only account with write access and has 2FA enabled; the policy binds any future account granted write access. Codeberg additionally blocks plain-password HTTP/S git operations once 2FA is enabled, so access requires a token or SSH key. The forge offers no per-project 2FA enforcement toggle, so the requirement is enforced by written policy. Reference: https://codeberg.org/godisch/potillus/src/branch/main/docs/GOVERNANCE.md [require_2FA]


    Enough for a badge!

    When a new collaborator is added, the version control system MUST require manual permission assignment, or restrict the collaborator permissions to the lowest available privileges by default. [OSPS-AC-02.01]
    Most public version control systems are configured in this manner. Ensure the project's version control system always assigns the lowest available permissions to collaborators by default when added, granting additional permissions only when necessary.

    On Codeberg (Forgejo), collaborators are never added automatically: the repository owner must explicitly invite each collaborator and manually assign an access level (Read/Write/Admin); there is no automatic addition or privilege escalation. The project also currently has a single maintainer, so no additional collaborators with elevated access exist. The set of accounts with write access is documented in docs/GOVERNANCE.md. Any future collaborator therefore requires a deliberate, manual permission grant by the owner.


    Enough for a badge!

    When a direct commit is attempted on the project's primary branch, an enforcement mechanism MUST prevent the change from being applied. [OSPS-AC-03.01]
    If the VCS is centralized, set branch protection on the primary branch in the project's VCS. Alternatively, use a decentralized approach, like the Linux kernel's, where changes are first proposed in another repository, and merging changes into the primary repository requires a specific separate act.

    The primary branch (main) on the project's Codeberg repository has a branch-protection rule that permits changes only through pull requests; direct pushes are rejected server-side by the forge's pre-receive enforcement, which on Codeberg/Forgejo applies to repository admins and the owner as well. All changes to main therefore go through a pull request, satisfying the enforcement requirement even though the project currently has a single maintainer.


    Enough for a badge!

    When an attempt is made to delete the project's primary branch, the version control system MUST treat this as a sensitive activity and require explicit confirmation of intent. [OSPS-AC-03.02]
    Set branch protection on the primary branch in the project's version control system to prevent deletion.

    The primary branch (main) is the repository's default branch and is additionally covered by a branch-protection rule. On Codeberg/Forgejo the default branch cannot be deleted at all, and a protected branch is likewise non-deletable while the rule is active; any branch deletion in the web UI further requires explicit confirmation with a permanence warning. Deleting the primary branch is therefore treated as a blocked, non-accidental action, exceeding the "require explicit confirmation of intent" requirement.


    Enough for a badge!

    When a CI/CD pipeline operates on untrusted metadata, those parameters MUST be sanitized and validated prior to use in the pipeline. [OSPS-BR-01.01]
    CI/CD pipelines should sanitize (quote, escape or exit on expected values) all metadata inputs which correspond to untrusted sources. This includes data such as branch names, commit messages, tags, pull request titles, and author information.

    The project currently operates no automated, event-triggered CI/CD pipeline: no runner processes push/pull-request events or untrusted contributor input. The only release automation (Fastlane) is invoked manually and locally by the maintainer on their own trusted working copy and does not ingest untrusted metadata. As no pipeline operates on untrusted metadata, this requirement's precondition does not occur. Should a CI pipeline (e.g. Woodpecker) be introduced, untrusted inputs (PR titles, branch names, fork payloads) will be sanitized and validated and untrusted-PR builds run without access to privileged credentials.


    Enough for a badge!

    When a CI/CD pipeline operates on untrusted code snapshots, it MUST prevent access to privileged CI/CD credentials and assets. [OSPS-BR-01.03]
    CI/CD pipelines should isolate untrusted code snapshots from privileged credentials and assets. In particular, projects should be careful to ensure that workflows which build or execute code prior to review by a collaborator do not have access to CI/CD credentials.

    The project operates no automated CI/CD pipeline that builds untrusted code snapshots (e.g. pull requests from forks); no runner executes contributor-supplied code. Release automation (Fastlane) is invoked manually and locally by the maintainer against their own trusted checkout, and privileged credentials (release-signing keystore, store-upload keys) exist only in the maintainer's local, git-ignored keystore.properties, never exposed to a pipeline. As no pipeline operates on untrusted code snapshots, this requirement's precondition does not occur. A future CI pipeline (Woodpecker) will run untrusted-PR builds without access to privileged credentials — recorded in docs/ROADMAP.md.


    Enough for a badge!

    When the project lists a URI as an official project channel, that URI MUST be exclusively delivered using encrypted channels. [OSPS-BR-03.01]
    Configure the project's websites and version control systems to use encrypted channels such as SSH or HTTPS for data transmission. Ensure all tools and domains referenced in project documentation can only be accessed via encrypted channels.

    All official project channels are served exclusively over encrypted transport. The canonical repository and issue tracker (codeberg.org/godisch/potillus) are reached over HTTPS (and Git over HTTPS/SSH), and the distribution page (f-droid.org/packages/de.godisch.potillus) is HTTPS-only; both Codeberg and F-Droid enforce HTTPS with HSTS. No project URL uses plain HTTP.


    Enough for a badge!

    When the project lists a URI as an official distribution channel, that channel MUST be protected from adversary-in-the-middle attacks using cryptographically authenticated channels. [OSPS-BR-03.02]
    Artifacts distributed by the project should be distributed through channels which ensure integrity and authenticity. Use of HTTPS for downloads, signed releases, or distribution through trusted package managers are all acceptable methods to protect against adversary-in-the-middle attacks.

    The distribution channel is protected against adversary-in-the-middle attacks by cryptographically authenticated delivery, not transport security alone. The app is published on F-Droid (f-droid.org/packages/de.godisch.potillus) over HTTPS, where F-Droid cryptographically signs its repository index and signs the APK. The build is reproducible: F-Droid rebuilds the app from the published GPL-licensed source and verifies the result bit-for-bit against the developer-signed APK before publishing, so the distributed binary is provably the one built from public source. Clients therefore verify a signed index and a signed package whose provenance is independently reproducible. Codeberg source access is likewise HTTPS-only.


    Enough for a badge!

    The project MUST prevent the unintentional storage of unencrypted sensitive data, such as secrets and credentials, in the version control system. [OSPS-BR-07.01]
    Configure .gitignore or equivalent to exclude files that may contain sensitive information. Use pre-commit hooks and automated scanning tools to detect and prevent the inclusion of sensitive data in commits.

    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. [no_leaked_credentials]


    Enough for a badge!

    When the project has made a release, the project documentation MUST include user guides for all basic functionality. [OSPS-DO-01.01]
    Create user guides or documentation for all basic functionality of the project, explaining how to install, configure, and use the project's features. If there are any known dangerous or destructive actions available, include highly-visible warnings.

    The project provides basic user documentation. A comprehensive, screen-by-screen User's Guide (android/docs/guide/usersguide.md.in, localized into ~20 languages) explains every screen and feature — Today, Calendar, Statistics, Drinks, and Settings (limits, backup/restore, security, appearance) — and is rendered and displayed inside the app itself (via tools/render-guide.py, shown in DocumentViewerScreen). The README additionally documents the app's purpose, feature set, platform requirements (Android 11+), and how to obtain it. Source: https://codeberg.org/godisch/potillus/src/branch/main/android/docs/guide/usersguide.md.in and https://codeberg.org/godisch/potillus/src/branch/main/README.md [documentation_basics]


    Enough for a badge!

    When the project has made a release, the project documentation MUST include a guide for reporting defects. [OSPS-DO-02.01]
    It is recommended that projects use their VCS default issue tracker. If an external source is used, ensure that the project documentation and contributing guide clearly and visibly explain how to use the reporting system. It is recommended that project documentation also sets expectations for how defects will be triaged and resolved.

    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) [report_process]


    Enough for a badge!

    While active, the project MUST have one or more mechanisms for public discussions about proposed changes and usage obstacles. [OSPS-GV-02.01]
    Establish one or more mechanisms for public discussions within the project, such as mailing lists, instant messaging, or issue trackers, to facilitate open communication and feedback.

    Discussion of proposed changes and issues takes place in the project's Codeberg issue tracker and pull requests (https://codeberg.org/godisch/potillus/issues). This mechanism is full-text searchable; every issue, pull request, and comment is addressable by a stable URL; any person with a free Codeberg account can open issues and join the discussion; and it is used entirely through a web browser, requiring no proprietary client-side software (Codeberg runs the FLOSS Forgejo platform). [discussion]


    Enough for a badge!

    While active, the project documentation MUST include an explanation of the contribution process. [OSPS-GV-03.01]
    Create a CONTRIBUTING.md or CONTRIBUTING/ directory to outline the contribution process including the steps for submitting changes, and engaging with the project maintainers.

    The contribution process is documented in CONTRIBUTING.md, Section 2 "Submitting changes": contributors open an issue to discuss the change, then submit it as a pull request against main on Codeberg (a patch by e-mail is accepted as an alternative); the change must meet the documented architecture, coding, testing, and translation conventions, and is reviewed and merged by the maintainer. URL: https://codeberg.org/godisch/potillus/src/branch/main/CONTRIBUTING.md#2-submitting-changes [contribution]


    Enough for a badge!

    While active, the license for the source code MUST meet the OSI Open Source Definition or the FSF Free Software Definition. [OSPS-LE-02.01]
    Add a LICENSE file to the project's repo with a license that is an approved license by the Open Source Initiative (OSI), or a free license as approved by the Free Software Foundation (FSF). Examples of such licenses include the MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0, Lesser GNU General Public License (LGPL), and the GNU General Public License (GPL). Releasing to the public domain meets this control if there are no other encumbrances such as patents.

    The GPL-3.0-or-later license for the repository contents is approved by the Open Source Initiative (OSI).


    Enough for a badge!

    While active, the license for the released software assets MUST meet the OSI Open Source Definition or the FSF Free Software Definition. [OSPS-LE-02.02]
    If a different license is included with released software assets, ensure it is an approved license by the Open Source Initiative (OSI), or a free license as approved by the Free Software Foundation (FSF). Examples of such licenses include the MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0, Lesser GNU General Public License (LGPL), and the GNU General Public License (GPL). Note that the license for the released software assets may be different than the source code.

    The software is released as Free/Libre and Open Source Software under the GNU General Public License v3.0 or later (GPL-3.0-or-later). The full license text is provided in LICENSE.md, the copyright notice in COPYING.md ("either version 3 of the License, or (at your option) any later version"), and the F-Droid metadata declares License: GPL-3.0-or-later. See https://codeberg.org/godisch/potillus/src/branch/main/LICENSE.md [floss_license]


    Enough for a badge!

    While active, the license for the source code MUST be maintained in the corresponding repository's LICENSE file, COPYING file, or LICENSE/ directory. [OSPS-LE-03.01]
    Include the project's source code license in the project's LICENSE file, COPYING file, or LICENSE/ directory to provide visibility and clarity on the licensing terms. The filename MAY have an extension. If the project has multiple repositories, ensure that each repository includes the license file.

    The project's license is posted in a standard location at the repository root as LICENSE.md (full GPL-3.0-or-later text), which Codeberg/Forgejo auto-detects and displays as the project license; COPYING.md sits alongside it with the copyright notice. URL: https://codeberg.org/godisch/potillus/src/branch/main/LICENSE.md [license_location]


    Enough for a badge!

    While active, the license for the released software assets MUST be included in the released source code, or in a LICENSE file, COPYING file, or LICENSE/ directory alongside the corresponding release assets. [OSPS-LE-03.02]
    Include the project's released software assets license in the released source code, or in a LICENSE file, COPYING file, or LICENSE/ directory alongside the corresponding release assets to provide visibility and clarity on the licensing terms. The filename MAY have an extension. If the project has multiple repositories, ensure that each repository includes the license file.

    The released software assets carry the same GPL-3.0-or-later license as the source. In the repository the license is posted in a standard location at the root — LICENSE.md (full GPL-3.0-or-later text) with COPYING.md alongside — which Codeberg/Forgejo auto-detects. The license also travels with the released application: the app bundles a copyright/license notice (res/raw/copyright.md, generated from the source license via tools/render-copyright.py) that is shown in-app, and F-Droid builds the published APK from this GPL-licensed source and distributes that source alongside the binary. URL: https://codeberg.org/godisch/potillus/src/branch/main/LICENSE.md


    Enough for a badge!

    While active, the project's source code repository MUST be publicly readable at a static URL. [OSPS-QA-01.01]
    Use a common VCS such as GitHub, GitLab, or Bitbucket. Ensure the repository is publicly readable. Avoid duplication or mirroring of repositories unless highly visible documentation clarifies the primary source. Avoid frequent changes to the repository that would impact the repository URL. Ensure the repository is public.

    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. [repo_public]


    Enough for a badge!

    The version control system MUST contain a publicly readable record of all changes made, who made the changes, and when the changes were made. [OSPS-QA-01.02]
    Use a common VCS such as GitHub, GitLab, or Bitbucket to maintain a publicly readable commit history. Avoid squashing or rewriting commits in a way that would obscure the author of any commits.

    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 [repo_track]


    Enough for a badge!

    When the package management system supports it, the source code repository MUST contain a dependency list that accounts for the direct language dependencies. [OSPS-QA-02.01]
    This may take the form of a package manager or language dependency file that enumerates all direct dependencies such as package.json, Gemfile, or go.mod.

    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 [external_dependencies]


    Enough for a badge!

    Projects with multiple repositories MUST document a list of codebases that are part of the project. [OSPS-QA-04.01]
    Document any additional subproject code repositories produced by the project and compiled into a release. This documentation should include the status and intent of the respective codebase.

    The project consists of a single source repository (codeberg.org/godisch/potillus) with no Git submodules and no separate subproject repositories. As the project does not span multiple repositories, this requirement's precondition does not apply. Should the project ever split into multiple repositories, the constituent codebases would be documented (e.g. in README.md/docs/).


    Enough for a badge!

    While active, the version control system MUST NOT contain generated executable artifacts. [OSPS-QA-05.01]
    Remove generated executable artifacts in the project's version control system. It is recommended that any scenario where a generated executable artifact appears critical to a process such as testing, it should be instead be generated at build time or stored separately and fetched during a specific well-documented pipeline step.

    The version control system contains no artifacts generated by the project's own build. All build outputs (APK/AAB, AAR, .dex, .class, compiled libraries) are produced under git-ignored directories (android/build, android/app/build, android/.gradle) and are never committed. The only committed binary is gradle/wrapper/gradle-wrapper.jar, the upstream Gradle bootstrap wrapper whose in-repository presence is the Gradle-recommended practice; it is not a project-generated artifact. Its integrity is addressed under OSPS-QA-05.02.


    Enough for a badge!

    While active, the version control system MUST NOT contain unreviewable binary artifacts. [OSPS-QA-05.02]
    Do not add any unreviewable binary artifacts to the project's version control system. This includes executable application binaries, library files, and similar artifacts. It does not include assets such as graphical images, sound or music files, and similar content typically stored in a binary format.

    The only executable/library binary committed to version control is gradle/wrapper/gradle-wrapper.jar, the standard Gradle Wrapper bootstrap (committing it is Gradle's recommended practice and is required to build without a pre-installed Gradle). It is not an opaque, unreviewable blob: it is a stock Gradle Wrapper jar whose authenticity is independently verifiable via the OpenSSF/Gradle wrapper-validation tooling. The build additionally pins the Gradle distribution by cryptographic checksum in gradle/wrapper/gradle-wrapper.properties (distributionSha256Sum, with validateDistributionUrl=true), so the wrapper can only bootstrap an authenticated official Gradle release; the pinned checksum was verified against the value Gradle publishes for that release. On every Gradle update the wrapper is regenerated from the verified distribution (documented in CONTRIBUTING.md §7), so the committed jar remains a stock, verifiable wrapper regardless of version. All other binary files are content assets explicitly excluded by this control — graphical images (PNG, SVG), TTF fonts, and sample report PDFs. No executable application binaries or opaque library files are committed.


    Enough for a badge!

    While active, the project documentation MUST contain security contacts. [OSPS-VM-02.01]
    Create a security.md (or similarly-named) file that contains security contacts for the project.

    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 [vulnerability_report_process]



This data is available under the Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). This means that a Data Recipient may share the Data, with or without modifications, so long as the Data Recipient makes available the text of this agreement with the shared Data. Please credit Martin A. Godisch and the OpenSSF Best Practices badge contributors.

Project badge entry owned by: Martin A. Godisch.
Entry created on 2026-07-04 04:21:04 UTC, last updated on 2026-07-14 19:16:17 UTC. Last achieved passing badge on 2026-07-04 08:45:54 UTC.