homelab-dns

遵循以下最佳实践的项目将能够自愿的自我认证，并显示他们已经实现了核心基础设施计划（OpenSSF）徽章。

没有一套可以保证软件永远不会有缺陷或漏洞的做法；如果规范或假设是错误的，即使合适的方法也可能失败。也没有哪些做法可以保证一个项目能够维持健康和运作良好的开发者社区。但是，遵循最佳做法可以帮助改善项目的成果。例如，一些做法可以在发布之前进行多人评估，这可以帮助您找到其他难以找到的技术漏洞，并帮助建立信任，并希望不同公司的开发人员之间进行重复的交互。要获得徽章，必须满足所有“必须”和“禁止”的条款，满足所有“应该”条款或有合适的理由，和所有“建议”条款必须满足或未满足（至少希望考虑）。欢迎通过 GitHub网站创建问题或提出请求进行反馈。另外还有一个一般讨论邮件列表。

如果这是您的项目，请在项目页面上显示您的基准徽章状态！基准徽章状态如下所示： 项目4607的基准徽章等级为in_progress 以下是如何嵌入基准徽章：
您可以通过将其嵌入到Markdown文件中来显示您的基准徽章状态：
[![OpenSSF Baseline](https://www.bestpractices.dev/projects/4607/baseline)](https://www.bestpractices.dev/projects/4607)
或者将其嵌入到HTML中：
<a href="https://www.bestpractices.dev/projects/4607"><img src="https://www.bestpractices.dev/projects/4607/baseline"></a>


这些是基准等级1的标准。

Baseline Series: 基准等级1 基准等级2 基准等级3

        

 基本

 控制 0/24 ●

  • 控制


    未知的所需信息，不足以用于徽章。

    当用户尝试读取或修改项目权威存储库中的敏感资源时，系统必须要求用户完成多因素认证过程。 [OSPS-AC-01.01]
    为项目的版本控制系统强制执行多因素认证，要求协作者在访问敏感数据或修改存储库设置时提供第二种形式的认证。通行密钥对于此控制是可接受的。

    未知的所需信息，不足以用于徽章。

    当添加新的协作者时，版本控制系统必须要求手动分配权限，或默认将协作者权限限制为可用的最低权限。 [OSPS-AC-02.01]
    大多数公共版本控制系统都是这样配置的。确保项目的版本控制系统在添加协作者时始终默认分配最低可用权限,仅在必要时授予额外权限。

    未知的所需信息，不足以用于徽章。

    当尝试直接提交到项目的主分支时,强制机制必须阻止该更改的应用。 [OSPS-AC-03.01]
    如果VCS是集中式的,请在项目的VCS中对主分支设置分支保护。或者,使用去中心化方法,如Linux内核的方法,即先在另一个仓库中提出更改,将更改合并到主仓库需要特定的单独操作。

    未知的所需信息，不足以用于徽章。

    当尝试删除项目的主分支时,版本控制系统必须将此视为敏感活动,并要求明确确认意图。 [OSPS-AC-03.02]
    在项目的版本控制系统中对主分支设置分支保护以防止删除。

    未知的所需信息，不足以用于徽章。

    当CI/CD管道接受输入参数时,该参数必须在管道中使用之前进行清理和验证。 [OSPS-BR-01.01]

    未知的所需信息，不足以用于徽章。

    当CI/CD管道在其功能中使用分支名称时,该名称值必须在管道中使用之前进行清理和验证。 [OSPS-BR-01.02]

    未知的所需信息，不足以用于徽章。

    当项目将URI列为官方项目渠道时,该URI必须仅通过加密渠道交付。 [OSPS-BR-03.01]
    配置项目的网站和版本控制系统使用SSH或HTTPS等加密渠道进行数据传输。确保项目文档中引用的所有工具和域名只能通过加密渠道访问。

    未知的所需信息，不足以用于徽章。

    当项目将URI列为官方分发渠道时,该URI必须仅通过加密渠道交付。 [OSPS-BR-03.02]
    配置项目的发布管道,仅从使用SSH或HTTPS等加密渠道进行数据传输的网站、API响应和其他服务获取数据。

    未知的所需信息，不足以用于徽章。

    项目必须防止在版本控制系统中意外存储未加密的敏感数据,例如机密和凭据。 [OSPS-BR-07.01]
    配置.gitignore或等效文件以排除可能包含敏感信息的文件。使用预提交钩子和自动扫描工具来检测和防止在提交中包含敏感数据。

    未知的所需信息，不足以用于徽章。

    当项目发布版本后,项目文档必须包含所有基本功能的用户指南。 [OSPS-DO-01.01]
    为项目的所有基本功能创建用户指南或文档,说明如何安装、配置和使用项目的功能。如果存在任何已知的危险或破坏性操作,请包含高度可见的警告。

    未知的所需信息，不足以用于徽章。

    当项目发布版本后,项目文档必须包含缺陷报告指南。 [OSPS-DO-02.01]
    建议项目使用其VCS默认问题跟踪器。如果使用外部来源,请确保项目文档和贡献指南清晰且明显地解释如何使用报告系统。建议项目文档还设定缺陷将如何分类和解决的期望。

    未知的所需信息，不足以用于徽章。

    在活跃期间,项目必须有一个或多个机制用于公开讨论提议的更改和使用障碍。 [OSPS-GV-02.01]
    在项目中建立一个或多个公开讨论机制,例如邮件列表、即时消息或问题跟踪器,以促进开放的沟通和反馈。

    未知的所需信息，不足以用于徽章。

    在活跃期间,项目文档必须包含贡献流程的说明。 [OSPS-GV-03.01]
    创建一个CONTRIBUTING.md或CONTRIBUTING/目录来概述贡献流程，包括提交更改的步骤以及与项目维护者互动的方式。

    未知的所需信息，不足以用于徽章。

    活跃期间，源代码的许可证必须符合OSI开源定义或FSF自由软件定义。 [OSPS-LE-02.01]
    向项目的代码仓库添加一个LICENSE文件，其中包含开放源代码促进会（OSI）批准的许可证，或自由软件基金会（FSF）批准的自由许可证。此类许可证的示例包括MIT、BSD 2-Clause、BSD 3-Clause修订版、Apache 2.0、较宽松GNU通用公共许可证（LGPL）和GNU通用公共许可证（GPL）。如果没有其他限制（如专利），发布到公共领域可以满足此控制要求。

    未知的所需信息，不足以用于徽章。

    活跃期间，已发布软件资产的许可证必须符合OSI开源定义或FSF自由软件定义。 [OSPS-LE-02.02]
    如果已发布软件资产包含不同的许可证，请确保它是开放源代码促进会（OSI）批准的许可证，或自由软件基金会（FSF）批准的自由许可证。此类许可证的示例包括MIT、BSD 2-Clause、BSD 3-Clause修订版、Apache 2.0、较宽松GNU通用公共许可证（LGPL）和GNU通用公共许可证（GPL）。请注意，已发布软件资产的许可证可能与源代码的许可证不同。

    未知的所需信息，不足以用于徽章。

    活跃期间，源代码的许可证必须保存在相应仓库的LICENSE文件、COPYING文件或LICENSE/目录中。 [OSPS-LE-03.01]
    将项目的源代码许可证包含在项目的LICENSE文件、COPYING文件或LICENSE/目录中，以提供许可条款的可见性和清晰性。文件名可以有扩展名。如果项目有多个仓库，请确保每个仓库都包含许可证文件。

    未知的所需信息，不足以用于徽章。

    活跃期间，已发布软件资产的许可证必须包含在已发布的源代码中，或包含在与相应发布资产一起的LICENSE文件、COPYING文件或LICENSE/目录中。 [OSPS-LE-03.02]
    将项目的已发布软件资产许可证包含在已发布的源代码中，或包含在与相应发布资产一起的LICENSE文件、COPYING文件或LICENSE/目录中，以提供许可条款的可见性和清晰性。文件名可以有扩展名。如果项目有多个仓库，请确保每个仓库都包含许可证文件。

    未知的所需信息，不足以用于徽章。

    活跃期间，项目的源代码仓库必须在静态URL上可公开读取。 [OSPS-QA-01.01]
    使用常见的版本控制系统（VCS），如GitHub、GitLab或Bitbucket。确保仓库可公开读取。避免重复或镜像仓库，除非有高度可见的文档说明主要来源。避免频繁更改会影响仓库URL的仓库。确保仓库是公开的。

    未知的所需信息，不足以用于徽章。

    版本控制系统必须包含所有更改的可公开读取的记录，包括谁进行了更改以及更改的时间。 [OSPS-QA-01.02]
    使用常见的版本控制系统（VCS），如GitHub、GitLab或Bitbucket来维护可公开读取的提交历史记录。避免压缩或重写提交，以免掩盖任何提交的作者。

    未知的所需信息，不足以用于徽章。

    当包管理系统支持时，源代码仓库必须包含一个依赖项列表，该列表涵盖直接的语言依赖项。 [OSPS-QA-02.01]
    这可以采用包管理器或语言依赖文件的形式，列举所有直接依赖项，如package.json、Gemfile或go.mod。

    未知的所需信息，不足以用于徽章。

    活跃期间，项目文档必须包含被视为子项目的任何代码库的列表。 [OSPS-QA-04.01]
    记录由项目生成并编译到发布版本中的任何附加子项目代码仓库。此文档应包括相应代码库的状态和意图。

    未知的所需信息，不足以用于徽章。

    活跃期间，版本控制系统中不得包含生成的可执行工件。 [OSPS-QA-05.01]
    删除项目版本控制系统中生成的可执行工件。建议在任何情况下，如果生成的可执行工件对测试等过程至关重要，应该在构建时生成，或单独存储并在特定的、有详细文档记录的管道步骤中获取。

    未知的所需信息，不足以用于徽章。

    活跃期间，版本控制系统中不得包含无法审查的二进制工件。 [OSPS-QA-05.02]
    不要将任何无法审查的二进制工件添加到项目的版本控制系统中。这包括可执行应用程序二进制文件、库文件和类似的工件。这不包括资产，如图形图像、声音或音乐文件以及通常以二进制格式存储的类似内容。

    未知的所需信息，不足以用于徽章。

    在活动期间，项目文档必须包含安全联系人。 [OSPS-VM-02.01]
    创建一个security.md（或类似名称）文件，其中包含项目的安全联系人。


此数据在知识共享署名3.0或更高版本许可证（CC-BY-3.0 +） 下可用。所有内容都可以自由分享和演绎，但必须给予适当的署名。请署名为Dominik Strässle和OpenSSF最佳实践徽章贡献者。

项目徽章条目拥有者： Dominik Strässle.
最后更新于 2021-01-21 13:58:57 UTC, 最后更新于 2021-01-21 13:58:57 UTC。