BadgeApp

Basics

General

What is the human-readable name of the project?
Note that other projects may use the same name.

What is a brief description of the project?

Libellus Potionis is a privacy-first, free, open-source, and ad-free alcohol consumption tracker designed to help users monitor, pace, and manage their drinking habits entirely offline. It requires no invasive device permissions—no camera, microphone, or location access—and completely operates without network connectivity. It runs on both Android and iOS, and is available on F-Droid.

What is the URL for the project (as a whole)?
https://gitlab.com/godisch/potillus

What is the URL for the version control repository (it may be the same as the project URL)?
https://gitlab.com/godisch/potillus

What license(s) is the project released under?
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.

What programming language(s) are used to implement the project?
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".

What is the Common Platform Enumeration (CPE) name for the project (if it has one)?
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.
Other general comments about the project:
The two are separate native apps in this one repository — Kotlin/Jetpack Compose for Android, Swift/SwiftUI for iOS — that share the same design, the same feature set, and a common JSON backup format, so a backup exported on one platform imports on the other. Their behaviour is kept in lock-step by a shared set of golden test vectors.

Key Features
- Logging: predefine custom beverages or use internationally common presets. Log drinks instantly or retroactively with precise timestamp corrections.
- Concurrent limits: set three boundaries at once — a daily limit in grams of pure alcohol, a rolling 7-day limit in grams, and a maximum number of drinking days per week. Each has its own progress bar.
- Blood alcohol concentration (BAC): enter your body weight to get a live estimate from the Widmark formula.
- Counseling reports: generate a two-page PDF report of your consumption for a counseling appointment.
- Data portability: export the dataset as a CSV file for external processing (e.g. in LibreOffice Calc), or create JSON backups to move data between devices.
- Adjustments: set your own "day start" time, so that late-night drinks count toward the preceding evening, and an evaluation start date for a clean restart.
A User's Guide is available inside the app.

Controls 24/24 ●

Controls

Criterion [OSPS-AC-01.01]
Met

Unmet

N/A

?

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 GitLab) 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. GitLab additionally accepts no account password for git over HTTP/S at all — an access token or an SSH key is required — so a stolen password alone cannot push. Per-project 2FA enforcement is a group-level setting the project's plan does not offer, so the requirement is enforced by written policy.

Criterion [OSPS-AC-02.01]
Met

Unmet

N/A

?

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 GitLab, project members are never added automatically: a user with the Owner role must explicitly invite each member and assign a role (Guest/Reporter/Developer/Maintainer/Owner), and no role grants itself an escalation. The project also currently has a single maintainer, so no additional members 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.

Criterion [OSPS-AC-03.01]
Met

Unmet

N/A

?

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 GitLab repository is a protected branch whose "Allowed to push and merge" setting is "No one", so direct pushes are rejected server-side for every role including the project Owner, and changes reach main only through a merge request. All changes to main therefore go through a merge request, satisfying the enforcement requirement even though the project currently has a single maintainer.

Criterion [OSPS-AC-03.02]
Met

Unmet

N/A

?

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 a protected branch. On GitLab a protected branch cannot be deleted while the protection rule is active, and the default branch cannot be deleted at all; removing the protection is itself a deliberate, separately audited settings change. Deleting the primary branch is therefore treated as a blocked, non-accidental action, exceeding the "require explicit confirmation of intent" requirement.

Criterion [OSPS-BR-01.01]
Met

Unmet

N/A

?

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's CI/CD pipeline consumes no untrusted input, by construction rather than by sanitizing after the fact. .gitlab-ci.yml interpolates no forge-supplied string anywhere: no merge request title, branch name, commit message, fork payload or user-supplied variable appears in any job's script. The jobs run three fixed commands — tools/release-check.sh --Werror, make check-static and an osv-scanner source scan — each of which reads only the checked-out tree. The single CI variable the file references, CI_MERGE_REQUEST_TARGET_BRANCH_NAME, appears in a workflow: rule comparison, never in a shell command, so it cannot be interpreted as code. There is therefore no injection path from a proposed change into pipeline execution.

Criterion [OSPS-BR-01.03]
Met

Unmet

N/A

?

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.

Untrusted code snapshots cannot reach privileged credentials, because the pipeline holds none. .gitlab-ci.yml defines no secret, no protected or masked variable and no deployment credential; its three jobs are read-only checks on a plain python:3-slim image. The project's privileged credentials — the release-signing keystore, the Google Play and App Store upload keys, and the GitLab release token in fastlane/gitlab-credentials.txt — exist only in the maintainer's local, git-ignored files and are never present in a CI environment; releases are built and published manually on a trusted local checkout. A merge request from a fork therefore executes only the fixed check commands, with nothing privileged in reach. The automatic CI job token is scoped to this project alone under Settings > CI/CD > Token Access.

