hMailServer

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 14949 é in_progress 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/14949/baseline)](https://www.bestpractices.dev/projects/14949)
ou incorporando isto no seu HTML:
<a href="https://www.bestpractices.dev/projects/14949"><img src="https://www.bestpractices.dev/projects/14949/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.

    hMailServer is a free, open-source mail server for Windows and Linux, implementing SMTP, IMAP and POP3, with webmail, a REST API and a Control Panel. It is a maintained fork of Martin Knafve's hMailServer, brought up to date with a current toolchain, current cryptography, and the transport-security and authentication standards expected of a mail server in 2026.

    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.

    This entry replaces https://www.bestpractices.dev/en/projects/14187, which was made through a GitHub login. GitHub suspended the project account on 18 September 2026, so that entry can no longer be edited. The project has lived on GitLab since 22 September 2026: https://gitlab.com/Progressiverobot/hmailserver. Every answer here was checked again against the project on 26 September 2026.

 Controles 22/24 ●

  • Controles


    Suficiente para um badge!

    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.

    Only the Owner account, Progressiverobot, can change project settings, CI/CD variables, protected branches and tags, or push master and v* tags, and it signs in with two-factor authentication. The two other members, zainulabidin1990 and chrisholloway5 (Developer), can read confidential issues, where security reports arrive, and also sign in with two-factor authentication. The project is in a personal namespace, so GitLab has no setting that enforces this for them. See https://gitlab.com/Progressiverobot/hmailserver/-/project_members


    Suficiente para um badge!

    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.

    GitLab never grants project access by itself: a member is added only by an Owner or Maintainer inviting them with an explicitly chosen role, and access requests are turned off for this project. Today there are three members: Progressiverobot (Owner) and zainulabidin1990 and chrisholloway5 (Developer). See https://gitlab.com/Progressiverobot/hmailserver/-/project_members


    Insuficiente para um badge.

    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.

    master is a protected branch: force pushes are refused and only the Maintainer role or above may push or merge. Only the Owner account, Progressiverobot, holds that role, so every other account is refused a direct commit. But the maintainer lands changes by pushing master directly (a fast-forward after the full regression gate), and nothing prevents a direct commit from that account. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/CONTRIBUTING.md#merge-requests


    Suficiente para um badge!

    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.

    master is the default branch, and GitLab refuses to delete the default branch. master is also protected: a git push cannot delete it, and only the Maintainer role or above can unprotect it, which only the Owner account holds. See https://gitlab.com/Progressiverobot/hmailserver/-/branches


    Suficiente para um badge!

    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 only CI job that handles metadata from outside the project is sign-off, which runs on a merge request from a fork. It reads commit authors, subjects and trailers into quoted shell variables, compares them as data and only prints them. Branch and tag names are compared in rules: and passed to scripts only as environment variables, never written into a command (SECURITY.md, "Branch and tag names in the pipelines"). See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/.gitlab-ci.yml


    Suficiente para um badge!

    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.

    The project's two runners, linix and bench150, are registered ref_protected and locked, and do not run untagged jobs. The jobs that use them run only for protected refs (master, batch*, v*), never for a merge request. A merge request from a fork runs its pipeline in the fork, or on GitLab's shared runners when a maintainer runs it here, and either way sees no protected variable. No job on master declares an ID token; in the next batch only the release jobs for protected v* tags do. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/docs/ContinuousIntegration.md


    Suficiente para um badge!

    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.

    The project's channels are HTTPS only: the GitLab project, issues, wiki and releases, the update feed https://updates.progressiverobot.com and https://www.progressiverobot.com. The forums SUPPORT.md names are also HTTPS only: https://www.hmailserver.com/forum/ on master, and https://www.hmailserver.co.uk/ from the next batch. Each of those four sites redirects plain HTTP to HTTPS (checked 26 September 2026), and Git is served over HTTPS and SSH only. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/SUPPORT.md


    Suficiente para um badge!

    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.

    Releases are distributed only over HTTPS, from GitLab's release pages and package registry (https://gitlab.com/Progressiverobot/hmailserver/-/releases) and the HTTPS update feed. Assets are also signed: Sigstore bundles for every asset up to 6.3.3, and Authenticode on the Windows installer from 6.3.1.


    Insuficiente para um badge.

    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 repository holds no credential, but nothing on GitLab stops one from being committed today. GitLab's secret push protection needs Ultimate, and .gitignore excludes build output and logs but no secret-file patterns. A secret_detection job (GitLab's template, failing on any finding not listed in .gitleaksignore) comes in the next batch and has not run on GitLab yet. On 26 September 2026 a scan of the whole history with that job's image found no real secret. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/SECURITY.md


    Suficiente para um badge!

    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.

    README.md covers installation (Windows installer, Linux packages, unattended install), administration (Control Panel, REST API), and building, with a configuration reference. The 104 documents under hmailserver/docs cover operation, upgrade, migration and security, and the GitLab wiki (https://gitlab.com/Progressiverobot/hmailserver/-/wikis/home) has 63 pages of user guides. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/README.md


    Suficiente para um badge!

    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.

    SUPPORT.md explains how to report a defect: a GitLab issue with the Bug template, and what to include (the log, the ERROR log, version, platform, database). It says what to expect and sends security problems to SECURITY.md. CONTRIBUTING.md, 'Reporting, asking and proposing', repeats the routes. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/SUPPORT.md


    Suficiente para um badge!

    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.

    The GitLab issue tracker is public. Proposed changes and questions are discussed there, and a Question template adds the question label. Merge requests are open to forks. SUPPORT.md also points usage questions to the hMailServer forum. See https://gitlab.com/Progressiverobot/hmailserver/-/work_items


    Suficiente para um badge!

    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.

    CONTRIBUTING.md explains the contribution process: how to report, ask and propose, then build, test, sign off, and open a merge request from a fork against master. It also explains how the maintainer reviews and lands the change. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/CONTRIBUTING.md


    Suficiente para um badge!

    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 source is licensed AGPL-3.0-or-later, which is OSI-approved and FSF-free. The full text is in LICENSE, the source headers carry SPDX-License-Identifier: AGPL-3.0-or-later, and GitLab detects the licence. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/LICENSE


    Suficiente para um badge!

    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 released assets are the same AGPL-3.0-or-later software. The Windows installer shows the AGPL text at install time (LicenseFile=license.rtf, hmailserver/installation/License.rtf), and the .rpm declares License: AGPL-3.0-or-later. No other licence is applied to releases. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/installation/License.rtf


    Suficiente para um badge!

    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 licence text is in the LICENSE file at the root of the project's only repository. See https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/LICENSE


    Suficiente para um badge!

    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.

    Each GitLab release includes the source archives of its tag, which contain the root LICENSE (AGPL-3.0-or-later), and the Windows installer shows the licence text during setup. See https://gitlab.com/Progressiverobot/hmailserver/-/releases


    Suficiente para um badge!

    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 source code is publicly readable at the static URL https://gitlab.com/Progressiverobot/hmailserver (a public GitLab project, default branch master), the project's home since 22 September 2026, as the first lines of README.md say. The former GitHub copy has been unavailable since 18 September 2026. https://gitlab.com/Progressiverobot/hmailserver


    Suficiente para um badge!

    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 git history on GitLab is publicly readable and records the author, committer and date of every commit: master's 1,425 commits are the whole history carried over from GitHub plus every commit since, kept linear by fast-forward, and force-push is refused on the protected master branch. https://gitlab.com/Progressiverobot/hmailserver/-/commits/master


    Suficiente para um badge!

    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.

    Every .NET project with a PackageReference has a committed NuGet lock file (packages.lock.json), and three legacy test tools list theirs in packages.config; the Python tooling's requirements are pinned with hashes (build/requirements-dev.txt). The C++ server has no package manager: OpenSSL, Boost and libpq are pinned by version and source-archive hash in the libraries/build-*.ps1 scripts, and every binary build input is listed in hmailserver/docs/third-party-binaries.json (checked by SHA-256, by version for the MSVC runtime, and for presence for two of Windows' own type libraries). https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/docs/ThirdPartyBinaries.md


    Suficiente para um badge!

    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.

    hMailServer is a single-repository project: the C++ server, the .NET tools, the Control Deck and webmail, the tests, fuzz harnesses, installer, packaging and documentation are all built into releases from https://gitlab.com/Progressiverobot/hmailserver alone. The wiki belongs to the same GitLab project and is compiled into nothing.


    Suficiente para um badge!

    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.

    No generated executable is in version control. The one there was, the COM interop wrapper Interop.hMailServer.dll, has been generated at build time by build/generate-com-wrapper.ps1 since 11 September 2026. None of master's 6,983 tracked files has a PE, ELF or Mach-O header (checked 26 September 2026); the CI's Binary-Artifacts check (build/ci/repo-hygiene.py) tests the same. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/source/Tools/Interop/README.md


    Suficiente para um badge!

    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.

    Since 11 September 2026 the repository holds no executable or library binary: the forty third-party DLLs, MSIs and EXEs were removed, and the build fetches or gathers each one it still needs, checked against hmailserver/docs/third-party-binaries.json (SHA-256 for the fetched ones, version for the MSVC runtime, presence for two of Windows' own type libraries). What remains binary is images (icons, the Fat Cow icon archive, installer bitmaps), licence texts (RTF) and test fixtures (PST files, certificates, OpenPGP samples, fuzz regression inputs). https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/hmailserver/docs/ThirdPartyBinaries.md


    Suficiente para um badge!

    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.

    SECURITY.md at the repository root gives the security contacts: a confidential GitLab issue (Security template) or email to the project's Service Desk address, contact-project+progressiverobot-hmailserver-86730559-issue-@incoming.gitlab.com, both reaching the maintainers, whom GOVERNANCE.md names. https://gitlab.com/Progressiverobot/hmailserver/-/blob/master/SECURITY.md



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/14949/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 christopher holloway e aos contribuidores do selo de melhores práticas OpenSSF.

Entrada de selo do projeto de propriedade de: christopher holloway.
Entrada criada em 2026-09-26 05:28:20 UTC, última atualização em 2026-09-26 06:16:51 UTC. Selo de aprovação alcançado pela última vez em 2026-09-26 05:45:21 UTC.