Libellus Potionis

Les projets qui suivent les meilleures pratiques ci-dessous peuvent s'auto-certifier et montrer qu'ils ont obtenu le badge de la Open Source Security Foundation (OpenSSF).

Il n'existe aucun ensemble de pratiques qui garantissent que ce logiciel n'aura jamais de défauts ou de vulnérabilités ; même les méthodes formelles peuvent échouer si les spécifications ou les hypothèses sont fausses. Il n'y a pas non plus de pratiques qui peuvent garantir qu'un projet permettra de maintenir une communauté de développement saine et qui fonctionne bien. Toutefois, suivre les meilleures pratiques peut contribuer à améliorer les résultats des projets. Par exemple, certaines pratiques permettent la revue par plusieurs personnes avant publication, ce qui peut aider à trouver des vulnérabilités techniques difficiles à trouver autrement et à renforcer la confiance et un désir d'interaction répétée entre les développeurs de différentes entreprises. Pour gagner un badge, tous les critères DOIT et NE DOIT PAS doivent être satisfaits, tous les critères DEVRAIT doivent être satisfaits OU non satisfaits avec justification, et tous les critères PROPOSÉ doivent être satisfaits OU non satisfaits (nous voulons au moins qu'ils soient considérés). Si vous voulez entrer un texte de justification pour un commentaire générique, au lieu d'une raison justifiant que la situation est acceptable, commencez le bloc de texte avec '//' suivi d'un espace. Les commentaires sont les bienvenus via le site GitHub en tant que problèmes ou pull requests. Il existe également une liste de diffusion pour discussion générale.