Criterion [OSPS-BR-03.01]
Met

Unmet

N/A

?

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 (gitlab.com/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 GitLab and F-Droid enforce HTTPS with HSTS. No project URL uses plain HTTP.

Criterion [OSPS-BR-03.02]
Met

Unmet

N/A

?

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. GitLab source access is likewise HTTPS-only. The planned Apple App Store channel likewise delivers Apple-signed packages over HTTPS; the App Store re-signs the binary with an Apple identity, so — like Google Play — the delivered artifact is not third-party-reproducible, though the underlying iOS build is verified reproducible by the two-build check in make release-ios.

Criterion [OSPS-BR-07.01]
Met

Unmet

N/A

?

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.

Criterion [OSPS-DO-01.01]
Met

Unmet

N/A

?

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 (localized into 21 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. The iOS port ships the same screen-by-screen guide (docs/guide/usersguide.ios.md), rendered inside the app, and targets iOS 17+.

Criterion [OSPS-DO-02.01]
Met

Unmet

N/A

?

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 GitLab issue tracker, with android@godisch.de offered as an alternative. This process is documented in the README's "Feedback & Contributing" section.

Criterion [OSPS-GV-02.01]
Met

Unmet

N/A

?

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 GitLab issue tracker and merge requests (gitlab.com/godisch/potillus/-/issues). This mechanism is full-text searchable; every issue, merge request, and comment is addressable by a stable URL; any person with a free GitLab account can open issues and join the discussion; and it is used entirely through a web browser, requiring no proprietary client-side software (GitLab's core is released as free software under the MIT licence).

Criterion [OSPS-GV-03.01]
Met

Unmet

N/A

?

The project documentation MUST include an explanation of the contribution process, or clearly state that public contributions are not accepted ^{[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 merge request against main on GitLab (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.

Criterion [OSPS-LE-02.01]
Met

Unmet

N/A

?

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).

Criterion [OSPS-LE-02.02]
Met

Unmet

N/A

?

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.

Criterion [OSPS-LE-03.01]
Met

Unmet

N/A

?

The license for the source code MUST be maintained in the corresponding repository's LICENSE file, COPYING file, LICENSES/ directory, or LICENSE/ directory. ^{[OSPS-LE-03.01]}
Include the project's source code license in the project's LICENSE file, COPYING file, LICENSES/ directory, 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 GitLab auto-detects and displays as the project license; COPYING.md sits alongside it with the copyright notice.

Criterion [OSPS-LE-03.02]
Met

Unmet

N/A

?

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 GitLab auto-detects. The license also travels with the released application: each package bundles the verbatim text of every license it is obliged to reproduce, copied verbatim from the project-root license files at build time (Android: res/raw/license_gpl3.md, license_apache2.md, license_gpl2.md and license_bsd3.md; iOS: license_gpl3.md), and the in-app About screen states the app's own GPL notice with the App Store Distribution Exception in full and links to each verbatim text. F-Droid builds the published APK from this GPL-licensed source and distributes that source alongside the binary.

Criterion [OSPS-QA-01.01]
Met

Unmet

N/A

?

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 at a stable URL, gitlab.com/godisch/potillus — readable without an account and cloneable over HTTPS.

Criterion [OSPS-QA-01.02]
Met

Unmet

N/A

?

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 GitLab (commit list, diffs, and blame view) at gitlab.com/godisch/potillus/-/commits/main

Criterion [OSPS-QA-02.01]
Met

Unmet

N/A

?

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 iOS port declares its dependencies the same way: ios/PotillusKit/Package.swift names them and ios/PotillusKit/Package.resolved pins each to an exact version and revision, which SwiftPM resolves automatically. Both builds additionally generate a CycloneDX 1.6 JSON SBOM of the release dependencies as a standardized machine-readable inventory (make sbom, make ios-sbom).

Criterion [OSPS-QA-04.01]
Met

Unmet

N/A

?

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 (gitlab.com/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/).

Criterion [OSPS-QA-05.01]
Met

Unmet

N/A

?

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. The iOS port is the same: Xcode build products (DerivedData, .build) and the XcodeGen-generated ios/Potillus.xcodeproj are git-ignored and never committed, and no iOS binary is checked in.

Criterion [OSPS-QA-05.02]
Met

Unmet

N/A

?

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. On the iOS side no binary is committed at all: SwiftPM resolves dependencies from source, pinned by exact version and revision in ios/PotillusKit/Package.resolved, so there is no wrapper jar or prebuilt library to review.

Criterion [OSPS-VM-02.01]
Met

Unmet

N/A

?

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 GitLab 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.

You can use tools and AI systems to propose changes via a simple URL, such as https://www.bestpractices.dev/en/projects/13480/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced. See our automation proposals system for how to do that. 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.

Libellus Potionis

Basics

General

Controls 24/24 ●

Controls