ruview-home-sensing

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 na página do seu projeto! O status do selo se parece com isto: O nível do selo para o projeto 15634 é in_progress Aqui está como incorporá-lo:
Você pode mostrar o status do seu selo incorporando isto no seu arquivo markdown:
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/15634/badge)](https://www.bestpractices.dev/projects/15634)
ou incorporando isto no seu HTML:
<a href="https://www.bestpractices.dev/projects/15634"><img src="https://www.bestpractices.dev/projects/15634/badge"></a>


Estes são os critérios de nível de Aprovação. Você também pode visualizar os critérios de nível Prata ou Ouro.

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

        

 Fundamentos 12/13 ●

 Controle de Mudanças 9/9 ●

  • Repositório de código-fonte público controlado por versão


    Suficiente para um badge!

    O projeto DEVE ter um repositório de código-fonte controlado por versão que seja publicamente legível e tenha uma URL. [repo_public]
    A URL PODE ser a mesma que a URL do projeto. O projeto PODE usar branches privados (não públicos) em casos específicos enquanto a mudança não for lançada publicamente (por exemplo, para corrigir uma vulnerabilidade antes de ser revelada ao público).

    The software source is publicly readable in the default main branch after PR 1 merged at commit 3afc395637abd854f7300e96d62512af7975ab0b. The tagged initial prerelease remains separately available. Evidence: https://github.com/ha-homelab/ruview-home-sensing/tree/3afc395637abd854f7300e96d62512af7975ab0b ; https://github.com/ha-homelab/ruview-home-sensing/pull/1 ; https://github.com/ha-homelab/ruview-home-sensing/releases/tag/v0.4.0-rc.1


    Suficiente para um badge!

    O repositório de código-fonte do projeto DEVE rastrear quais mudanças foram feitas, quem fez as mudanças e quando as mudanças foram feitas. [repo_track]

    The public Git repository records the source changes and review commits. This assessment uses only its public change record. Evidence: https://github.com/ha-homelab/ruview-home-sensing/commits/d71f09cdc6948fb131c247ae51a2ada1af27a942 ; https://github.com/ha-homelab/ruview-home-sensing/pull/1/commits


    Suficiente para um badge!

    Para permitir revisão colaborativa, o repositório de código-fonte do projeto DEVE incluir versões intermediárias para revisão entre lançamentos; ele NÃO DEVE incluir apenas lançamentos finais. [repo_interim]
    Os projetos PODEM optar por omitir versões intermediárias específicas de seus repositórios de código-fonte públicos (por exemplo, aquelas que corrigem vulnerabilidades de segurança não públicas específicas, podem nunca ser lançadas publicamente ou incluem material que não pode ser legalmente postado e não estão no lançamento final).

    Interim source revisions are publicly available as Git commits and pull requests. The initial public source PR has merged, and its resulting main-branch commit is publicly readable. Evidence: https://github.com/ha-homelab/ruview-home-sensing/commits/3afc395637abd854f7300e96d62512af7975ab0b ; https://github.com/ha-homelab/ruview-home-sensing/tree/3afc395637abd854f7300e96d62512af7975ab0b ; https://github.com/ha-homelab/ruview-home-sensing/pull/1


    Suficiente para um badge!

    É SUGERIDO que software de controle de versão distribuído comum seja usado (por exemplo, git) para o repositório de código-fonte do projeto. [repo_distributed]
    O Git não é especificamente exigido e os projetos podem usar software de controle de versão centralizado (como subversion) com justificativa.

    The project uses a public Git repository, a distributed version-control system. Evidence: https://github.com/ha-homelab/ruview-home-sensing/tree/d71f09cdc6948fb131c247ae51a2ada1af27a942


  • Numeração de versão única


    Suficiente para um badge!

    Os resultados do projeto DEVEM ter um identificador de versão único para cada lançamento destinado a ser usado pelos usuários. [version_unique]
    Isso PODE ser atendido de várias maneiras, incluindo IDs de commit (como git commit id ou mercurial changeset id) ou um número de versão (incluindo números de versão que usam versionamento semântico ou esquemas baseados em data como AAAAMMDD).

    The initial prerelease v0.4.0-rc.1 has a unique Git tag resolving to commit d71f09cdc6948fb131c247ae51a2ada1af27a942. The version file uses 0.4.0-rc.1 and Python metadata uses the corresponding 0.4.0rc1 spelling. The published source archive manifest identifies its exact source commit. Evidence: https://github.com/ha-homelab/ruview-home-sensing/releases/tag/v0.4.0-rc.1 ; https://github.com/ha-homelab/ruview-home-sensing/blob/d71f09cdc6948fb131c247ae51a2ada1af27a942/version ; https://github.com/ha-homelab/ruview-home-sensing/blob/d71f09cdc6948fb131c247ae51a2ada1af27a942/pyproject.toml


    Suficiente para um badge!

    É SUGERIDO que o formato de numeração de versão Versionamento Semântico (SemVer) ou Versionamento de Calendário (CalVer) seja usado para lançamentos. É SUGERIDO que aqueles que usam CalVer incluam um valor de nível micro. [version_semver]
    Os projetos geralmente devem preferir qualquer formato que seja esperado por seus usuários, por exemplo, porque é o formato normal usado por seu ecossistema. Muitos ecossistemas preferem SemVer, e SemVer é geralmente preferido para interfaces de programação de aplicações (APIs) e kits de desenvolvimento de software (SDKs). CalVer tende a ser usado por projetos que são grandes, têm um número excepcionalmente grande de dependências desenvolvidas independentemente, têm um escopo em constante mudança ou são sensíveis ao tempo. É SUGERIDO que aqueles que usam CalVer incluam um valor de nível micro, porque incluir um nível micro suporta branches mantidos simultaneamente sempre que isso se tornar necessário. Outros formatos de numeração de versão podem ser usados como números de versão, incluindo IDs de commit do git ou IDs de changeset do mercurial, desde que identifiquem exclusivamente as versões. No entanto, algumas alternativas (como IDs de commit do git) podem causar problemas como identificadores de lançamento, porque os usuários podem não ser capazes de determinar facilmente se estão atualizados. O formato do ID de versão pode não ser importante para identificar lançamentos de software se todos os destinatários executarem apenas a versão mais recente (por exemplo, é o código para um único site ou serviço de internet que é constantemente atualizado via entrega contínua).

    The source version follows the SemVer prerelease form 0.4.0-rc.1. Python packaging uses its ecosystem-compatible 0.4.0rc1 representation. Evidence: https://github.com/ha-homelab/ruview-home-sensing/blob/d71f09cdc6948fb131c247ae51a2ada1af27a942/version ; https://github.com/ha-homelab/ruview-home-sensing/blob/d71f09cdc6948fb131c247ae51a2ada1af27a942/pyproject.toml


    Suficiente para um badge!

    É SUGERIDO que os projetos identifiquem cada lançamento dentro de seu sistema de controle de versão. Por exemplo, é SUGERIDO que aqueles que usam git identifiquem cada lançamento usando tags do git. [version_tags]

    The published initial prerelease v0.4.0-rc.1 is identified by the Git tag of the same name, which resolves to source commit d71f09cdc6948fb131c247ae51a2ada1af27a942. The prerelease tag remains immutable and distinct from the later main-branch merge; no stable release is claimed. Evidence: https://github.com/ha-homelab/ruview-home-sensing/releases/tag/v0.4.0-rc.1 ; https://github.com/ha-homelab/ruview-home-sensing/tree/v0.4.0-rc.1


  • Notas de lançamento


    Suficiente para um badge!

    O projeto DEVE fornecer, em cada lançamento, notas de lançamento que sejam um resumo legível por humanos das principais mudanças nesse lançamento para ajudar os usuários a determinar se devem atualizar e qual será o impacto da atualização. As notas de lançamento NÃO DEVEM ser a saída bruta de um log de controle de versão (por exemplo, os resultados do comando "git log" não são notas de lançamento). Projetos cujos resultados não se destinam à reutilização em vários locais (como o software para um único site ou serviço) E empregam entrega contínua PODEM selecionar "N/A". (URL obrigatória) [release_notes]
    As notas de lançamento PODEM ser implementadas de várias maneiras. Muitos projetos as fornecem em um arquivo chamado "NEWS", "CHANGELOG" ou "ChangeLog", opcionalmente com extensões como ".txt", ".md" ou ".html". Historicamente, o termo "change log" significava um log de todas as mudanças, mas para atender a esses critérios, o que é necessário é um resumo legível por humanos. As notas de lançamento PODEM, em vez disso, ser fornecidas por mecanismos de sistema de controle de versão, como o fluxo de trabalho GitHub Releases.

    The sole published release, v0.4.0-rc.1, includes human-readable notes explaining the initial software components, separate bridge dependency, the source archive and wheel, compatibility and installation-policy requirements, security fixes, and experimental limitations. The notes link the exact source and validation run and explicitly do not claim stable promotion, deployment, a Passing badge or physical-device qualification. Evidence: https://github.com/ha-homelab/ruview-home-sensing/releases/tag/v0.4.0-rc.1 ; https://github.com/ha-homelab/ruview-home-sensing/blob/d71f09cdc6948fb131c247ae51a2ada1af27a942/docs/distribution.md


    Suficiente para um badge!

    As notas de lançamento DEVEM identificar todas as vulnerabilidades de tempo de execução publicamente conhecidas corrigidas neste lançamento que já tinham uma atribuição CVE ou similar quando o lançamento foi criado. Este critério pode ser marcado como não aplicável (N/A) se os usuários normalmente não conseguem atualizar o software por conta própria (por exemplo, como geralmente é verdade para atualizações de kernel). Este critério se aplica apenas aos resultados do projeto, não às suas dependências. Se não houver notas de lançamento ou se não houve vulnerabilidades publicamente conhecidas, escolha N/A. [release_notes_vulns]
    Este critério ajuda os usuários a determinar se uma determinada atualização irá corrigir uma vulnerabilidade que é publicamente conhecida, para ajudar os usuários a tomar uma decisão informada sobre atualização. Se os usuários normalmente não conseguem atualizar o software por conta própria em seus computadores, mas devem depender de um ou mais intermediários para realizar a atualização (como é frequentemente o caso de um kernel e software de baixo nível que está entrelaçado com um kernel), o projeto pode escolher "não aplicável" (N/A) em vez disso, já que essa informação adicional não será útil para esses usuários. Da mesma forma, um projeto pode escolher N/A se todos os destinatários executarem apenas a versão mais recente (por exemplo, é o código para um único site ou serviço de internet que é constantemente atualizado via entrega contínua). Este critério se aplica apenas aos resultados do projeto, não às suas dependências. Listar as vulnerabilidades de todas as dependências transitivas de um projeto torna-se difícil conforme as dependências aumentam e variam, e é desnecessário já que ferramentas que examinam e rastreiam dependências podem fazer isso de uma forma mais escalável.

    No qualifying publicly known project-runtime vulnerability with a CVE or equivalent assignment has been identified for this initial prerelease. Its notes nevertheless describe the project security fixes. CVE-2026-59890 / GHSA-h35f-9h28-mq5c, also discussed in the notes, concerns the external setuptools build dependency and is outside this criterion's project-results scope. Reassess when a release fixes a qualifying assigned project vulnerability. Evidence: https://github.com/ha-homelab/ruview-home-sensing/releases/tag/v0.4.0-rc.1 ; https://github.com/ha-homelab/ruview-home-sensing/security/advisories


 Relatórios 8/8 ●

  • Processo de relato de bugs


    Suficiente para um badge!

    O projeto DEVE fornecer um processo para os usuários enviarem relatórios de bugs (por exemplo, usando um rastreador de problemas ou uma lista de discussão). (URL obrigatória) [report_process]

    CONTRIBUTING asks reporters to open an issue with observed behavior, expected results and a minimal fictional reproduction. The public repository has an enabled issue tracker. Evidence: https://github.com/ha-homelab/ruview-home-sensing/blob/d71f09cdc6948fb131c247ae51a2ada1af27a942/CONTRIBUTING.md ; https://github.com/ha-homelab/ruview-home-sensing/issues


    Suficiente para um badge!

    O projeto DEVERIA usar um rastreador de problemas para rastrear problemas individuais. [report_tracker]

    The project uses an enabled public GitHub issue tracker for individual reports. Evidence: https://github.com/ha-homelab/ruview-home-sensing/issues


    Suficiente para um badge!

    O projeto DEVE reconhecer a maioria dos relatórios de bugs enviados nos últimos 2-12 meses (inclusive); a resposta não precisa incluir uma correção. [report_responses]

    The maintainer reports no qualifying external bug reports during the assessment period. The newly created public tracker currently contains no bug issues. This is a no-report assessment, not an invented response record. Evidence: https://github.com/ha-homelab/ruview-home-sensing/issues


    Suficiente para um badge!

    O projeto DEVERIA responder a uma maioria (>50%) das solicitações de melhorias nos últimos 2-12 meses (inclusive). [enhancement_responses]
    A resposta PODE ser 'não' ou uma discussão sobre seus méritos. O objetivo é simplesmente que haja alguma resposta a algumas solicitações, o que indica que o projeto ainda está ativo. Para fins deste critério, os projetos não precisam contar solicitações falsas (por exemplo, de spammers ou sistemas automatizados). Se um projeto não estiver mais fazendo melhorias, selecione "não atendido" e inclua a URL que torna esta situação clara para os usuários. Se um projeto tende a ser sobrecarregado pelo número de solicitações de melhorias, selecione "não atendido" e explique.

    The maintainer reports no qualifying external enhancement requests during the assessment period. The newly created public tracker currently contains no enhancement issues. Evidence: https://github.com/ha-homelab/ruview-home-sensing/issues


    Suficiente para um badge!

    O projeto DEVE ter um arquivo publicamente disponível para relatórios e respostas para pesquisa posterior. (URL obrigatória) [report_archive]

    GitHub provides a public searchable archive of open and closed issues and their responses; the initial pull-request discussion is also publicly retained. Evidence: https://github.com/ha-homelab/ruview-home-sensing/issues?q=is%3Aissue ; https://github.com/ha-homelab/ruview-home-sensing/pull/1


  • Processo de relato de vulnerabilidades


    Suficiente para um badge!

    O projeto DEVE publicar o processo para relatar vulnerabilidades no site do projeto. (URL obrigatória) [vulnerability_report_process]
    Projetos hospedados no GitHub DEVERIAM considerar habilitar o relato privado de uma vulnerabilidade de segurança. Projetos no GitLab DEVERIAM considerar usar sua capacidade de relatar uma vulnerabilidade de forma privada. Projetos PODEM identificar um endereço de e-mail em https://PROJECTSITE/security, frequentemente na forma security@example.org. Este processo de relato de vulnerabilidades PODE ser o mesmo que seu processo de relato de bugs. Relatórios de vulnerabilidades PODEM ser sempre públicos, mas muitos projetos têm um mecanismo de relato de vulnerabilidades privado.

    SECURITY explains the confidential reporting route, requested reproduction information and handling boundaries. GitHub private vulnerability reporting is enabled for this repository. Evidence: https://github.com/ha-homelab/ruview-home-sensing/blob/d71f09cdc6948fb131c247ae51a2ada1af27a942/SECURITY.md ; https://github.com/ha-homelab/ruview-home-sensing/security/advisories/new


    Suficiente para um badge!

    Se relatórios privados de vulnerabilidades forem suportados, o projeto DEVE incluir como enviar as informações de uma forma que seja mantida privada. (URL obrigatória) [vulnerability_report_private]
    Exemplos incluem um relatório de defeito privado enviado na web usando HTTPS (TLS) ou um e-mail criptografado usando OpenPGP. Se relatórios de vulnerabilidades forem sempre públicos (portanto, nunca há relatórios privados de vulnerabilidades), escolha "não aplicável" (N/A).

    The enabled GitHub private vulnerability-reporting form is the documented confidential intake. Reporters are told not to publish credentials or sensitive reproduction data in a public issue. Evidence: https://github.com/ha-homelab/ruview-home-sensing/blob/d71f09cdc6948fb131c247ae51a2ada1af27a942/SECURITY.md ; https://github.com/ha-homelab/ruview-home-sensing/security/advisories/new


    Suficiente para um badge!

    O tempo de resposta inicial do projeto para qualquer relatório de vulnerabilidade recebido nos últimos 6 meses DEVE ser menor ou igual a 14 dias. [vulnerability_report_response]
    Se não houve vulnerabilidades relatadas nos últimos 6 meses, escolha "não aplicável" (N/A).

    The maintainer reports no vulnerability reports in the preceding six months. This no-report applicability assessment does not assert a demonstrated response-time record. Evidence: https://github.com/ha-homelab/ruview-home-sensing/blob/d71f09cdc6948fb131c247ae51a2ada1af27a942/SECURITY.md


 Qualidade 8/13 ●

 Segurança 5/16 ●

 Análise 8/8 ●


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

Entrada de selo do projeto de propriedade de: alvit.
Entrada criada em 2026-10-17 23:08:53 UTC, última atualização em 2026-10-18 00:10:48 UTC.