Libellus Potionis

Projetos que seguem as melhores práticas abaixo podem se autocertificar voluntariamente e mostrar que alcançaram um selo de melhores práticas da Open Source Security Foundation (OpenSSF).

Não existe um conjunto de práticas que possa garantir que o software nunca terá defeitos ou vulnerabilidades; mesmo métodos formais podem falhar se as especificações ou suposições estiverem erradas. Nem existe qualquer conjunto de práticas que possa garantir que um projeto sustentará uma comunidade de desenvolvimento saudável e bem-funcionada. No entanto, seguir as melhores práticas pode ajudar a melhorar os resultados dos projetos. Por exemplo, algumas práticas permitem revisão multipessoal antes do lançamento, o que pode ajudar a encontrar vulnerabilidades técnicas difíceis de encontrar e ajudar a construir confiança e desejo de interação repetida entre desenvolvedores de diferentes empresas. Para ganhar um selo, todos os critérios DEVE e NÃO DEVE devem ser atendidos, todos os critérios DEVERIA devem ser atendidos OU não atendidos com justificativa, e todos os critérios SUGERIDO devem ser atendidos OU não atendidos (queremos que sejam considerados pelo menos). Se você quiser inserir texto de justificativa como um comentário genérico, em vez de ser uma justificativa de que a situação é aceitável, inicie o bloco de texto com '//' seguido de um espaço. Feedback é bem-vindo via site do GitHub como questões ou pull requests Há também uma lista de discussão para discussão geral.