Nous fournissons volontiers l'information dans plusieurs langues, cependant, s'il existe un conflit ou une contradiction entre les traductions, la version anglaise est la version qui fait autorité.
Si c'est votre projet, veuillez afficher votre statut de badge de référence sur la page de votre projet ! Le statut du badge de référence ressemble à ceci : Le niveau du badge de référence pour le projet 13480 est baseline-2 Voici comment intégrer le badge de référence :
Vous pouvez afficher votre statut de badge de référence en incorporant ceci dans votre fichier markdown :
[![OpenSSF Baseline](https://www.bestpractices.dev/projects/13480/baseline)](https://www.bestpractices.dev/projects/13480)
ou en incorporant ceci dans votre HTML :
<a href="https://www.bestpractices.dev/projects/13480"><img src="https://www.bestpractices.dev/projects/13480/baseline"></a>


Voici les critères du niveau de référence 1. Il s'agit des critères version v2026.02.19.

Baseline Series: Niveau de référence 1 Niveau de référence 2 Niveau de référence 3

        

 Notions de base

  • Général

    Notez que d'autres projets peuvent utiliser le même nom.

    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.

    Utilisez un format d'expression de licence SPDX ; des exemples sont « Apache-2.0 », « BSD-2-Clause », « BSD-3-Clause », « GPL-2.0+ », « LGPL-3.0+ », « MIT » et « (BSD-2-Clause OU Ruby) ». Ne pas inclure des guillemets simples ou doubles.
    S'il y a plus d'un langage, listez-les en tant que valeurs séparées par des virgules (espaces facultatifs) et triez-les du plus au moins utilisé. S'il y a une longue liste, veuillez lister au moins les trois premiers. S'il n'y a pas de langage (par exemple, il s'agit d'un projet uniquement de documentation ou de test), utilisez le caractère unique « - ». Utilisez une capitalisation conventionnelle pour chaque langage, par exemple « JavaScript ».
    La plate-forme commune d'énumération (CPE) est un schéma de dénomination structuré pour les systèmes, les logiciels et les paquetages des technologies de l'information. Il est utilisé dans un certain nombre de systèmes et de bases de données pour signaler des vulnérabilités.

    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.

 Contrôles 24/24

  • Contrôles


    Lorsqu'un utilisateur tente de lire ou de modifier une ressource sensible dans le dépôt faisant autorité du projet, le système DOIT exiger que l'utilisateur termine un processus d'authentification multi-facteurs. [OSPS-AC-01.01]
    Imposer l'authentification multi-facteurs pour le système de contrôle de version du projet, exigeant des collaborateurs qu'ils fournissent une seconde forme d'authentification lors de l'accès aux données sensibles ou de la modification des paramètres du dépôt. Les passkeys sont acceptables pour ce contrôle.

    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]



    Lorsqu'un nouveau collaborateur est ajouté, le système de contrôle de version DOIT exiger une attribution manuelle de permissions, ou restreindre les permissions du collaborateur aux privilèges disponibles les plus bas par défaut. [OSPS-AC-02.01]
    La plupart des systèmes de contrôle de version publics sont configurés de cette manière. Assurez-vous que le système de contrôle de version du projet attribue toujours les permissions les plus basses disponibles aux collaborateurs par défaut lorsqu'ils sont ajoutés, accordant des permissions supplémentaires uniquement lorsque cela est nécessaire.

    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.



    Lorsqu'un commit direct est tenté sur la branche principale du projet, un mécanisme d'application DOIT empêcher la modification d'être appliquée. [OSPS-AC-03.01]
    Si le VCS est centralisé, définissez une protection de branche sur la branche principale dans le VCS du projet. Alternativement, utilisez une approche décentralisée, comme celle du noyau Linux, où les modifications sont d'abord proposées dans un autre dépôt, et la fusion des modifications dans le dépôt principal nécessite un acte distinct spécifique.

    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.



    Lorsqu'une tentative est faite de supprimer la branche principale du projet, le système de contrôle de version DOIT traiter cela comme une activité sensible et exiger une confirmation explicite de l'intention. [OSPS-AC-03.02]
    Définissez une protection de branche sur la branche principale dans le système de contrôle de version du projet pour empêcher la suppression.

    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.



    Lorsqu'un pipeline CI/CD accepte un paramètre d'entrée, ce paramètre DOIT être assaini et validé avant d'être utilisé dans le pipeline. [OSPS-BR-01.01]
    Les pipelines CI/CD doivent assainir (mettre entre guillemets, échapper ou quitter pour les valeurs attendues) toutes les entrées de métadonnées correspondant à des sources non fiables. Cela inclut des données telles que les noms de branches, les messages de commit, les tags, les titres des pull requests et les informations sur l'auteur.

    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.



    Lorsqu'un pipeline CI/CD opère sur des instantanés de code non fiables, il DOIT empêcher l'accès aux identifiants et aux ressources privilégiés du CI/CD. [OSPS-BR-01.03]
    Les pipelines CI/CD doivent isoler les instantanés de code non fiables des identifiants et des ressources privilégiés. En particulier, les projets doivent veiller à ce que les workflows qui compilent ou exécutent du code avant examen par un collaborateur n'aient pas accès aux identifiants CI/CD.

    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.



    Lorsque le projet liste un URI comme canal officiel du projet, cet URI DOIT être exclusivement fourni en utilisant des canaux chiffrés. [OSPS-BR-03.01]
    Configurez les sites Web et les systèmes de contrôle de version du projet pour utiliser des canaux chiffrés tels que SSH ou HTTPS pour la transmission de données. Assurez-vous que tous les outils et domaines référencés dans la documentation du projet ne peuvent être accessibles que via des canaux chiffrés.

    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.



    Lorsque le projet liste un URI comme canal de distribution officiel, cet URI DOIT être exclusivement fourni en utilisant des canaux chiffrés. [OSPS-BR-03.02]
    Configurez le pipeline de publication du projet pour récupérer uniquement les données des sites Web, réponses API et autres services qui utilisent des canaux chiffrés tels que SSH ou HTTPS pour la transmission de données.

    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.



    Le projet DOIT empêcher le stockage involontaire de données sensibles non chiffrées, telles que des secrets et des informations d'identification, dans le système de contrôle de version. [OSPS-BR-07.01]
    Configurez .gitignore ou équivalent pour exclure les fichiers susceptibles de contenir des informations sensibles. Utilisez des hooks de pré-commit et des outils d'analyse automatisés pour détecter et empêcher l'inclusion de données sensibles dans les 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]



    Lorsque le projet a effectué une publication, la documentation du projet DOIT inclure des guides utilisateur pour toutes les fonctionnalités de base. [OSPS-DO-01.01]
    Créez des guides utilisateur ou de la documentation pour toutes les fonctionnalités de base du projet, en expliquant comment installer, configurer et utiliser les fonctionnalités du projet. S'il existe des actions dangereuses ou destructrices connues disponibles, incluez des avertissements très visibles.

    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]



    Lorsque le projet a effectué une publication, la documentation du projet DOIT inclure un guide pour signaler les défauts. [OSPS-DO-02.01]
    Il est recommandé que les projets utilisent le suivi de problèmes par défaut de leur VCS. Si une source externe est utilisée, assurez-vous que la documentation du projet et le guide de contribution expliquent clairement et visiblement comment utiliser le système de signalement. Il est recommandé que la documentation du projet établisse également des attentes quant à la manière dont les défauts seront triés et résolus.

    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]



    Tant qu'il est actif, le projet DOIT avoir un ou plusieurs mécanismes pour des discussions publiques sur les modifications proposées et les obstacles d'utilisation. [OSPS-GV-02.01]
    Établissez un ou plusieurs mécanismes pour des discussions publiques au sein du projet, tels que des listes de diffusion, de la messagerie instantanée ou des systèmes de suivi de problèmes, pour faciliter une communication et des retours ouverts.

    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]



    Tant qu'il est actif, la documentation du projet DOIT inclure une explication du processus de contribution. [OSPS-GV-03.01]
    Créez un fichier CONTRIBUTING.md ou un répertoire CONTRIBUTING/ pour décrire le processus de contribution, y compris les étapes pour soumettre des modifications et interagir avec les mainteneurs du projet.

    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]



    Tant qu'il est actif, la licence du code source DOIT répondre à la définition de l'Open Source de l'OSI ou à la définition du logiciel libre de la FSF. [OSPS-LE-02.01]
    Ajoutez un fichier LICENSE au dépôt du projet avec une licence qui est une licence approuvée par l'Open Source Initiative (OSI), ou une licence libre approuvée par la Free Software Foundation (FSF). Des exemples de telles licences incluent MIT, BSD 2-clause, BSD 3-clause révisée, Apache 2.0, Lesser GNU General Public License (LGPL) et GNU General Public License (GPL). Publier dans le domaine public répond à ce contrôle s'il n'y a pas d'autres restrictions telles que des brevets.

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



    Tant qu'il est actif, la licence des ressources logicielles publiées DOIT répondre à la définition de l'Open Source de l'OSI ou à la définition du logiciel libre de la FSF. [OSPS-LE-02.02]
    Si une licence différente est incluse avec les ressources logicielles publiées, assurez-vous qu'il s'agit d'une licence approuvée par l'Open Source Initiative (OSI), ou d'une licence libre approuvée par la Free Software Foundation (FSF). Des exemples de telles licenses incluent MIT, BSD 2-clause, BSD 3-clause révisée, Apache 2.0, Lesser GNU General Public License (LGPL) et GNU General Public License (GPL). Notez que la licence des ressources logicielles publiées peut être différente de celle du code source.

    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]



    Tant qu'il est actif, la licence du code source DOIT être maintenue dans le fichier LICENSE, le fichier COPYING ou le répertoire LICENSE/ du dépôt correspondant. [OSPS-LE-03.01]
    Incluez la licence du code source du projet dans le fichier LICENSE, le fichier COPYING ou le répertoire LICENSE/ du projet pour fournir visibilité et clarté sur les termes de la licence. Le nom de fichier PEUT avoir une extension. Si le projet a plusieurs dépôts, assurez-vous que chaque dépôt inclut le fichier de licence.

    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]



    Tant qu'il est actif, la licence des ressources logicielles publiées DOIT être incluse dans le code source publié, ou dans un fichier LICENSE, un fichier COPYING ou un répertoire LICENSE/ aux côtés des ressources de publication correspondantes. [OSPS-LE-03.02]
    Incluez la licence des ressources logicielles publiées du projet dans le code source publié, ou dans un fichier LICENSE, un fichier COPYING ou un répertoire LICENSE/ aux côtés des ressources de publication correspondantes pour fournir visibilité et clarté sur les termes de la licence. Le nom de fichier PEUT avoir une extension. Si le projet a plusieurs dépôts, assurez-vous que chaque dépôt inclut le fichier de licence.

    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



    Pendant son activité, le référentiel de code source du projet DOIT être publiquement lisible à une URL statique. [OSPS-QA-01.01]
    Utilisez un VCS commun tel que GitHub, GitLab ou Bitbucket. Assurez-vous que le référentiel est publiquement lisible. Évitez la duplication ou la mise en miroir de référentiels à moins qu'une documentation très visible ne clarifie la source principale. Évitez les changements fréquents du référentiel qui affecteraient l'URL du référentiel. Assurez-vous que le référentiel est 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]



    Le système de contrôle de version DOIT contenir un enregistrement publiquement lisible de toutes les modifications apportées, qui les a apportées et quand elles ont été apportées. [OSPS-QA-01.02]
    Utilisez un VCS commun tel que GitHub, GitLab ou Bitbucket pour maintenir un historique de commits publiquement lisible. Évitez de fusionner ou de réécrire les commits d'une manière qui obscurcirait l'auteur de tout commit.

    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]



    Lorsque le système de gestion de paquets le prend en charge, le référentiel de code source DOIT contenir une liste de dépendances qui tient compte des dépendances directes du langage. [OSPS-QA-02.01]
    Cela peut prendre la forme d'un fichier de gestionnaire de paquets ou de dépendances de langage qui énumère toutes les dépendances directes telles que package.json, Gemfile ou 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]



    Pendant son activité, la documentation du projet DOIT contenir une liste de tous les codes sources qui sont considérés comme des sous-projets. [OSPS-QA-04.01]
    Documentez tous les référentiels de code de sous-projets supplémentaires produits par le projet et compilés dans une version. Cette documentation doit inclure l'état et l'intention du code source respectif.

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



    Pendant son activité, le système de contrôle de version NE DOIT PAS contenir d'artefacts exécutables générés. [OSPS-QA-05.01]
    Supprimez les artefacts exécutables générés dans le système de contrôle de version du projet. Il est recommandé que tout scénario où un artefact exécutable généré apparaît critique pour un processus tel que les tests, il devrait plutôt être généré au moment de la compilation ou stocké séparément et récupéré lors d'une étape de pipeline spécifique bien documentée.

    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.



    Pendant son activité, le système de contrôle de version NE DOIT PAS contenir d'artefacts binaires non révisables. [OSPS-QA-05.02]
    N'ajoutez aucun artefact binaire non révisable au système de contrôle de version du projet. Cela inclut les binaires d'applications exécutables, les fichiers de bibliothèque et les artefacts similaires. Cela n'inclut pas les ressources telles que les images graphiques, les fichiers sonores ou musicaux et le contenu similaire généralement stocké dans un format binaire.

    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.



    Pendant son activité, la documentation du projet DOIT contenir des contacts de sécurité. [OSPS-VM-02.01]
    Créez un fichier security.md (ou portant un nom similaire) qui contient les contacts de sécurité pour le projet.

    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]



Ces données sont disponibles sous la licence Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). Cela signifie qu'un destinataire de données peut partager les données, avec ou sans modifications, à condition que le destinataire de données rende disponible le texte de cet accord avec les données partagées. Veuillez créditer Martin A. Godisch et les contributeurs du badge des meilleures pratiques de la OpenSSF.

Soumission du badge du projet appartenant à : Martin A. Godisch.
Soumission créée le 2026-07-04 04:21:04 UTC, dernière mise à jour le 2026-07-14 19:16:17 UTC. Le dernier badge obtenu l'a été le 2026-07-04 08:45:54 UTC.