Fornecemos com prazer as informações em vários idiomas, no entanto, se houver qualquer conflito ou inconsistência entre as traduções, a versão em inglês é a versão autoritativa.
Se este é o seu projeto, por favor mostre o status do seu selo básico na página do seu projeto! O status do selo básico se parece com isto: O nível do selo básico para o projeto 13480 é baseline-2 Aqui está como incorporar o selo básico:
Você pode mostrar o status do seu selo básico incorporando isto no seu arquivo markdown:
[![OpenSSF Baseline](https://www.bestpractices.dev/projects/13480/baseline)](https://www.bestpractices.dev/projects/13480)
ou incorporando isto no seu HTML:
<a href="https://www.bestpractices.dev/projects/13480"><img src="https://www.bestpractices.dev/projects/13480/baseline"></a>


Estes são os critérios de Nível Básico 1. Estes são critérios da versão v2026.08.28.

Baseline Series: Nível Básico 1 Nível Básico 2 Nível Básico 3

        

 Fundamentos

  • Geral

    Observe que outros projetos podem usar o mesmo nome.

    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.

    Use o formato de expressão de licença SPDX; exemplos incluem "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "GPL-2.0+", "LGPL-3.0+", "MIT" e "(BSD-2-Clause OR Ruby)". Não inclua aspas simples ou aspas duplas.
    Se houver mais de uma linguagem, liste-as como valores separados por vírgula (espaços opcionais) e ordene-as da mais usada para a menos usada. Se houver uma longa lista, liste pelo menos as três primeiras mais comuns. Se não houver linguagem (por exemplo, este é um projeto apenas de documentação ou apenas de teste), use o caractere único "-". Use uma capitalização convencional para cada linguagem, por exemplo, "JavaScript".
    O Common Platform Enumeration (CPE) é um esquema de nomenclatura estruturado para sistemas de tecnologia da informação, software e pacotes. Ele é usado em vários sistemas e bancos de dados ao relatar vulnerabilidades.

    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.

 Controles 24/24

  • Controles


    Quando um usuário tentar ler ou modificar um recurso sensível no repositório autorizado do projeto, o sistema DEVE exigir que o usuário complete um processo de autenticação multifator. [OSPS-AC-01.01]
    Imponha autenticação multifator para o sistema de controle de versão do projeto, exigindo que os colaboradores forneçam uma segunda forma de autenticação ao acessar dados sensíveis ou modificar configurações do repositório. Passkeys são aceitáveis para este controle.

    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.



    Quando um novo colaborador for adicionado, o sistema de controle de versão DEVE exigir atribuição manual de permissão, ou restringir as permissões do colaborador aos menores privilégios disponíveis por padrão. [OSPS-AC-02.01]
    A maioria dos sistemas públicos de controle de versão são configurados desta maneira. Certifique-se de que o sistema de controle de versão do projeto sempre atribua as menores permissões disponíveis aos colaboradores por padrão quando adicionados, concedendo permissões adicionais somente quando necessário.

    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.



    Quando uma confirmação direta for tentada no ramo principal do projeto, um mecanismo de aplicação DEVE impedir que a mudança seja aplicada. [OSPS-AC-03.01]
    Se o VCS for centralizado, defina proteção de ramo no ramo principal no VCS do projeto. Alternativamente, use uma abordagem descentralizada, como a do kernel Linux, onde as mudanças são primeiro propostas em outro repositório, e mesclar mudanças no repositório principal requer um ato separado específico.

    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.



    Quando for feita uma tentativa de excluir o ramo principal do projeto, o sistema de controle de versão DEVE tratar isso como uma atividade sensível e exigir confirmação explícita de intenção. [OSPS-AC-03.02]
    Defina proteção de ramo no ramo principal no sistema de controle de versão do projeto para evitar exclusão.

    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.



    Quando um pipeline de CI/CD opera com metadados não confiáveis, esses parâmetros DEVEM ser higienizados e validados antes de serem usados no pipeline. [OSPS-BR-01.01]
    Os pipelines de CI/CD devem sanitizar (citar, escapar ou sair com valores esperados) todas as entradas de metadados que correspondam a fontes não confiáveis. Isso inclui dados como nomes de branch, mensagens de commit, tags, títulos de pull requests e informações de autoria.

    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.



    Quando um pipeline de CI/CD opera em snapshots de código não confiável, ele DEVE impedir o acesso a credenciais e ativos privilegiados de CI/CD. [OSPS-BR-01.03]
    Os pipelines de CI/CD devem isolar snapshots de código não confiável de credenciais e ativos privilegiados. Em particular, os projetos devem ter cuidado para garantir que os workflows que compilam ou executam código antes da revisão por um colaborador não tenham acesso às credenciais de CI/CD.

    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.



    Quando o projeto listar um URI como um canal oficial do projeto, esse URI DEVE ser entregue exclusivamente usando canais criptografados. [OSPS-BR-03.01]
    Configure os sites do projeto e os sistemas de controle de versão para usar canais criptografados como SSH ou HTTPS para transmissão de dados. Certifique-se de que todas as ferramentas e domínios referenciados na documentação do projeto só possam ser acessados por meio de canais criptografados.

    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.



    Quando o projeto listar uma URI como canal de distribuição oficial, esse canal DEVE ser protegido contra ataques de adversário no meio (adversary-in-the-middle) usando canais criptograficamente autenticados. [OSPS-BR-03.02]
    Os artefatos distribuídos pelo projeto devem ser distribuídos por meio de canais que garantam integridade e autenticidade. O uso de HTTPS para downloads, versões assinadas ou distribuição por meio de gerenciadores de pacotes confiáveis são métodos aceitáveis para proteger contra ataques de adversário no meio.

    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.



    O projeto DEVE impedir o armazenamento não intencional de dados sensíveis não criptografados, como segredos e credenciais, no sistema de controle de versão. [OSPS-BR-07.01]
    Configure .gitignore ou equivalente para excluir arquivos que possam conter informações sensíveis. Use hooks de pré-commit e ferramentas de varredura automatizadas para detectar e prevenir a inclusão de dados sensíveis em 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.



    Quando o projeto tiver feito uma versão, a documentação do projeto DEVE incluir guias do usuário para todas as funcionalidades básicas. [OSPS-DO-01.01]
    Crie guias do usuário ou documentação para todas as funcionalidades básicas do projeto, explicando como instalar, configurar e usar os recursos do projeto. Se houver quaisquer ações perigosas ou destrutivas conhecidas disponíveis, inclua avisos altamente visíveis.

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



    Quando o projeto tiver feito uma versão, a documentação do projeto DEVE incluir um guia para relatar defeitos. [OSPS-DO-02.01]
    É recomendado que os projetos usem o rastreador de issues padrão do seu VCS. Se uma fonte externa for usada, certifique-se de que a documentação do projeto e o guia de contribuição expliquem de forma clara e visível como usar o sistema de relatório. É recomendado que a documentação do projeto também estabeleça expectativas sobre como os defeitos serão triados e resolvidos.

    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.



    O projeto DEVE ter um ou mais mecanismos para discussões públicas sobre mudanças propostas e obstáculos de uso. [OSPS-GV-02.01]
    Estabeleça um ou mais mecanismos para discussões públicas dentro do projeto, como listas de discussão, mensagens instantâneas ou rastreadores de issues, para facilitar a comunicação aberta e 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).



    A documentação do projeto DEVE incluir uma explicação do processo de contribuição, ou declarar claramente que contribuições públicas não são aceitas [OSPS-GV-03.01]
    Crie um CONTRIBUTING.md ou diretório CONTRIBUTING/ para delinear o processo de contribuição incluindo as etapas para enviar mudanças e se engajar com os mantenedores do projeto.

    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.



    A licença do código-fonte DEVE atender à Definição de Código Aberto da OSI ou à Definição de Software Livre da FSF. [OSPS-LE-02.01]
    Adicione um arquivo LICENSE ao repositório do projeto com uma licença que seja uma licença aprovada pela Open Source Initiative (OSI), ou uma licença livre aprovada pela Free Software Foundation (FSF). Exemplos de tais licenças incluem MIT, BSD 2-clause, BSD 3-clause revisada, Apache 2.0, Lesser GNU General Public License (LGPL) e a GNU General Public License (GPL). Lançar para o domínio público atende a este controle se não houver outros obstáculos como patentes.

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



    A licença dos ativos de software lançados DEVE atender à Definição de Código Aberto da OSI ou à Definição de Software Livre da FSF. [OSPS-LE-02.02]
    Se uma licença diferente for incluída com ativos de software lançados, certifique-se de que seja uma licença aprovada pela Open Source Initiative (OSI), ou uma licença livre aprovada pela Free Software Foundation (FSF). Exemplos de tais licenças incluem MIT, BSD 2-clause, BSD 3-clause revisada, Apache 2.0, Lesser GNU General Public License (LGPL) e a GNU General Public License (GPL). Note que a licença para os ativos de software lançados pode ser diferente do código-fonte.

    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.



    A licença do código-fonte DEVE ser mantida no arquivo LICENSE, arquivo COPYING, diretório LICENSES/ ou diretório LICENSE/ do repositório correspondente. [OSPS-LE-03.01]
    Inclua a licença do código-fonte do projeto no arquivo LICENSE, arquivo COPYING, diretório LICENSES/ ou diretório LICENSE/ do projeto para fornecer visibilidade e clareza sobre os termos de licenciamento. O nome do arquivo PODE ter uma extensão. Se o projeto tiver vários repositórios, garanta que cada repositório inclua o arquivo de licença.

    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.



    A licença dos ativos de software lançados DEVE ser incluída no código-fonte lançado, ou em um arquivo LICENSE, arquivo COPYING, ou diretório LICENSE/ junto aos ativos de lançamento correspondentes. [OSPS-LE-03.02]
    Inclua a licença dos ativos de software lançados do projeto no código-fonte lançado, ou em um arquivo LICENSE, arquivo COPYING ou diretório LICENSE/ ao lado dos ativos de versão correspondentes para fornecer visibilidade e clareza sobre os termos de licenciamento. O nome do arquivo PODE ter uma extensão. Se o projeto tiver múltiplos repositórios, certifique-se de que cada repositório inclua o arquivo de licença.

    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.



    O repositório de código-fonte do projeto DEVE ser publicamente legível em uma URL estática. [OSPS-QA-01.01]
    Use um VCS comum como GitHub, GitLab ou Bitbucket. Certifique-se de que o repositório seja publicamente legível. Evite duplicação ou espelhamento de repositórios a menos que documentação altamente visível esclareça a fonte primária. Evite mudanças frequentes no repositório que impactariam a URL do repositório. Certifique-se de que o repositório seja público.

    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.



    O sistema de controle de versão DEVE conter um registro publicamente legível de todas as alterações feitas, quem fez as alterações e quando as alterações foram feitas. [OSPS-QA-01.02]
    Use um VCS comum como GitHub, GitLab ou Bitbucket para manter um histórico de commits publicamente legível. Evite esmagar ou reescrever commits de uma forma que obscureça o autor de quaisquer 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



    Quando o sistema de gerenciamento de pacotes suportar, o repositório de código-fonte DEVE conter uma lista de dependências que representa as dependências diretas da linguagem. [OSPS-QA-02.01]
    Isso pode assumir a forma de um arquivo de dependências de gerenciador de pacotes ou linguagem que enumera todas as dependências diretas, como 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 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).



    Projetos com múltiplos repositórios DEVEM documentar uma lista das bases de código que fazem parte do projeto. [OSPS-QA-04.01]
    Documente quaisquer repositórios de código de subprojetos adicionais produzidos pelo projeto e compilados em uma versão de lançamento. Esta documentação deve incluir o status e a intenção da respectiva base de código.

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



    O sistema de controle de versão NÃO DEVE conter artefatos executáveis gerados. [OSPS-QA-05.01]
    Remova artefatos executáveis gerados no sistema de controle de versão do projeto. É recomendado que qualquer cenário em que um artefato executável gerado apareça como crítico para um processo, como testes, ele deve ser gerado no momento da compilação ou armazenado separadamente e buscado durante uma etapa de pipeline específica e bem documentada.

    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.



    O sistema de controle de versão NÃO DEVE conter artefatos binários não revisáveis. [OSPS-QA-05.02]
    Não adicione nenhum artefato binário não revisável ao sistema de controle de versão do projeto. Isso inclui binários de aplicativos executáveis, arquivos de biblioteca e artefatos similares. Não inclui recursos como imagens gráficas, arquivos de som ou música e conteúdo similar normalmente armazenado em formato binário.

    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.



    A documentação do projeto DEVE conter contatos de segurança. [OSPS-VM-02.01]
    Crie um arquivo security.md (ou com nome similar) que contenha contatos de segurança para o projeto.

    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.



Você pode usar ferramentas e sistemas de IA para propor alterações por meio de uma URL simples, como https://www.bestpractices.dev/pt-BR/projects/13480/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced. Veja nosso sistema de propostas de automação para saber como fazer isso. Estes dados estão disponíveis sob o Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). Isso significa que um Destinatário de Dados pode compartilhar os Dados, com ou sem modificações, desde que o Destinatário de Dados disponibilize o texto deste acordo com os Dados compartilhados. Por favor, dê crédito a Martin A. Godisch e aos contribuidores do selo de melhores práticas OpenSSF.

Entrada de selo do projeto de propriedade de: Martin A. Godisch.
Entrada criada em 2026-07-04 04:21:04 UTC, última atualização em 2026-08-29 11:29:00 UTC. Selo de aprovação perdido pela última vez em 2026-07-19 18:17:51 UTC. Selo de aprovação alcançado pela última vez em 2026-07-19 18:18:14 UTC.