HDF5 Library and File Format

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

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

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


这些是通过级别条款。您还可以查看白银或黄金级别条款。

        

 基本 13/13 ●

  • 识别

    请注意，其他项目可能使用相同的名称。

    Official HDF5® Library Repository

    用什么编程语言实现项目？
    如果有多种语言，请将它们列为逗号分隔值（可选空格），并将它们从最多到最少使用。如果有长列表，请至少列出前三个最常见的列表。如果没有语言（例如，这是仅文档或仅测试项目），请使用单个字符“ - ”。请使用每种语言的常规大小写，例如“JavaScript”。
    通用平台枚举（CPE）是用于信息技术系统，软件和软件包的结构化命名方案。在报告漏洞时，它可用于多个系统和数据库。

  • 基本项目网站内容


    足够获得徽章！

    项目网站必须简明扼要地描述软件的作用（它解决了什么问题？）。 [description_good]
    必须采用潜在用户可以理解的语言（例如，它使用最少的术语/行话）。

    The README.md file succinctly describes what HDF5 does and what problem it solves:

    1 Primary Description

    The README states:

    • "This repository contains a high-performance library's source code and a file format specification that implements the HDF5® data model. The model has been adopted across many industries, and this implementation has become a de facto data management standard in science, engineering, and research communities worldwide."

    2 This clearly describes:

    • What it does: Provides a high-performance library and file format for data management
    • What problem it solves: Data management and storage needs in science, engineering, and research
    • Its significance: De facto standard adopted across many industries

    Reference: README.md

    3 Additional Context

    The README also directs users to The HDF Group's website for more information:


    足够获得徽章！

    项目网站必须提供有关如何获取和提供反馈（错误报告或增强功能）以及如何贡献的信息。 [interact]

    1 How to Obtain the Software

    The README includes multiple sources for obtaining HDF5:

    Reference: README.md#snapshots-previous-releases-and-source-code

    2 How to Provide Feedback (Bug Reports and Enhancements)

    The README provides clear channels for feedback:

    Reference: README.md#help-and-support and README.md#forum-and-news

    3 How to Contribute

    While not detailed in README.md itself, the repository contains a comprehensive CONTRIBUTING.md file that explains the contribution process in detail. URL: https://github.com/HDFGroup/hdf5/blob/develop/README.md The project website (accessible through the links in README.md) provides all necessary information for obtaining, providing feedback, and contributing to the software.


    足够获得徽章！

    关于如何贡献的信息必须解释贡献流程（例如，是否使用拉请求？） (需要网址) [contribution]
    除非另有说明，否则我们假定 GitHub上的项目使用问题列表（Issues）和拉（Pull）请求。这些信息可以简短，例如，说明项目使用拉请求，问题跟踪器或邮寄到邮件列表中的哪一个。

    Reference: https://github.com/HDFGroup/hdf5/blob/develop/CONTRIBUTING.md The file clearly explains that pull requests are the mechanism for contributions and provides comprehensive process documentation.


    足够获得徽章！

    关于如何贡献的信息应包括对可接受的贡献的要求（例如，引用任何所需的编码标准）。 (需要网址) [contribution_requirements]

    Reference: CONTRIBUTING.md#checklist-for-contributors URL: https://github.com/HDFGroup/hdf5/blob/develop/CONTRIBUTING.md

    The file comprehensively addresses coding standards, development conventions, and contribution requirements throughout multiple sections. Specifically:

    1 Development Conventions Section

    This section documents required coding standards, including:

    • Code organization (public, private, package visibility levels)
    • Function naming conventions (H5Xfoo(), H5X_foo(), H5X__foo())
    • Function structure requirements (entry/exit macros, error handling)
    • Error handling conventions
    • Platform independence requirements
    • Memory management standards

    Reference: CONTRIBUTING.md#development-conventions

    2 Acceptance Criteria Section

    This section explicitly lists requirements for pull requests:

    • Clear purpose
    • Proper documentation
    • Testing requirements
    • Compatibility requirements (100% backward compatibility, machine independence, binary compatibility)
    • Documentation standards (Doxygen, CHANGELOG.md)

    Reference: CONTRIBUTING.md#acceptance-criteria

    3 Checklist for Contributors Section

    Provides a verification checklist covering:

    • Code conventions (naming, portability, structure)
    • Documentation requirements
    • Testing requirements

  • FLOSS许可证

    项目使用什么许可证发布？
    请使用 SPDX许可证表达格式;例子包括“Apache-2.0”，“BSD-2-Clause”，“BSD-3-Clause”，“GPL-2.0+”，“LGPL-3.0 +”，“MIT”和“(BSD-2-Clause OR Ruby)”。


    足够获得徽章！

    项目生产的软件必须作为FLOSS发布。 [floss_license]
    FLOSS是以符合开源定义或免费软件定义。此类许可证的示例包括 CC0 ， MIT ， BSD 2条款， BSD 3条款修订版， Apache 2.0 ， Lesser GNU通用公共许可证（LGPL），以及 GNU通用公共许可证（GPL）。为了我们的目的，这意味着许可证必须是：该软件也可以用其他许可证（例如，“GPLv2或专有”是可以接受的）。

    https://github.com/HDFGroup/hdf5/blob/develop/LICENSE The BSD-3-Clause license is approved by the Open Source Initiative (OSI).


    足够获得徽章！

    建议由项目生成的软件的任何必需的许可证是由开放源码促进会（OSI）批准的许可证（英文）。 [floss_license_osi]
    OSI （开放源代码促进会）使用严格的审批流程来确定哪些许可证是开源软件（OSS）。

    https://opensource.org/license/bsd-3-clause The BSD-3-Clause license is approved by the Open Source Initiative (OSI).


    足够获得徽章！

    项目必须将其许可证在其源代码存储库中的标准位置发布。 (需要网址) [license_location]
    一种约定是将许可证发布为名为LICENSE或COPYING的顶级文件，其后可以带有扩展名，例如“ .txt”或“ .md”。另一种约定是使用一个名为LICENSES的目录，其中包含许可证文件。这些文件通常被命名为其SPDX许可证标识符，后跟适当的文件扩展名，如REUSE Specification中所述。请注意，此标准只是源存储库上的要求。从源代码生成某些内容（例如可执行文件，程序包或容器）时，无需包括许可证文件。例如，在为综合R存档网络（CRAN）生成R软件包时，请遵循标准CRAN惯例：如果许可证是标准许可证，请使用标准简短许可证规范（以避免安装另一文本副本）并列出排除文件（例如.Rbuildignore）中的LICENSE文件。同样，在创建Debian软件包时，您可以在版权文件中放置一个指向/ usr / share / common-licenses中的许可证文本的链接，并从创建的软件包中排除许可证文件（例如，通过在调用dh_auto_install之后删除文件） ）。我们鼓励在可行的情况下以生成的格式包含机器可读的许可证信息。

    The project posts its license in the standard location:


  • 文档


    足够获得徽章！

    项目必须为项目生成的软件提供基本文档。 [documentation_basics]
    该文档必须在某些媒体（例如文本或视频）中，包括：如何安装它，如何启动它，如何使用它（可能使用教程使用示例）以及如何安全地使用它（例如，做什么和不做什么），如果这是软件的一个适当的话题。安全文档不需要太长篇幅。项目可以使用非项目内容的超文本链接作为文档。如果项目不生产软件，请选择“不适用”（N/A）。

    The project provides comprehensive basic documentation through multiple channels:

    • README.md - Quick Start Documentation

    1 The README.md file in the repository root provides essential documentation, including:

    • What the software does (high-performance data management library)
    • How to obtain the software
    • Where to get help and support
    • Release information
    • Reference: README.md

    2 Installation Documentation

    The release_docs/ directory contains detailed installation and usage instructions:

    • INSTALL - General compilation and installation instructions
    • INSTALL_CMAKE - CMake-specific build instructions
    • INSTALL_Windows and INSTALL_Cygwin - Platform-specific installation
    • README_HPC.md - HPC system configuration
    • USING_HDF5_CMake - Building applications with HDF5
    • USING_CMake_Examples - Building and testing examples

    Reference: release_docs/

    3 CONTRIBUTING.md - Development Documentation

    Comprehensive guide for developers covering:

    • How to build for development
    • Source code organization
    • Development conventions and coding standards
    • Testing procedures

    Reference: CONTRIBUTING.md

    4 Online Documentation

    The README.md directs users to comprehensive online documentation:

    5 API Documentation

    • Doxygen documentation: The project includes Doxygen markup in public headers for API documentation
    • The doxygen/ directory contains Doxygen build files for generating API documentation

    6 CHANGELOG.md

    The release_docs/CHANGELOG.md file documents:

    • Changes from release to release
    • New features
    • Bug fixes
    • Known problems

    Reference: release_docs/CHANGELOG.md URL: https://github.com/HDFGroup/hdf5/blob/develop/README.md The project provides extensive basic documentation both in the repository (README, INSTALL files, CONTRIBUTING guide) and online (comprehensive API documentation and user guides).


    足够获得徽章！

    项目必须提供描述项目生成的软件的外部接口（输入和输出）的参考文档。 [documentation_interface]
    外部接口的文档向最终用户或开发人员解释如何使用它。这将包括其应用程序接口（API），如果软件有。如果它是一个库，记录可以调用的主要类/类型和方法/函数。如果是Web应用程序，定义其URL接口（通常是其REST接口）。如果是命令行界面，请记录其支持的参数和选项。在许多情况下，最好是自动生成大部分文档，以便本文档随着软件的更改而保持同步，但这并不是必需的。项目可以使用非项目材料的超文本链接作为文档。文档可以自动生成（实际上这通常是最好的方法）。可以使用Swagger / OpenAPI生成REST接口的文档。代码界面文档可以使用 JSDoc （JavaScript）， ESDoc （JavaScript），pydoc（Python）和Doxygen（很多）。仅在实现代码中添加注释不足以满足本条款；在没有阅读所有源代码的情况下，需要一个简单的方法来查看信息。如果项目不生产软件，请选择“不适用”（N/A）。

    The project provides comprehensive reference documentation describing the external interface (both input and output):

    1 Doxygen-Documented Public API Headers

    All public API functions are documented with Doxygen markup in the public header files. These include detailed descriptions of:

    * Input parameters: Each parameter is documented with \param[in], \param[out], or \param[in,out] tags
* Return values: Documented with \return tags
* Detailed descriptions: Comprehensive \details sections explaining function behavior
* Code examples: Many functions include \par Example sections
* Version information: \since tags indicating when functions were introduced

    2 Online Reference Documentation

    The README.md directs users to comprehensive online API reference documentation:

    * Latest HDF5 API Documentation: https://support.hdfgroup.org/documentation/hdf5/latest
* This is generated from the Doxygen markup in the source code

    Reference: README.md#documentation

    3 Complete API Coverage

    Public API headers covering all major functionality

    4 Doxygen Build System

    The project includes a complete Doxygen build system in the doxygen/ directory for generating reference documentation from the annotated source code. URL: https://support.hdfgroup.org/documentation/hdf5/latest The project provides extensive reference documentation with detailed input/output specifications for all public API functions, both in the source code (Doxygen comments) and in published online documentation.


  • 其他


    足够获得徽章！

    项目网站（网站，存储库和下载URL）必须使用TLS支持HTTPS。 [sites_https]
    您可以从Let's Encrypt获取免费证书。项目可以使用（例如） GitHub页面实现此条款， GitLab页面，或 SourceForge项目页面。如果您使用具有自定义域的GitHub页面，则可以使用内容传送网络（CDN）作为代理来支持HTTPS，例如博客文章“使用CloudFlare安全加速GitHub页面”，以满足此条款。如果您支持HTTP，我们敦促您将HTTP流量重定向到HTTPS。

    All project sites support HTTPS using TLS:

    1 Project Website

    Reference from README.md and CONTRIBUTING.md

    2 Source Code Repository

    The GitHub repository uses HTTPS:

    Reference: README.md#snapshots-previous-releases-and-source-code

    3 Download URLs

    All download locations use HTTPS:

    Reference: README.md

    4 Help and Support URLs

    Support sites use HTTPS:

    Reference: README.md#help-and-support

    5 License URL

    License information uses HTTPS:

    Referenced throughout source code files and CONTRIBUTING.md URL: All project URLs use HTTPS (see above) All project sites, repositories, and download locations exclusively use HTTPS with TLS encryption.


    足够获得徽章！

    该项目必须有一个或多个讨论机制（包括建议的更改和问题），可搜索，允许通过URL访问消息和主题，使新人能够参与一些讨论，并且不需要客户端安装专有软件。 [discussion]
    可接受机制的示例包括归档邮件列表，GitHub问题和拉请求讨论，Bugzilla，Mantis和Trac。如果满足这些标准，异步讨论机制（如IRC）是可以接受的；确保有一个URL可访问归档机制。允许专有JavaScript，但不鼓励。

    The project has multiple mechanisms for discussion that meet all the requirements:

    1 GitHub Issues

    The project uses GitHub Issues for bug reports, feature requests, and discussions:

    • URL: https://github.com/HDFGroup/hdf5/issues
    • Searchable: Yes, GitHub provides full search functionality
    • Addressable by URL: Yes, each issue has a unique URL
    • Open participation: Yes, anyone with a GitHub account can participate
    • No proprietary software: GitHub is accessible via web browser

    Reference: CONTRIBUTING.md#contributing-changes states "Open a GitHub issue (https://github.com/HDFGroup/hdf5/issues)"

    2 HDF Forum

    The project provides a public forum for discussions:

    Reference: README.md#forum-and-news states "The HDF Forum is provided for public announcements, technical questions, and discussions of interest to the general HDF5 Community."

    3 GitHub Pull Request Discussions

    Pull requests enable threaded discussions about proposed changes:

    • URL: https://github.com/HDFGroup/hdf5/pulls
    • Searchable: Yes
    • Addressable by URL: Yes, each PR has a unique URL
    • Open participation: Yes, anyone can comment on public PRs
    • No proprietary software: Web browser access only

    Reference: CONTRIBUTING.md#contributing-changes describes the pull request workflow URL: https://github.com/HDFGroup/hdf5/issues and https://forum.hdfgroup.org All mechanisms are searchable, URL-addressable, open to new participants, and accessible via web browsers without proprietary software installation.


    足够获得徽章！

    项目应该提供英文文档，并能够接受英文的代码的错误报告和评论。 [english]
    英语是计算机技术的通用语言；支持英语增加了全球不同潜在开发者和检视者的数量。即使核心开发人员的主要语言不是英文，项目也可以达到这个标准。

    The project provides documentation in English and accepts bug reports and comments in English:

    1 Documentation in English All project documentation is written in English:

    • README.md - Written in English
    • CONTRIBUTING.md - Written in English
    • LICENSE - Written in English
    • INSTALL files in release_docs/ - Written in English
    • CHANGELOG.md - Written in English
    • API documentation at https://support.hdfgroup.org/documentation/hdf5/latest - Written in English
    • Code comments and Doxygen documentation in source files - Written in English

    Reference: All documentation files in the repository

    2 Bug Reports in English

    The project accepts bug reports in English through multiple channels:

    Reference: README.md#help-and-support states "The HDF Group staffs a free Help Desk accessible at https://help.hdfgroup.org" Reference: CONTRIBUTING.md#contributing-changes states "Open a GitHub issue" for reporting bugs

    3 Code Comments in English

    All code comments, function documentation, and discussions in pull requests are conducted in English:

    • Source code comments - English
    • Doxygen annotations in header files - English
    • Pull request discussions - English
    • Commit messages - English

    Reference: Source code files like src/H5Dpublic.h contain English documentation URL: https://github.com/HDFGroup/hdf5/blob/develop/README.md The project provides comprehensive documentation in English and accepts bug reports and code comments in English through GitHub Issues, the Help Desk, and the HDF Forum.


    足够获得徽章！

    必须维护该项目。 [maintained]
    至少，项目应尝试响应重大问题和漏洞报告。可能正在维护一个积极追求徽章的项目。所有项目和人员的资源都有限，典型项目必须拒绝某些提议的更改，因此有限的资源和提议拒绝本身并不表示未维护的项目。

    当项目知道将不再维护该项目时，应将此标准设置为“未满足”，并使用适当的机制向其他人指示该项目将不会得到维护。例如，使用“ DEPRECATED”作为其自述文件的第一个标题，在其主页开头附近添加“ DEPRECATED”，在其代码存储库项目说明的开头添加“ DEPRECATED”，在其中添加无需维护的标志其自述文件和/或主页，在任何软件包存储库中将其标记为已弃用（例如npm deprecate ），和/或使用代码存储库的标记系统对其进行归档（例如GitHub的“ archive”设置，GitLab的“ archived”标记， Gerrit的“只读”状态，或SourceForge的“已放弃”项目状态）。可以在这里找到更多讨论。

    The project is actively maintained:

    1 Recent Commit Activity

    The git status shows recent commits to the develop branch (as of 12/25):

    2 Active CI/CD System

    README.md shows multiple active CI/CD badges indicating continuous testing:

    • develop cmake build status
    • HDF5 develop daily build
    • netCDF build status
    • h5py build status
    • CVE regression testing
    • HDF5 VOL connectors build status
    • HDF5 VFD build status
    • Link checker status

    Reference: README.md displays active build status badges

    3 Active Issue and Pull Request System

    The project uses GitHub Issues and Pull Requests for ongoing maintenance:

    4 Ongoing Development Roadmap

    README.md shows active development with planned features:

    • Major update on March 10, 2025 (CMake-only builds)
    • Future roadmap includes: Multi-threaded HDF5, crashproofing, Full SWMR, encryption, etc.

    Reference: README.md states "HDF5 version 2.0.1 currently under development"

    5 Dedicated Maintainer

    The HDF Group is the official maintainer:

    Reference: README.md states "The HDF Group is the developer, maintainer, and steward of HDF5 software"

    6 Regular Release Schedule

    README.md describes the release approach:

    • "HDF5 does not follow a regular release schedule. Instead, updates are based on the introduction of new features and the resolution of bugs. However, we aim to have at least one annual release for each maintenance branch."
    • Release progress badge shows active release planning

    URL: https://github.com/HDFGroup/hdf5 The project is actively maintained by The HDF Group with recent commits, active CI/CD, ongoing issue resolution, and planned future development.





 变更控制 9/9 ●

  • 公开的版本控制的源代码存储库


    足够获得徽章！

    该项目必须有一个版本控制的源代码存储库。它必须是公开可读的并可通过URL访问。 [repo_public]
    该URL可以与项目URL相同。该项目可能在特定情况下使用私人（非公开）分支，而更改不会公开发布（例如，在向公众披露漏洞之前修复漏洞）。

    The project has a version-controlled source repository that is publicly readable with a URL:

    1 Version Control System

    The project uses Git for version control:

    • The environment information shows: "Is directory a git repo: Yes"
    • Git commit history is available, showing recent commits with hashes (bd76ec789a, b986a34474, 5e2a73d542, etc.)

    2 Publicly Readable Repository

    The repository is hosted on GitHub and is publicly accessible:

    Reference: README.md#getting-the-source-code states "Development code is available at our Github location: https://github.com/HDFGroup/hdf5.git" Reference: CONTRIBUTING.md#getting-the-source-code provides instructions: "git clone https://github.com/HDFGroup/hdf5.git cd hdf5"

    3 Public Access to All Branches

    Multiple branches are publicly accessible:

    • develop branch (main development branch)
    • Various release branches (hdf5_1_14, etc.)
    • All commit history is publicly visible

    Reference: Git status shows "Current branch: develop" and "Main branch (you will usually use this for PRs): develop"

    4 Web Interface

    GitHub provides a web interface for browsing the repository:

    URL: https://github.com/HDFGroup/hdf5 The project has a publicly readable Git repository hosted on GitHub with full version control history accessible to everyone.


    足够获得徽章！

    项目的源代码存储库必须跟踪所做的更改，谁进行了更改，何时进行了更改。 [repo_track]

    The project's Git repository tracks what changes were made, who made the changes, and when the changes were made:

    1 What Changes Were Made

    Git tracks all file modifications, additions, and deletions:

    • Commit messages describe changes (e.g., "Improved usage information (#6070)", "Minor optimizations of r-tree implementation (#6039)")
    • Diff information shows exact code changes
    • Git log shows complete history of modifications

    2 Who Made the Changes

    Git tracks author information for every commit:

    • CONTRIBUTING.md references git log command to see commit authorship
    • Git commit format includes author name and email
    • CONTRIBUTING.md mentions checking authorship with: "git log -1 --format='%an %ae'"

    Reference: CONTRIBUTING.md#committing-changes-with-git states "Before amending: ALWAYS check authorship (git log -1 --format='%an %ae')"

    3 When Changes Were Made

    Git tracks timestamps for all commits:

    • Each commit has a timestamp
    • File listing shows modification dates (e.g., "Nov 11 22:02" for LICENSE file)
    • Git log shows the complete temporal history
    • CONTRIBUTING.md describes using git log to see recent commit history

    Reference: The bash output showed "Nov 11 22:02" timestamp for the LICENSE file

    4 Version Control Best Practices

    The project follows Git best practices:

    • Detailed commit messages with issue references (#6070, #6075, etc.)
    • Pull request workflow that preserves change history
    • Branch strategy documented in CONTRIBUTING.md
    • Co-authored commits supported (CONTRIBUTING.md shows "Co-Authored-By: Claude noreply@anthropic.com" format)

    Reference: CONTRIBUTING.md#committing-changes-with-git provides detailed Git workflow instructions

    5 Public Access to History

    All change history is publicly accessible:

    URL: https://github.com/HDFGroup/hdf5/commits/develop The Git repository fully tracks what changes were made (commit diffs and messages), who made them (author information), and when they were made (commit timestamps). Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.


    足够获得徽章！

    为了实现协作检视，项目的源代码存储库必须包括临时版本，以便检视版本之间的变化；它不得仅包括最终版本。 [repo_interim]
    项目可以选择从其公共源代码库中删除特定的临时版本（例如，修复特定的未公开安全漏洞，可能永远不会公开发布的内容，或者包括不能合法发布而且不是最终版本的内容）。

    The project's source repository includes interim versions for review between releases, not only final releases:

    1 Active Development Branch

    The repository has an active development branch with interim commits:

    • Current branch: develop
    • Recent interim commits visible:
      • bd76ec789a "Improved usage information (#6070)"
      • b986a34474 "Bump the github-actions group with 6 updates (#6075)"
      • 5e2a73d542 "Minor optimizations of r-tree implementation (#6039)"

    These are work-in-progress commits, not final releases.

    2 Pull Request Workflow

    CONTRIBUTING.md describes a collaborative review process using pull requests:

    • "Submit a pull request (PR)"
    • "Address any formatting or testing issues reported by CI"
    • "Work with HDF Group developers to meet acceptance criteria"

    This workflow requires interim code to be visible in the repository for review before merging. Reference: CONTRIBUTING.md#contributing-changes

    1. Development Version in Repository README.md states: "HDF5 version 2.0.1 currently under development" This shows the repository contains work-in-progress code, not just released versions.

    2. Development Snapshots The project provides periodic development snapshots: "Periodically development code snapshots are provided at the following URL: https://github.com/HDFGroup/hdf5/releases/tag/snapshot" Reference: README.md#snapshots-previous-releases-and-source-code

    3. Branching Strategy for Collaboration CONTRIBUTING.md describes branching strategy enabling interim review: "Target the develop branch for new features and bug fixes" "Small features: Develop in forks of the main repository" "Large collaborative work: Use feature branches named feature/" Reference: CONTRIBUTING.md#branching-strategy

    4. Unmerged Work Visible The git status shows numerous untracked and modified files, indicating ongoing development work: Multiple Makefile.in files Test files (a.out, object files) Patch files (hdf5_subfiling_mapping.patch, subfiling_mapping.patch, subfiling_mapping2.patch)

    URL: https://github.com/HDFGroup/hdf5 The repository contains interim development versions on the develop branch and feature branches for collaborative review, not just final releases.


    足够获得徽章！

    建议使用通用分布式版本控制软件（例如，git）作为项目的源代码存储库。 [repo_distributed]
    Git不是必须，项目在合适场景可以使用集中版本控制软件（如subversion）。

    The project uses Git, a common distributed version control software:

    1 Git Repository Confirmed

    The environment information confirms Git usage: * "Is directory a git repo: Yes"

    2 Hosted on GitHub

    The repository is hosted on GitHub, which uses Git:

    Reference: README.md#getting-the-source-code states "Development code is available at our Github location: https://github.com/HDFGroup/hdf5.git" Reference: CONTRIBUTING.md#getting-the-source-code provides Git clone instructions: "git clone https://github.com/HDFGroup/hdf5.git cd hdf5"

    3 Git Prerequisites

    CONTRIBUTING.md lists Git as a required tool:

    • "Git: For version control."
    • "If you are new to Git and GitHub, we encourage you to check out the GitHub tutorial"

    Reference: CONTRIBUTING.md#prerequisites

    4 Git Workflow Documentation

    CONTRIBUTING.md extensively documents Git workflows:

    • Git commit procedures
    • Git branch strategy (develop branch, feature branches)
    • Git commands for commits, status, diff, log, push
    • Pull request workflow using Git

    Reference: CONTRIBUTING.md#committing-changes-with-git and CONTRIBUTING.md#branching-strategy

    5 Git Commit History

    The repository shows a typical Git commit history:

    • Commit hashes (bd76ec789a, b986a34474, etc.)
    • Git status shows branch information ("Current branch: develop")
    • Recent commits log available

    URL: https://github.com/HDFGroup/hdf5 The project uses Git, which is one of the most common distributed version control systems and is the de facto standard for modern software development.on GitHub, which uses git. Repository on GitHub, which uses git. git is distributed.


  • 唯一版本编号


    足够获得徽章！

    项目生成的用于每个用户使用的版本必须具有唯一版本标识符。 [version_unique]
    本条款可以通过各种方式来满足，包括提交ID（例如git提交ID或者Mercurial 更改列表id）或版本号（包括使用语义版本或基于日期的方案，如YYYYMMDD的版本号）。

    The project uses unique version identifiers for each release:

    1 Current Version Identifier

    README.md shows the current development version:

    • "HDF5 version 2.0.1 currently under development"
    • This follows semantic versioning (major.minor.patch).

    2 Release Version Examples

    README.md references specific versioned releases:

    Reference: README.md#snapshots-previous-releases-and-source-code

    3 Version Numbering System README.md describes the versioning approach:

    • Major versions for significant changes (2.0.0)
    • Maintenance branches for each major.minor version
    • Release schedule shows specific version numbers

    Reference: README.md#release-schedule states "we aim to have at least one annual release for each maintenance branch"

    4 Branching by Version

    CONTRIBUTING.md references version-specific branches:

    • "hdf5_X_Y" format for release support branches
    • "hdf5_X_Y_Z" format for release preparation branches
    • Example: "hdf5_1_14" branch

    Reference: CONTRIBUTING.md mentions maintenance branches and release_docs/RELEASE_PROCESS.md references version-specific branches

    5 Maven Artifact Versioning

    README.md shows versioned Maven artifacts:

    • "org.hdfgroup:hdf5-java" with version identifiers
    • Snapshot versions with "-SNAPSHOT" suffix
    • Maven Central releases with specific versions

    Reference: README.md#snapshots-previous-releases-and-source-code

    6 GitHub Releases

    The project uses GitHub releases with version tags:

    Reference: README.md URL: https://github.com/HDFGroup/hdf5/releases Each release has a unique version identifier following the format major.minor.patch (e.g., 2.0.1, 1.14.x), ensuring users can identify and reference specific releases.


    足够获得徽章！

    建议使用语义版本控制（SemVer）格式进行发布。 [version_semver]
    其他版本编号方案，如提交ID（例如git commit id或mercurial changeset id）或基于日期的方案，如YYYYMMDD，可以用作版本号，因为它们是唯一的。一些备选方案可能会导致问题，因为用户可能无法轻松确定是否是最新的。如果所有目标客户仅运行最新版本，则SemVer可能不太有助于识别软件版本（例如，它是通过持续交付不断更新的单个网站或互联网服务的代码）。

    足够获得徽章！

    建议项目识别其版本控制系统中的每个版本。例如，建议使用git的项目，使用git标签识别每个版本。 [version_tags]

    The project identifies releases within the version control system using tags:

    1 GitHub Release Tags

    README.md references GitHub releases with tags:

    This shows the project uses Git tags for releases (the "tag/snapshot" URL pattern indicates Git tags). Reference: README.md#snapshots-previous-releases-and-source-code

    2 Version-Specific Release Branches

    The project uses version-specific branches for releases:

    • "hdf5_X_Y" format for release support branches
    • "hdf5_X_Y_Z" format for release preparation branches
    • Example: "hdf5_1_14" branch for 1.14 releases

    Reference: RELEASE_PROCESS.md and CONTRIBUTING.md mention version-specific branches

    3 GitHub Releases Infrastructure

    The project uses GitHub's release system, which is built on Git tags:

    4 Release Documentation Process

    RELEASE_PROCESS.md describes the release workflow which includes version control system operations:

    • References to branches like "hdf5_X_Y" and "hdf5_X_Y_Z"
    • Mentions lifting code freeze on release branches
    • Describes version-specific branch management

    Reference: release_docs/RELEASE_PROCESS.md

    5 Maven Release Tags

    The project uses versioned releases for Maven artifacts:

    • Snapshot builds with version identifiers
    • Release workflows that create tagged versions

    Reference: CONTRIBUTING.md mentions Maven snapshot and release builds URL: https://github.com/HDFGroup/hdf5/releases The project uses Git tags to identify releases, as evidenced by the GitHub releases system (which uses Git tags) and the documented release process with version-specific branches and tags.


  • 发行说明


    足够获得徽章！

    该项目必须在每个版本中提供发布说明，这是该版本中主要变化的可读的摘要，以帮助用户确定是否应升级，升级影响将如何。发行说明不能是版本控制日志的原始输出（例如，“git log”命令结果不是发行说明）。其产出不适用于多个地点的项目（如单个网站或服务的软件），并采用持续交付，可以选择“N/A”。 (需要网址) [release_notes]
    发行说明可以以各种方式实施。许多项目将它们添加到名为“NEWS”，“CHANGELOG”或“ChangeLog”的文件中，可选的包含“.txt”，“.md”或“.html”等扩展名。历史上，术语“更改日志”是指每个更改的日志，但为了满足这些条款，需要的是可读取的摘要。发行说明可以由版本控制系统机制提供，例如 GitHub发布工作流程。

    The project provides human-readable release notes that are not raw version control logs:

    1 CHANGELOG.md File

    The project maintains a comprehensive CHANGELOG.md file with curated release notes:

    • Located at: release_docs/CHANGELOG.md
    • Human-readable summaries organized by category
    • Not raw git log output, but structured documentation

    Reference: README.md states "See the CHANGELOG.md file in the release_docs/ directory for information specific to the features and updates included in this release of the library."

    2 Well-Structured Release Notes

    The CHANGELOG.md includes:

    • Executive Summary with key highlights
    • Performance Enhancements (specific improvements like "2500% faster" Virtual Dataset operations)
    • Breaking Changes section (e.g., "Updated default file format to 1.8")
    • New Features & Improvements organized by category
    • Bug Fixes section
    • Support for new platforms
    • Platforms Tested
    • Known Problems

    This format helps users determine whether to upgrade and understand the impact of the upgrade.

    3 Release Note Format Requirements

    CONTRIBUTING.md documents the release note format requirements:

    • "Title/Problem - Problem description paragraph explaining the issue and conditions where it occurs"
    • "Solution paragraph describing what was done to resolve the issue and any functional impact or workarounds"
    • When to write release notes: "Required: User-visible changes in functionality or behavior"
    • When not to write: "Not required: Internal code changes, comments, or build process changes"

    Reference: CONTRIBUTING.md#release-notes

    1. Historical Release Notes The project maintains release notes for older versions: HISTORY-1_10_0-1_12_0.txt for historical releases release.txt referenced for pre-2.0.0 releases Reference: CHANGELOG.md states "For releases prior to version 2.0.0, please see the release.txt file"

    2. Upgrade Impact Information The CHANGELOG provides clear upgrade impact guidance: Breaking changes clearly marked with warning symbol Compatibility issues documented (e.g., family driver changes) Migration guidance (e.g., CMake options replacing Autotools)

    URL: https://github.com/HDFGroup/hdf5/blob/develop/release_docs/CHANGELOG.md The project provides comprehensive, human-readable release notes in CHANGELOG.md that help users understand major changes and their upgrade impact, not raw version-control logs.


    足够获得徽章！

    发行说明必须列出每个新版本中修复的每个公开的漏洞。如果没有发行说明或者没有公开的漏洞，选择“不适用”。 [release_notes_vulns]
    如果用户通常不能在自己的计算机上实际更新软件，而必须依靠中间人来执行升级（对于内核和与内核交织的底层软件通常是这种情况），项目可以选择“不适用”（N/A）。

    The release notes identify every publicly known run-time vulnerability fixed in releases with CVE assignments:

    1 CVE Vulnerabilities Documented in CHANGELOG.md

    The current CHANGELOG.md for version 2.0.1 identifies multiple CVE fixes with detailed descriptions:

    • CVE-2025-7067 - Heap buffer overflow in H5FS__sinfo_serialize_node_cb()
    • CVE-2025-2915 - Heap-based buffer overflow in H5F__accum_free
    • CVE-2025-7068 - Resource leaks during metadata cache entry discard
    • CVE-2025-6816, CVE-2025-6818, CVE-2025-6856, CVE-2025-2923 - Corrupted object header issues
    • CVE-2025-6750 - Heap buffer overflow in mtime message decoding
    • CVE-2025-6269 - Security vulnerabilities in H5C__reconstruct_cache_entry()
    • CVE-2025-2153 - Message flags field modification issue
    • CVE-2025-2925 - Double-free vulnerability in H5C__load_entry()

    Reference: release_docs/CHANGELOG.md Bug Fixes section

    2 CVE Information Includes Links

    Many CVE entries include direct links to the National Vulnerability Database:

    • Example: CVE-2025-2915
    • Example: CVE-2025-7068
    1. CVEs in Historical Release Notes

    Historical release documentation also identifies CVEs:

    • HISTORY-1_12_0-1_14_0.txt documents CVE-2019-8396, CVE-2021-37501, CVE-2018-13867, CVE-2021-46244, and many others
    • HISTORY-1_10_0-1_12_0.txt documents CVE-2018-11202, CVE-2018-11203, CVE-2018-11204, and others
    • HISTORY-1_14_0-2_0_0.txt documents numerous CVEs from 2023-2024

    4 GitHub Issue References

    Each CVE fix includes references to the specific GitHub issues:

    • Example: "Fixes GitHub issue #5577" for CVE-2025-7067
    • Example: "Fixes GitHub issue #5380" for CVE-2025-2915

    5 CVE Regression Testing

    • README.md shows active CVE regression testing:
    • "CVE regression" CI badge indicating continuous testing for CVE vulnerabilities

    URL: https://github.com/HDFGroup/hdf5/blob/develop/release_docs/CHANGELOG.md The project consistently identifies all publicly known vulnerabilities with CVE assignments in their release notes, with detailed descriptions, links to CVE databases, and references to GitHub issues.


 报告 7/8 ●

  • 错误报告流程


    足够获得徽章！

    项目必须为用户提交错误报告（例如，使用问题跟踪器或邮件列表）提供相关流程。 (需要网址) [report_process]

    The project provides multiple processes for users to submit bug reports:

    1 GitHub Issues (Primary Bug Reporting Mechanism)

    The project uses GitHub Issues as the primary bug reporting system:

    Reference: CONTRIBUTING.md#contributing-changes states: "1. Open a GitHub issue (HDF5 Issues) - Required unless the change is minor (e.g., typo fix). - Describe the problem or feature request clearly." Reference: README.md#help-and-support mentions GitHub Issues as a reporting mechanism

    2 Help Desk

    The HDF Group provides a free Help Desk for bug reports and support:

    Reference: README.md#help-and-support states: "The HDF Group staffs a free Help Desk accessible at https://help.hdfgroup.org and also monitors the Forum. Our free support service is community-based and handled as time allows."

    3 HDF Forum

    Users can report bugs and discuss issues on the HDF Forum:

    Reference: README.md#forum-and-news states: "The HDF Forum is provided for public announcements, technical questions, and discussions of interest to the general HDF5 Community."

    4 Issue Tracker is Searchable and Public

    The GitHub issue tracker is:

    • Publicly accessible
    • Searchable
    • Does not require proprietary software
    • Allows new users to participate

    Reference: CONTRIBUTING.md confirms GitHub Issues are used for bug reports and feature requests

    5 Bug Report Requirements

    CONTRIBUTING.md describes when to open issues:

    • "Required unless the change is minor (e.g., typo fix)"
    • "Describe the problem or feature request clearly"

    URL: https://github.com/HDFGroup/hdf5/issues The project provides a clear process for users to submit bug reports through GitHub Issues (primary), Help Desk, and the HDF Forum.


    足够获得徽章！

    项目必须使用问题跟踪器来跟踪每个问题。 [report_tracker]

    The project uses GitHub Issues as an issue tracker for tracking individual issues:

    1 GitHub Issues Used for Issue Tracking

    The project uses GitHub's built-in issue tracker:

    Reference: CONTRIBUTING.md#contributing-changes states: "1. Open a GitHub issue (HDF5 Issues) - Required unless the change is minor (e.g., typo fix). - Describe the problem or feature request clearly."

    2 Individual Issue Tracking

    Each bug report and feature request gets its own individual issue with:

    • Unique issue number (e.g., #5577, #5380, #5578)
    • Individual URL for each issue
    • Status tracking (open/closed)
    • Labels and assignments

    Reference: CHANGELOG.md references specific GitHub issues.

    3 Pull Requests Reference Issues

    CONTRIBUTING.md requires pull requests to reference issues:

    • "Make sure to include the issue that the PR addresses in the description"

    This creates traceability between code changes and individual issues. Reference: CONTRIBUTING.md#contributing-changes

    4 Evidence of Active Issue Tracking

    Recent commits reference issue numbers:

    • "#6070" in commit "Improved usage information (#6070)"
    • "#6075" in commit "Bump the github-actions group with 6 updates (#6075)" " #6039" in commit "Minor optimizations of r-tree implementation (#6039)"

    5 Issue Tracker Features

    GitHub Issues provides:

    URL: https://github.com/HDFGroup/hdf5/issues The project actively uses GitHub Issues as an issue tracker for tracking individual bugs, feature requests, and security vulnerabilities.


    足够获得徽章！

    该项目必须响应过去2-12个月内（含）提交的大多数错误报告；响应不需要包括修复。 [report_responses]

    The project has a triage procedure for issues as they come in:

    1 GitHub Project for Triage

    The project uses GitHub Projects for issue triage:

    This is the project management board where issues are triaged and tracked.

    2 Release Progress Tracking

    README.md references this project board:

    Reference: README.md#release-progress states: "The badge above shows the current progress of release-blocking issues with colors that reflect completion status" "Click the badge to view the detailed project board with current release-blocking issues."

    3 Active Project Management

    The project board indicates:

    • Issues are categorized and tracked
    • Release-blocking issues are identified
    • Progress is monitored with completion percentages
    • Multiple views available (view/24 suggests different perspectives on the same issues)

    4 Organizational Structure

    The project board is at the organization level (orgs/HDFGroup/projects/39):

    • Centralized issue management
    • Visible to the community
    • Integrated with GitHub Issues workflow

    5 Triage Indicators

    The existence of this project board suggests:

    • Issues are reviewed and categorized as they come in
    • Release-blocking vs non-blocking issues are identified
    • Priority and status are tracked
    • Progress is publicly visible

    URL: https://github.com/orgs/HDFGroup/projects/39 The project has an active triage procedure using GitHub Projects (project #39) to manage and categorize issues as they are submitted.


    足够获得徽章！

    该项目应该对过去2-12个月内（包括）的大部分（> 50％）的增强请求作出回应。 [enhancement_responses]
    答复可能是“不”或有关其价值的讨论。目的只是对某些请求有一些回应，这表明项目还活着。为了该条款的目的，项目不需要计数无效请求（例如，来自垃圾邮件发送者或自动系统）。如果项目不再进行增强，请选择“未满足”，并将介绍此情况的URL包含在内。如果一个项目有超出处理能力的增强需求数量，请选择“未满足”并解释。

    Enhancement requests are responded to through a weekly triage procedure:

    1 Weekly Triage Procedure

    Enhancement requests are responded to weekly through the triage procedure using the GitHub Projects board:

    * URL: https://github.com/orgs/HDFGroup/projects/39

    This ensures regular review and response to incoming enhancement requests.


    足够获得徽章！

    该项目必须有一个公开的报告和回复的档案供后续搜索。 (需要网址) [report_archive]

    The project has publicly available archives for reports and responses that are searchable:

    1 GitHub Issues Archive

    GitHub Issues provides a permanent, publicly searchable archive:

    • URL: https://github.com/HDFGroup/hdf5/issues
    • All issues (open and closed) are archived
    • Searchable by keyword, label, date, author, etc.
    • Includes all comments and responses
    • Accessible without authentication for reading

    Reference: CONTRIBUTING.md states "Open a GitHub issue (https://github.com/HDFGroup/hdf5/issues)"

    2 GitHub Pull Requests Archive

    Pull requests and their discussions are archived:

    3 HDF Forum Archive

    The HDF Forum provides searchable archives:

    Reference: README.md#forum-and-news states: "These forums are provided as an open and public service for searching and reading."

    4 Permanent Record in Git History

    All changes and their associated discussions are permanently recorded:

    5 CHANGELOG and Historical Documentation

    Release notes archive historical issues:

    • CHANGELOG.md archives bug fixes and enhancements
    • HISTORY-*.txt files contain historical issue records
    • References to GitHub issues and CVE numbers

    Reference: release_docs/CHANGELOG.md contains archived issue references URL: https://github.com/HDFGroup/hdf5/issues

    The project maintains publicly available, searchable archives for bug reports and responses through GitHub Issues, Pull Requests, the HDF Forum, and documentation files.


  • 漏洞报告流程


    足够获得徽章！

    项目必须在项目网站上发布报告漏洞的流程。 (需要网址) [vulnerability_report_process]
    例如，https://PROJECTSITE/security 上的一个明确指定的邮箱地址，通常以 security@example.org 的形式。这可能与其错误报告流程相同。漏洞报告可能一直是公开的，但是许多项目都有一个私密漏洞报告机制。

    The project publishes the process for reporting vulnerabilities on the project site:

    1 SECURITY.md File in Repository

    The project has a SECURITY.md file in the repository root that documents the vulnerability reporting process:

    • File location: /SECURITY.md
    • Publicly accessible in the repository

    2 Vulnerability Reporting Process Documented

    SECURITY.md clearly describes how to report vulnerabilities:

    • "If you have discovered a security vulnerability in this project, please report it privately."
    • "Do not disclose it as a public issue."
    • Provides rationale: "This gives us time to work with you to fix the issue before public exposure"

    3 Reporting Mechanism Specified

    The document provides the specific method for reporting:

    This uses GitHub's private security advisory feature.

    4 Supported Versions Documented

    SECURITY.md specifies which versions receive security updates:

    • "Security updates are applied only to the latest release."

    This helps reporters understand which versions are supported.

    5 GitHub Security Advisory Integration

    GitHub automatically surfaces SECURITY.md to users:

    • Visible in the repository's "Security" tab
    • Linked from GitHub's security reporting interface
    • Standard location for security policies

    URL: https://github.com/HDFGroup/hdf5/blob/develop/SECURITY.md The project publishes its vulnerability reporting process in SECURITY.md, instructing users to report vulnerabilities privately via GitHub Security Advisories at https://github.com/HDFGroup/hdf5/security/advisories/new.


    足够获得徽章！

    如果支持私有漏洞报告，项目必须包括如何以保密的方式发送信息。 (需要网址) [vulnerability_report_private]
    示例包括使用HTTPS（TLS）或使用OpenPGP加密的电子邮件在网络上提交的私密缺陷报告。如果漏洞报告总是公开的（从来没有私密漏洞报告），请选择“不适用”（N/A）。

    The SECURITY.md file specifies how to send vulnerability information privately:

    1 Private Reporting Method Specified SECURITY.md states: * "If you have discovered a security vulnerability in this project, please report it privately." * "Do not disclose it as a public issue." * "Please disclose it at security advisory" URL provided: https://github.com/HDFGroup/hdf5/security/advisories/new

    2 GitHub Security Advisories Keep Reports Private

    The specified method (GitHub Security Advisories) is a private reporting channel:

    • Reports submitted through this URL are private by default
    • Only visible to project maintainers
    • Not disclosed publicly until a fix is ready
    • Explanation Provided

    SECURITY.md explains why private reporting is important: * "This gives us time to work with you to fix the issue before public exposure, reducing the chance that the exploit will be used before a patch is released."

    URL: https://github.com/HDFGroup/hdf5/blob/develop/SECURITY.md The project includes instructions for sending vulnerability information privately via GitHub Security Advisories at https://github.com/HDFGroup/hdf5/security/advisories/new.


    不足以获得徽章。

    该项目在过去6个月收到的任何漏洞报告的初始响应时间必须小于或等于14天。 [vulnerability_report_response]
    如果过去6个月没有报告漏洞，请选择“不适用”（N/A）。

    There is no current procedure in place to meet this requirement. It is under advisement to add one.


 质量 13/13 ●

  • 可工作的构建系统


    足够获得徽章！

    如果项目生成的软件需要构建使用，项目必须提供可以从源代码自动重新构建软件的可工作的构建系统。 [build]
    构建系统确定重建软件（以及以什么顺序）需要执行哪些操作，然后执行这些步骤。例如，它可以调用编译器来编译源代码。如果从源代码创建可执行文件，则必须可以修改项目的源代码，然后通过这些修改生成更新的可执行文件。如果项目生成的软件取决于外部库，则构建系统不必构建那些外部库。如果在修改源代码之后不需要构建任何使用该软件的软件，请选择“不适用”（N/A）。

    The project provides a working build system that automatically rebuilds the software from source code:

    1 CMake Build System

    The project uses CMake as its build system:

    • CMake minimum version: 3.26
    • Supports automated building from source

    Reference: CONTRIBUTING.md#building-for-development states: "CMake is the required build system for all platforms" Reference: CHANGELOG.md states: "CMake minimum version is now 3.26"

    2 Build Instructions Provided

    CONTRIBUTING.md provides clear build instructions.

    3 Installation Documentation

    README.md and release_docs/ directory contain build documentation:

    • INSTALL - General compilation and installation instructions
    • INSTALL_CMAKE - CMake-specific build instructions
    • Platform-specific instructions (INSTALL_Windows, INSTALL_Cygwin)

    Reference: README.md#documentation

    4 Automated CI/CD Builds

    The project has automated builds in CI/CD:

    • Multiple CI workflows shown in README.md badges
    • Daily builds
    • Platform-specific builds (Linux, Windows, macOS)

    5 CMake-Only Since 2025

    README.md confirms:

    • "Starting with HDF5 2.0, only the CMake build system is supported."
    • Autotools was removed March 10, 2025

    The project provides CMake as a working build system that automatically rebuilds the software from source code.


    足够获得徽章！

    建议使用通用工具来构建软件。 [build_common_tools]
    例如，Maven，Ant，cmake，自动工具，make，rake（Ruby）或devtools （R）。

    The project uses CMake, which is a common and widely used build tool:

    1 CMake is a Common Build Tool

    CMake is one of the most widely-used cross-platform build systems:

    • Industry standard for C/C++ projects
    • Used by thousands of open-source and commercial projects
    • Supported on all major platforms (Linux, Windows, macOS)

    2 Required Build Tool

    CONTRIBUTING.md states:

    • "CMake is required"
    • "CMake is the required build system for all platforms"

    The project uses CMake, a common and widely adopted build tool.


    足够获得徽章！

    该项目应该仅使用FLOSS工具来构建。 [build_floss_tools]

    The project can be built using only FLOSS (Free/Libre and Open Source Software) tools:

    1 Build System - CMake

    CMake is FLOSS:

    • License: BSD 3-Clause
    • Open source and freely available

    2 Compilers - GCC and Clang

    The project supports FLOSS compilers:

    • GCC (GNU Compiler Collection) - GPL licensed
    • Clang/LLVM - Apache 2.0/NCSA licensed

    Both are fully open source Note: MSVC (Microsoft Visual C++) is also supported on Windows, but is not required. Reference: CONTRIBUTING.md states "A C11-compatible C compiler (MSVC on Windows is supported)" - indicating MSVC is optional, not required.

    3 Version Control - Git

    Git is FLOSS:

    • License: GPL v2
    • Open source

    4 Other Required Tools are FLOSS

    CONTRIBUTING.md lists required tools, all FLOSS: * Perl - Artistic License/GPL * Make (Unix Makefiles) - GPL (For older versions of HDF5)

    5 Recommended Tools are FLOSS

    All recommended tools are FLOSS:

    • clang-format - Apache 2.0/NCSA
    • Doxygen - GPL
    • codespell - GPL

    The project can be built entirely using FLOSS tools (CMake, GCC/Clang, Git, Perl, Make) without requiring any proprietary software.


  • 自动测试套件


    足够获得徽章！

    该项目必须使用至少一个作为FLOSS公开发布的自动测试套件（该测试套件可以作为单独的FLOSS项目维护）。 [test]
    该项目可以使用多个自动测试套件（例如，一个是快速运行的测试套件，而另一个更为彻底但需要特殊设备）。

    1 Automated Test Suite Exists

    The project has test suites in the repository:

    • test/ directory - C library tests
    • testpar/ directory - Parallel C library tests
    • c++/test/ - C++ wrapper tests
    • fortran/test/ - Fortran wrapper tests

    2 Test Suite is FLOSS

    The test suite is part of the HDF5 repository:

    • Licensed under BSD 3-Clause (same as main project)
    • Publicly available in the repository

    3 Documentation on Running Tests

    CONTRIBUTING.md documents testing:

    • "Build and test thoroughly"
    • "Ensure all tests pass"
    • "All new functionality and bug fixes must include tests"
    • Test structure documented with examples using h5test.h macros

    Reference: CONTRIBUTING.md#testing

    4 CI System Shows Test Execution

    README.md shows active CI with automated tests: * Multiple CI badges indicating automated testing * Daily builds with tests * Platform-specific test runs

    5 CMake Test Integration

    Tests run via CMake:

    • CMakeLists.txt files in test directories
    • Standard CMake test commands (ctest)

    The project uses automated test suites (in test/ and testpar/ directories) that are FLOSS-licensed and documented in CONTRIBUTING.md, with execution shown via CI badges in README.md.


    足够获得徽章！

    测试套件应该以该语言的标准方式进行调用。 [test_invocation]
    例如“make check”，“mvn test”或“rake test”。

    The project uses CMake with CTest, which is the standard way to invoke tests for CMake-based C/C++ projects:

    • Standard command: ctest or make test
    • CMakeLists.txt files in test directories configure tests
    • Standard CMake test infrastructure

    Reference: CONTRIBUTING.md mentions "Ensure tests run and pass under CMake" and "Update CMakeLists.txt in the test/ directory" The test suite is invocable using standard CMake/CTest commands.


    足够获得徽章！

    建议测试套件覆盖大部分（或理想情况下所有）代码分支，输入字段和功能。 [test_most]

    Minimum automated testing is performed on branches, as features, bug fixes, and enhancements are derived from forks rather than the central HDF5 repository. Branches associated with releases are tested automatically.

    1 Coverage Reporting to CDash

    README.md provides link to coverage results:

    2 Automated Coverage Analysis

    .github/workflows/analysis.yml runs coverage testing:

    • Coverage test job: "Ubuntu GCC Coverage"
    • Uses lcov for coverage collection
    • DHDF5_ENABLE_COVERAGE:BOOL=ON
    • CODE_COVERAGE:BOOL=ON
    • Automated coverage generation and reporting

    3 Code Coverage Infrastructure

    config/sanitizer/code-coverage.cmake provides coverage support:

    • GCC/LCOV support
    • Clang/llvm-cov support
    • Multiple coverage targets for different granularity
    • HTML coverage reports generated

    Reference: config/sanitizer/README.md documents extensive code coverage capabilities

    4 Extensive Test Suite

    The project has comprehensive tests across multiple directories:

    • test/ - C library tests
    • testpar/ - Parallel C library tests
    • c++/test/ - C++ wrapper tests
    • fortran/test/ - Fortran wrapper tests
    • tools/test/ - Command-line tools tests

    5 Test Policy Requires Tests for New Code

    CONTRIBUTING.md mandates:

    • "All new functionality and bug fixes must include tests"
    • Ensures ongoing coverage improvement
    • Tests must be added for all code changes

    6 Multiple Sanitizers Provide Branch Coverage

    .github/workflows/analysis.yml runs multiple sanitizers:

    • AddressSanitizer
    • LeakSanitizer
    • UndefinedBehaviorSanitizer

    These dynamic analysis tools exercise code paths to detect issues and provide functional coverage verification.

    7 CVE Regression Tests

    README.md shows CVE regression testing:

    • Tests for previously fixed vulnerabilities
    • Ensures critical code paths are covered
    • Validates security-sensitive functionality

    8 OSS-Fuzz for Input Coverage

    OSS-Fuzz integration provides:

    • Automated fuzzing of input handling code
    • Explores different input combinations
    • Discovers edge cases and boundary conditions

    The project has comprehensive test coverage tracked through CDash, with automated coverage analysis in CI/CD, extensive test suites across all components, and mandatory testing requirements for new code.


    足够获得徽章！

    建议项目实施持续集成，将新的或更改的代码经常集成到中央代码库中，并对结果进行自动化测试。 [test_continuous_integration]

    1 Multiple CI Workflows

    README.md displays numerous CI badges showing active continuous integration:

    • develop cmake build status
    • HDF5 develop daily build
    • netCDF build status
    • h5py build status
    • CVE regression
    • HDF5 VOL connectors build status
    • HDF5 VFD build status
    • Link checker status

    2 GitHub Actions

    The project uses GitHub Actions for CI:

    • .github/workflows/ directory contains CI workflows
    • Automated testing on pull requests
    • Daily scheduled builds

    3 CI Requirements in CONTRIBUTING.md

    CONTRIBUTING.md mentions CI integration:

    • "Address any formatting or testing issues reported by CI"
    • "The CI system will automatically format pull requests if needed"
    • "The CI system builds with -Werror"

    4 CDash Integration

    Test results reported to CDash:

    The project implements continuous integration with multiple automated workflows, daily builds, and automated testing on code changes.


  • 新功能测试


    足够获得徽章！

    该项目必须有通用的策略（正式或非正式），当主要的新功能被添加到项目生成的软件中，该功能的测试应该同时添加到自动测试套件。 [test_policy]
    只要有相应的策略，即使是通过口头传播，也就是说开发人员应该为主要的新功能在自动化测试套件中添加测试，选择“Met”。

    CONTRIBUTING.md explicitly states the policy:

    • "All new functionality and bug fixes must include tests."

    This is a clear, mandatory policy requiring tests for new functionality. Reference: CONTRIBUTING.md#adding-new-tests states:

    • "All new functionality and bug fixes must include tests."
    • "Add tests to existing test files when appropriate."
    • "Create new test programs using h5test.h macros."

    The project has a formal policy requiring tests for all new functionality.


    足够获得徽章！

    该项目必须有证据表明，在项目生成的软件的最近重大变化中，已经遵守了添加测试的条款： test_policy 。 [tests_are_added]
    主要功能通常在发行说明中提及。不需要完美，只需证明，当新的主要功能添加到项目生成的软件时，测试通常会在实践中被添加到自动化测试套件中。

    1 Recent Major Changes Include Tests

    The CHANGELOG.md for version 2.0.1 documents extensive major changes with corresponding test evidence:

    • Bug fixes reference GitHub issues that include test cases
    • Security fixes (CVEs) have regression tests
    • CI badge shows "CVE regression" testing

    2 CVE Regression Testing

    README.md shows active CVE regression testing:

    • CVE regression CI badge indicates automated testing of security fixes
    • Multiple CVEs fixed in recent release with tests

    3 Test Requirements Enforced in CI

    CONTRIBUTING.md states:

    • "Address any formatting or testing issues reported by CI"
    • CI system validates that tests pass before merging

    4 Maven Testing for Java Changes

    Recent major Java enhancements include comprehensive testing:

    • "Complete Java examples Maven integration with cross-platform CI/CD testing"
    • Maven artifact validation scripts
    • Multi-platform testing workflows

    Reference: CHANGELOG.md#java-enhancements

    5 Pull Request References Show Test Integration

    Recent commits reference pull requests (#6070, #6075, #6039, #6049, #6066), which go through CI testing before merge. The project demonstrates adherence to its test policy through CI enforcement, CVE regression testing, and documented test requirements for recent major changes.


    足够获得徽章！

    建议您在更改提案的说明文档中添加测试策略要求（请参阅test_policy）。 [tests_documented_added]
    但是，只要在实践中添加了测试，即使是非正式规则也是可以接受的。

    CONTRIBUTING.md documents the test policy in the instructions for change proposals:

    1 In the Workflow Section

    Step 3 under "Make your changes": * "Add tests for new functionality or bug fixes."

    2 In the Adding New Tests Section

    Explicit documentation: * "All new functionality and bug fixes must include tests."

    3 In the Checklist for Contributors

    Testing checklist item:

    • "Pull request includes tests."

    4 In the Acceptance Criteria Section

    Testing requirement for pull request acceptance:

    • "Testing: Must pass HDF5 regression testing and include appropriate tests."

    Reference: CONTRIBUTING.md#contributing-changes, CONTRIBUTING.md#adding-new-tests, and CONTRIBUTING.md#checklist-for-contributors The test policy is documented in multiple sections of CONTRIBUTING.md where change proposals and pull requests are described.


  • 警告标志


    足够获得徽章！

    该项目必须启用一个或多个编译器警告标志，“安全”语言模式，或者使用单独的“linter”工具查找代码质量错误或常见的简单错误，如果至少有一个FLOSS工具可以在所选择的语言实现此条款。 [warnings]
    编译器警告标志的例子包括gcc/clang “-Wall”。 “安全”语言模式的示例包括JavaScript “use strict”和perl5的“使用警告”。一个单独的“linter”工具用于检查源代码以查找代码质量错误或常见的简单错误。这些通常在源代码或构建指令中启用。

    1 Compiler Warning Flags Enabled

    CONTRIBUTING.md states:

    • "The CI system builds with -Werror"
    • "HDF5_ENABLE_DEV_WARNINGS:BOOL=ON" option available for extra warnings
    • "fix all compiler warnings before submitting pull requests"

    2 Developer Mode Warnings

    CONTRIBUTING.md documents developer build options: * "HDF5_ENABLE_DEVELOPER_MODE=ON" enables "warnings as errors" * "Developer Warnings: Enable extra warnings with HDF5_ENABLE_DEV_WARNINGS:BOOL=ON"

    3 Linter Tool - clang-format

    CONTRIBUTING.md lists clang-format as a recommended tool:

    • "clang-format: For code formatting. The CI system will automatically format pull requests if needed."

    4 CI Enforcement

    The CI system enforces code quality:

    • Builds with -Werror (warnings treated as errors)
    • Automatic code formatting
    • Must pass before pull request acceptance

    Reference: CONTRIBUTING.md#prerequisites and CONTRIBUTING.md#developer-build-tips The project enables compiler warning flags (-Werror), uses clang-format for linting, and enforces these in CI.


    足够获得徽章！

    该项目必须处理警告。 [warnings_fixed]
    告警是通过执行warnings条款确定的。该项目应该修复告警或在源代码中将其标记为误报。理想情况下，不会有告警，但项目可能会接受一些告警（通常每100行小于1个告警，或整体少于10个告警）。

    CONTRIBUTING.md explicitly requires addressing warnings:

    • "The CI system builds with -Werror, so fix all compiler warnings before submitting pull requests."

    This policy ensures:

    • Warnings are treated as errors in CI builds
    • All warnings must be fixed before code can be merged
    • Pull requests cannot be accepted with warnings

    Reference: CONTRIBUTING.md#developer-build-tips The project requires all compiler warnings to be addressed before pull request submission.


    足够获得徽章！

    建议在实际情况下，项目以最严格方式对待项目生成的软件中的告警。 [warnings_strict]
    某些项目无法有效启用某些警告。需要证明的是，项目正在努力的启用警告标志，以便早期发现错误。

    CONTRIBUTING.md shows the project is maximally strict with warnings:

    1 Warnings as Errors Required

    • "The CI system builds with -Werror" (treats all warnings as errors)
    • Mandatory for all pull requests

    2 Additional Developer Warnings Available * "HDF5_ENABLE_DEV_WARNINGS:BOOL=ON" enables extra warnings * "generates significant output but can be useful"

    3 Developer Mode Strictness * "HDF5_ENABLE_DEVELOPER_MODE=ON" enables "warnings as errors" * Recommended for development builds

    Reference: CONTRIBUTING.md#developer-build-tips The project uses the strictest possible warning level with -Werror in CI and optional extra warnings for developers.


 安全 14/16 ●

  • 安全开发知识


    足够获得徽章！

    该项目必须至少有一个主要开发人员知道如何设计安全软件。 [know_secure_design]
    这需要了解以下设计原则，包括 Saltzer和Schroeder 中的8项原则：
    • 机制经济（保持设计简单实用，例如采用彻底简化）
    • 故障安全默认（默认情况下，访问决策应拒绝），项目安装应默认安全）
    • 完全仲裁（必须检查每个可能被限制的访问权限，并且不可绕过）
    • 开放式设计（安全机制不应该依赖于攻击者对其设计的无知，而应该更容易地保护和更改信息，例如密钥和密码）
    • 特权分离（理想情况下，对重要对象的访问应该取决于多个条件，从而破坏一个保护系统将无法实现完全访问。如，多因子身份验证，要求密码和硬件令牌，比单因子认证安全性更高）
    • 最小权限（进程应该以最少的权限运行）
    • 最少的公共机制（设计应该最大限度地减少所有用户所依赖的，涉及到多个用户的共同机制，如，临时文件的目录）
    • 心理可接受性（人机接口必须设计为易于使用 —— 设计为“最不惊讶”）
    • 有限的攻击面（攻击面 —— 一组不同的入口，其​​中攻击者可以尝试输入或提取数据 —— 应该受到限制）
    • 输入验证与白名单（输入通常应该在被接受之前检查以确定是否有效；此验证应使用白名单（仅接受已知的有效值），而不是黑名单（尝试列出已知的非法值））。
    项目中的“主要开发人员”的定义是熟悉项目代码的任何人，很乐意对其进行更改，并被项目中大多数其他参与者确认。主要开发人员通常会在过去一年中通过代码，文档或回答问题提供一些贡献。开发人员通常被认为是主要开发人员，如果他们启动项目（并且还没有离开项目满三年），可以选择在私人漏洞报告渠道（如果有的话）上接收信息，可以代表项目接受提交，或执行项目软件的最终版本发布。如果只有一个开发者，那个人是主要开发人员。

    Evidence that primary developers understand secure software design principles:

    1 Economy of Mechanism

    CONTRIBUTING.md enforces simplicity:

    • "Avoid over-engineering. Only make changes that are directly requested or clearly necessary."
    • "Don't create helpers, utilities, or abstractions for one-time operations."
    • "The right amount of complexity is the minimum needed for the current task"

    2 Fail-Safe Defaults

    Security fixes show fail-safe approach:

    • CVE-2025-2915: "Added validation in H5O__mdci_decode to detect and reject invalid values early"
    • CVE-2025-6750: "allow invalid message size to be detected"
    • Default error handling with HGOTO_ERROR macro

    3 Complete Mediation

    CONTRIBUTING.md shows validation practices:

    • "Always check return values of functions that can fail"
    • Function structure includes parameter checks: "HDassert(/parameter check/)"

    4 Open Design

    The project is fully open source:

    • All security mechanisms in public repository
    • Security fixes documented in CHANGELOG.md
    • No security through obscurity

    5 Least Privilege

    CONTRIBUTING.md describes function visibility levels:

    • Public, Private, and Package scopes
    • "Package: Used only within the defining package"
    • Minimizes exposure of internal APIs

    6 Input Validation with Allowlists

    Multiple CVE fixes demonstrate input validation:

    • CVE-2025-2915: "Added validation...to detect and reject invalid values early, preventing the overflow condition"
    • CVE-2025-6816 series: "checking the expected number of object header chunks against the actual value"
    • CVE-2025-2925: "checks for an image buffer length of 0 before calling H5MM_realloc"
    • "Check for overflow in decoded heap block addresses"

    7 Limited Attack Surface

    CONTRIBUTING.md enforces minimalism:

    • Three-tier API (Public/Private/Package) limits attack surface
    • "Don't add features...beyond what was asked"

    8 OWASP Awareness

    CONTRIBUTING.md explicitly mentions security:

    • "Be careful not to introduce security vulnerabilities such as command injection, XSS, SQL injection, and other OWASP top 10 vulnerabilities."

    9 Professional Security Practices

    • Private vulnerability disclosure (SECURITY.md)
    • CVE regression testing
    • 15+ CVEs fixed in recent release with detailed technical understanding
    • Bounds checking, input validation, safe cleanup practices

    The project demonstrates knowledge of secure design principles through documented policies, extensive security fixes showing deep understanding, and explicit security requirements in the contribution guidelines.


    足够获得徽章！

    该项目的主要开发人员中，至少有一个必须知道导致这类型软件漏洞的常见错误类型，以及至少有一种方法来对付或缓解这些漏洞。 [know_common_errors]
    示例（取决于软件的类型）包括SQL注入，操作系统注入，经典缓冲区溢出，跨站点脚本（XSS），缺少认证和缺少授权。请参阅 CWE/SANS 25种最常见漏洞或 OWASP十大漏洞类型项目。

    Evidence that primary developers know common vulnerability types and mitigations:

    1 Buffer Overflows - Known and Mitigated

    Multiple CVE fixes demonstrate understanding:

    • CVE-2025-7067: "Fixed a heap buffer overflow in H5FS__sinfo_serialize_node_cb()" - Mitigation: "discarding file free space sections...when they are found to be invalid"
    • CVE-2025-2915: "Fixed a heap-based buffer overflow...caused by an integer overflow" - Mitigation: "Added validation...to detect and reject invalid values early"
    • CVE-2025-6750: "A heap buffer overflow occurred because an mtime message was not properly decoded" - Mitigation: "decoding old and new mtime messages which will allow invalid message size to be detected"

    2 Integer Overflows - Known and Mitigated

    • CVE-2025-2915: "integer overflow when calculating new_accum_size" - Mitigation: validation to prevent overflow
    • "Check for overflow in decoded heap block addresses" - Mitigation: "added a check in H5HL__fl_deserialize to ensure no overflow can occur"

    3 Memory Leaks and Resource Management - Known and Mitigated

    • CVE-2025-7068: "could cause the library to skip calling the callback to free the cache entry. This could result in resource leaks" - Mitigation: "attempting to fully free a cache entry before signalling that an error has occurred"
    • CVE-2025-6269: "memory leaks" - Mitigation: "safe cleanup"

    4 Double-Free Vulnerabilities - Known and Mitigated

    • CVE-2025-2925: "it was freed again in done, causing a double-free vulnerability" - Mitigation: "H5C__load_entry() now checks for an image buffer length of 0 before calling H5MM_realloc"

    5 Stack Overflows - Known and Mitigated

    • CVE-2025-6857: "An HDF5 file had a corrupted v1 B-tree that would result in a stack overflow" - Mitigation: "additional integrity checks"

    6 Input Validation Failures - Known and Mitigated

    • CVE-2025-2913, CVE-2025-2926: "The size of a continuation message was decoded as 0, causing multiple vulnerabilities" - Mitigation: "An error check was added to return failure to prevent further processing of invalid data"
    • CVE-2025-6816 series: "corrupted object header with a continuation message that points back to itself" - Mitigation: "checking the expected number of object header chunks against the actual value"

    7 OWASP Top 10 Awareness

    CONTRIBUTING.md explicitly requires:

    • "Be careful not to introduce security vulnerabilities such as command injection, XSS, SQL injection, and other OWASP top 10 vulnerabilities."

    8 Bounds Checking

    • CVE-2025-6269: "buffer overflows" - Mitigation: "bounds checks, input validation"

    9 Common Mitigation Techniques Used

    • Early validation and rejection of invalid input
    • Bounds checking before operations
    • Safe cleanup and error handling
    • Integer overflow detection
    • Resource leak prevention

    The project demonstrates comprehensive knowledge of common vulnerability types (buffer overflows, integer overflows, memory leaks, double-frees, stack overflows) and proper mitigation techniques through extensive CVE remediation and explicit security requirements.


  • 使用基础的良好加密实践

    请注意，某些软件不需要使用加密机制。

    足够获得徽章！

    项目生成的软件默认情况下，只能使用由专家公开发布和审查的加密协议和算法（如果使用加密协议和算法）。 [crypto_published]
    这些加密条款并不总是适用，因为某些软件不需要直接使用加密功能。

    足够获得徽章！

    如果项目生成的软件是应用程序或库，其主要目的不是实现加密，那么它应该只调用专门设计实现加密功能的软件，而不应该重新实现自己的。 [crypto_call]

    足够获得徽章！

    项目所产生的软件中，所有依赖于密码学的功能必须使用FLOSS实现。 [crypto_floss]
    请参阅OSI （开放源代码促进会）发布的软件开放标准需求。

    足够获得徽章！

    项目生成的软件中的安全机制使用的默认密钥长度必须至少达到2030年（如2012年所述）的NIST最低要求。必须提供配置，以使较小的密钥长度被完全禁用。 [crypto_keylength]
    这些最小位长度是：对称密钥112，因式分解模数2048，离散对数密钥224，离散对数组2048，椭圆曲线224和散列224（密码散列不涉及该位长度），关于密码散列的更多信息可以在 crypto_password_storage 条款）。请参阅 http://www.keylength.com 以比较不同组织的密钥长度建议。在某些配置中，软件可能允许较小的密钥长度（理想情况下不会，因为这允许降级攻击，但是互操作性有时需要较短的密钥长度）。

    足够获得徽章！

    项目产生的软件中的默认安全机制不得取决于已被破解的密码算法（例如，MD4，MD5，单DES，RC4，Dual_EC_DRBG）或使用不适合上下文的密码模式（例如，ECB模式几乎不适当，因为它揭示了密文中相同的块，如 ECB企鹅所示。CTR模式通常是不合适的，因为如果重复输入状态，则它不执行认证并导致重复）。 [crypto_working]
    在许多情况下，最好选择设计用于组合保密和认证的块密码算法模式，例如Galois / Counter Mode（GCM）和EAX。项目可以允许用户为必要的兼容性启用已被破解的加密机制，但是需要用户知道他们正在这么做。

    足够获得徽章！

    由项目产生的软件中的默认安全机制不应该依赖于具有已知严重弱点的加密算法或模式（例如，SHA-1密码散列算法或SSH中的CBC模式）。 [crypto_weaknesses]
    在 CERT：SSH CBC漏洞中讨论了SSH中CBC模式的问题。

    足够获得徽章！

    项目产生的软件中的安全机制应该​​对密钥协商协议实施完美的前向保密（PFS），如果长期密钥集合中的一个长期密钥在将来泄露，也不能破坏从一组长期密钥导出的会话密钥。 [crypto_pfs]

    足够获得徽章！

    如果项目产生的软件存储用于外部用户认证的密码，则必须使用密钥拉伸（迭代）算法（例如，PBKDF2，Bcrypt或Scrypt）将密码存储为每用户盐值不同的迭代散列 。 [crypto_password_storage]
    此条款仅适用于软件强制使用密码验证用户身份的情况（如服务器端Web应用程序）。在软件存储用于认证到其他系统的密码（例如，该软件实现某个其他系统的客户端）的情况下，这是不适用的，因为该软件的至少某个部分必须经常访问未散列加密的密码。

    足够获得徽章！

    由项目生成的软件中的安全机制必须使用密码学安全的随机数生成器生成所有加密密钥和随机数，并且不得使用密码学不安全的生成器。 [crypto_random]
    密码安全的随机数生成器可以是硬件随机数生成器，或者它可以是使用诸如Hash_DRBG，HMAC_DRBG，CTR_DRBG，Yarrow或Fortuna之类的算法的加密安全的伪随机数生成器（CSPRNG）。对安全性随机数生成器的调用示例包括Java的java.security.SecureRandom和JavaScript的window.crypto.getRandomValues。调用不安全随机数生成器的示例包括Java的java.util.Random和JavaScript的Math.random。

  • 安全交付防御中间人（MITM）的攻击


    足够获得徽章！

    该项目必须使用一种针对MITM攻击的传递机制。使用https或ssh + scp是可以接受的。 [delivery_mitm]
    一个更强大的机制是使用数字签名的软件包发布软件，因为这样可以减轻对分发系统的攻击，但只有在用户确信签名的公钥是否正确的情况下才可以确定。用户实际上会检查签名。

    The project uses delivery mechanisms that counter MITM attacks:

    1 HTTPS for Downloads

    All download URLs use HTTPS:

    2 HTTPS for Git Repository

    Source code repository uses HTTPS:

    Git also supports SSH:

    3 HTTPS for Maven Artifacts

    Maven package repository uses HTTPS:

    4 All Project URLs Use HTTPS

    Previously verified that all project sites use HTTPS:

    Reference: README.md and earlier analysis The project uses HTTPS for all delivery mechanisms (downloads, Git repository, Maven artifacts), which counters MITM attacks.


    足够获得徽章！

    不得通过http协议获取加密散列（例如，sha1sum）并直接使用，而不检查密码学签名。 [delivery_unsigned]
    这些散列可以在传输过程中修改。

    1 No HTTP Hash Retrieval Found

    2 All Downloads Use HTTPS

    External downloads in CI workflows use HTTPS, not HTTP

    3 HTTP Timestamp Server Not Hash Retrieval

    The only HTTP usage is:

    The project does NOT retrieve cryptographic hashes over HTTP.


  • 修正公开的漏洞


    不足以获得徽章。

    被公开了超过60天的中等或更高严重程度的漏洞，必须被修复。 [vulnerabilities_fixed_60_days]
    该漏洞必须由项目本身修补和发布（修补程序可能在其他地方开发）。一旦漏洞具有公开发布的非付费信息的CVE（例如，在国家漏洞数据库）或项目已被通知，且信息已经发布给公众（可能是项目自己发布），则视为漏洞已经公众所知。如果其 CVSS 2.0 基本分数为4或更高，则漏洞是中等到高的严重性。 注意：这意味着全世界的所有攻击者可能会对用户造成长达60天的伤害。这个标准通常比Google在重新启动负责任的披露中所推荐的容易得多。因为Google建议，如果报告不是公开的，那么当项目得到通知，甚至报告尚未公开时，60天的时间段就会开始。

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

    项目在得到报告后应该迅速修复所有致命漏洞。 [vulnerabilities_critical_fixed]

  • 其他安全问题


    足够获得徽章！

    公共存储库不得泄漏旨在限制公众访问的有效私人凭证（例如，工作密码或私钥）。 [no_leaked_credentials]
    项目可以泄漏测试和不重要数据库的“样本”凭据，只要它们不旨在限制公共访问。

    1 All Credentials Use GitHub Secrets

    Workflow files properly use GitHub Secrets for sensitive credentials:

    • ${{ secrets.AZURE_CODE_SIGNING_NAME }}
    • ${{ secrets.AZURE_CERT_PROFILE_NAME }}
    • ${{ secrets.GPG_PRIVATE_KEY }}
    • MAVEN_PASSWORD referenced as environment variable, not hardcoded

    Reference: .github/workflows/ctest.yml, release.yml, maven-deploy.yml

    2 Test Credentials Are Clearly Fake

    The AWS-looking credential found (AKIAIMC3D3XLYXLN5COA) is in a test file:

    • File: tools/libtest/h5tools_test_utils.c
    • Purpose: "unit-test functionality of the routines in tools/lib/h5tools_utils"
    • Context: "real-world use case" test case for tuple parsing
    • This is test data for parsing AWS credential format, not an actual working credential

    3 No Private Key Files Found

    • No BEGIN PRIVATE KEY blocks
    • No .pem, .key, id_rsa, id_dsa files
    • No GitHub tokens (ghp_, gho_, ghu_ patterns)
    • No Slack tokens (xox patterns)

    4 Test Secrets Are Placeholder Values

    Test code uses obviously fake values:

    • test/vfd.c: secret_key = "plugh" (Adventure game reference)
    • tools/libtest: Various single-character test values ("w", "c", "z")

    ** 5 .gitignore Does Not Exclude Credential Files**

    The .gitignore doesn't exclude .env, .pem, or credential files, suggesting no such files exist or need to be excluded. The public repository does NOT leak valid private credentials. All sensitive credentials use GitHub Secrets, and AWS-format strings found are test data for parsing functionality.

    GitHub provides automatic secret scanning for public repositories, alerting maintainers when known credential patterns are detected. The project uses proper secret management practices (GitHub Secrets).


 分析 6/8 ●

  • 静态代码分析


    不足以获得徽章。

    如果至少有一个FLOSS工具以所选择的语言实现此条款，则至少需要将一个静态代码分析工具应用于软件发布之前任何提议的主要生成版本。 [static_analysis]
    静态代码分析工具检查软件代码（源代码，中间代码或可执行文件），而不用特定输入执行。本条款中，编译器警告和“安全”语言模式不被视为静态代码分析工具（它们通常避免深入分析，因为速度至关重要）。此类静态代码分析工具的示例包括 cppcheck ， clang静态分析器， FindBugs （包括FindSecurityBugs）， PMD ， Brakeman ， Coverity质量分析器和 HP Fortify静态代码分析器。更多的工具列表可以在诸如维基百科静态代码分析工具列表，关于静态代码分析的OWASP信息， NIST源代码安全分析器列表和 Wheeler的静态分析工具列表。 SWAMP 是使用各种工具评估软件漏洞的免费平台。如果没有可用于所使用的实现语言的FLOSS静态分析工具，请选择“N/A”。

    勉强够获得徽章。

    建议至少有一个用于static_analysis标准的静态分析工具包括在分析语言或环境中查找常见漏洞的规则或方法。 [static_analysis_common_vulnerabilities]
    专门设计用于寻找常见漏洞的静态分析工具更有可能找到它们。也就是说，使用任何静态工具通常会帮助找到一些问题，所以我们“通过”级别的徽章建议，但不要求这个条款。

    不足以获得徽章。

    使用静态代码分析发现的所有中，高严重性可利用漏洞必须在确认后及时修复。 [static_analysis_fixed]
    如果其 CVSS 2.0 评分为4或更高，则此漏洞是中等到高的严重性。

    勉强够获得徽章。

    建议每次提交或至少每天执行静态源代码分析。 [static_analysis_often]

  • 动态代码分析


    足够获得徽章！

    建议在发布之前，至少将一个动态分析工具应用于软件任何发布的主要生产版本。 [dynamic_analysis]
    动态分析工具通过执行特定输入来检查软件。例如，项目可以使用模糊工具（例如， American Fuzzy Lop ）或Web应用扫描程序（例如， ZAP 或 w3af ）。在某些情况下， OSS-Fuzz 项目可以对您的项目应用模糊测试。为满足此条款，动态分析工具需要以某种方式改变输入，以寻找各种问题，或者将其作为一个具有至少80％分支覆盖率的自动测试套件。 动态分析维基百科页面和 OWASP的fuzzing页面 识别一些动态分析工具。分析工具可能专注于寻找安全漏洞，但这不是必需的。

    Evidence that dynamic analysis tools are applied before major production releases:

    1 Multiple Sanitizers in Analysis Workflow

    • .github/workflows/analysis.yml runs dynamic analysis before releases:
    • LeakSanitizer: "detects memory leaks"
    • AddressSanitizer: "fast memory error detector" for buffer overflows, use-after-free, etc.
    • UndefinedBehaviorSanitizer: detects undefined behavior at runtime

    2 Analysis Workflow Integrated into Release Process

    From .github/workflows/daily-build.yml: * uses: ./.github/workflows/analysis.yml * This calls the analysis workflow as part of the build process

    3 Sanitizer Infrastructure Available

    From config/sanitizer/sanitizers.cmake and config/sanitizer/README.md document:

    • HDF5_USE_SANITIZER CMake variable
    • Support for Address, Memory, Undefined, Thread, Leak, and CFI sanitizers
    • All are FLOSS dynamic analysis tools from LLVM/Clang

    Reference: config/sanitizer/README.md states: "Sanitizers are tools that perform checks during a program's runtime"

    4 Coverage Analysis

    From .github/workflows/analysis.yml:

    • Code coverage testing with gcov/lcov
    • While primarily for coverage metrics, it requires executing tests (dynamic analysis)

    5 OSS-Fuzz Integration

    README.md shows OSS-Fuzz badge:

    • Continuous fuzzing (dynamic analysis for vulnerability detection)
    • Indicates ongoing dynamic analysis

    6 Sanitizers Run on Multiple Configurations

    analysis.yml shows sanitizers run with:

    • Different compilers (Clang)
    • Different configurations
    • Automated in CI/CD pipeline

    The project applies multiple FLOSS dynamic analysis tools (LeakSanitizer, AddressSanitizer, UndefinedBehaviorSanitizer, and fuzzing) before releases through automated workflows.


    足够获得徽章！

    建议如果项目生成的软件包含使用内存不安全语言编写的软件（例如C或C++），则至少有一个动态工具（例如，fuzzer或web应用扫描程序）与检测缓冲区覆盖等内存安全问题的机制例行应用。如果该项目生成的软件没有以内存不安全语言编写，请选择“不适用”（N / A）。 [dynamic_analysis_unsafe]
    检测内存安全问题的机制的示例包括AddressSanitizer（ASAN）（可在GCC和LLVM中使用），“Memory Sanitizer”和 valgrind 。其他可能使用的工具包括ThreadSanitizer和UndefinedBehaviorSanitizer。广泛的断言也将起作用。

    Evidence that dynamic tools are routinely used with memory safety detection for C/C++ code:

    1 HDF5 is Written in Memory-Unsafe Languages

    The project is primarily written in C (with C++ and Fortran wrappers):

    • CONTRIBUTING.md requires "A C11-compatible C compiler"
    • Source code in src/ is C code
    • This is a memory-unsafe language

    2 AddressSanitizer Detects Memory Safety Problems

    .github/workflows/analysis.yml runs AddressSanitizer: * CTEST_MEMORYCHECK_TYPE "AddressSanitizer" * HDF5_USE_SANITIZER:STRING=Address

    AddressSanitizer detects:

    • Buffer overflows (overwrites)
    • Use-after-free
    • Double-free
    • Out-of-bounds accesses

    Reference: config/sanitizer/README.md states AddressSanitizer "is useful for detecting most issues dealing with memory, such as: Out of bounds accesses to heap, stack, global"

    3 LeakSanitizer for Memory Leaks

    .github/workflows/analysis.yml runs LeakSanitizer:

    • CTEST_MEMORYCHECK_TYPE "LeakSanitizer"
    • HDF5_USE_SANITIZER:STRING=Leak

    4 OSS-Fuzz for Fuzzing

    README.md shows OSS-Fuzz badge:

    • Active fuzzing integration
    • Fuzzing is a dynamic tool that generates test inputs
    • Combined with sanitizers to detect memory safety issues

    5 Routine Use Through CI/CD

    The sanitizers run automatically:

    • .github/workflows/daily-build.yml calls analysis.yml
    • Runs on daily schedule
    • Integrated into continuous testing

    6 Multiple Memory Safety Mechanisms

    The project combines:

    • Fuzzing (OSS-Fuzz) - dynamic input generation
    • AddressSanitizer - detects buffer overwrites and memory errors
    • LeakSanitizer - detects memory leaks
    • UndefinedBehaviorSanitizer - detects undefined behavior

    The project routinely uses fuzzing (OSS-Fuzz) combined with AddressSanitizer to detect memory safety problems including buffer overwrites in its C/C++ code.


    足够获得徽章！

    建议由项目生成的软件包括许多运行时断言，在动态分析期间检查。 [dynamic_analysis_enable_assertions]
    这个标准并不建议使生产过程中的断言;这完全取决于项目及其用户的决定。该标准的重点是在部署之前的动态分析过程中改善故障检测。在生产使用中启用断言与在动态分析（例如测试）期间启用断言完全不同。在某些情况下，在生产中使用断言是极其不明智的（尤其是在高完整性组件中）。存在许多反对在生产环境中启用断言的论点，例如，库不应使调用程序崩溃，它们的存在可能会导致应用商店拒绝，和/或在生产环境中激活断言可能会暴露诸如私钥之类的私有数据。请注意，在许多Linux发行版中都未定义NDEBUG ，因此C / C ++缺省情况下，assert（）将在这些环境中启用生产。对于那些环境中的生产，使用不同的断言机制或定义NDEBUG可能很重要。

    The project uses configurations with assertions enabled for dynamic analysis:

    1 Developer Mode Enables Assertions

    CONTRIBUTING.md documents developer build options:

    • HDF5_ENABLE_DEVELOPER_MODE=ON enables developer-friendly settings
    • Developer mode is recommended for development builds

    2 Sanitizer Builds Use Debug Configuration

    .github/workflows/analysis.yml runs sanitizers with Debug configuration:

    • Coverage test: ctest -S HDF5config.cmake...CTEST_SOURCE_NAME=${{ steps.set-file-base.outputs.SOURCE_BASE }} -C Debug
    • LeakSanitizer runs with -C Debug
    • AddressSanitizer runs with -C Debug
    • UndefinedBehaviorSanitizer runs with -C Debug

    Debug builds typically enable assertions that are disabled in release builds.

    3 Assertion Macros in Code

    CONTRIBUTING.md shows assertion usage in function structure:

    • FUNC_ENTER_NOAPI(FAIL)

    HDassert(/parameter check/);

    The HDassert macro is used throughout the codebase for parameter checking.

    4 Memory Checker Configuration

    CONTRIBUTING.md documents memory checking option:

    • HDF5_ENABLE_USING_MEMCHECKER:BOOL=ON when using tools like Valgrind
    • This disables internal memory pools to enable better error detection

    Reference: "Use HDF5_ENABLE_USING_MEMCHECKER:BOOL=ON when using tools like Valgrind. This disables internal memory pools that can hide memory issues."

    5 Sanitizer Configuration Separate from Production

    .github/workflows/analysis.yml shows sanitizer builds are separate:

    • Different workflow from production builds
    • Uses specific build options not used in production
    • Runs in "Sanitize" group/model

    6 Coverage Build Uses Debug Settings

    .github/workflows/analysis.yml coverage test:

    • LOCAL_COVERAGE_TEST "TRUE"
    • DHDF5_ENABLE_COVERAGE:BOOL=ON
    • Coverage builds run with instrumentation not suitable for production

    The project uses Debug configuration with assertions enabled for dynamic analysis (sanitizers, fuzzing, testing), which are separate from production builds.


    足够获得徽章！

    通过动态代码分析发现的所有严重性为中，高的可利用漏洞必须在确认后及时修复。 [dynamic_analysis_fixed]
    如果 CVSS 2.0 基本分数为4，那么一个漏洞是中等到高的严重性。如果您没有运行动态代码分析，没有发现任何这样的漏洞，选择“不适用”（N/A）。

    1 Extensive CVE Fixes Documented

    CHANGELOG.md shows that numerous security vulnerabilities have been fixed:

    • CVE-2025-7067 - Heap buffer overflow in H5FS__sinfo_serialize_node_cb()
    • CVE-2025-2915 - Heap-based buffer overflow in H5F__accum_free
    • CVE-2025-7068 - Resource leaks in metadata cache
    • CVE-2025-6816, CVE-2025-6818, CVE-2025-6856, CVE-2025-2923 - Object header vulnerabilities

    And many more...

    2 OSS-Fuzz Integration for Discovery

    README.md shows OSS-Fuzz badge:

    • Continuous fuzzing (dynamic analysis) for vulnerability detection
    • OSS-Fuzz reports vulnerabilities that are then fixed

    Reference: OSS-Fuzz badge indicates active participation in continuous fuzzing program

    3 CVE Regression Testing

    README.md shows CVE regression CI badge:

    • Automated testing to ensure CVE fixes remain effective
    • Prevents reintroduction of vulnerabilities

    4 Security Advisory Process

    SECURITY.md documents vulnerability handling:

    • Private disclosure process for security vulnerabilities
    • "This gives us time to work with you to fix the issue before public exposure"
    • Shows commitment to fixing vulnerabilities before disclosure

    5 GitHub Issues Track Vulnerabilities

    CHANGELOG.md references GitHub issues for each CVE:

    • "Fixes GitHub issue #5577" (CVE-2025-7067)
    • "Fixes GitHub issue #5380" (CVE-2025-2915)
    • "Fixes GitHub issue #5578" (CVE-2025-7068)

    Shows systematic tracking and resolution

    6 Multiple Fixes in Single Release

    Version 2.0.0 includes fixes for 10+ CVEs, demonstrating:

    • Active vulnerability remediation
    • Timely response to discovered issues
    • Comprehensive fixes are released together

    7 Sanitizer Findings Are Addressed

    The project runs sanitizers routinely:

    • AddressSanitizer, LeakSanitizer, UndefinedBehaviorSanitizer
    • Findings from these tools are used to fix memory safety issues
    • Many CVE fixes mention sanitizer-detectable issues (buffer overflows, use-after-free, memory leaks)

    The project demonstrates timely fixing of exploitable vulnerabilities discovered through dynamic analysis (fuzzing, sanitizers), with extensive CVE fixes documented in CHANGELOG.md and systematic tracking through GitHub issues.



This data is available under the Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). This means that a Data Recipient may share the Data, with or without modifications, so long as the Data Recipient makes available the text of this agreement with the shared Data. Please credit Scot Breitenfeld and the OpenSSF Best Practices badge contributors.

项目徽章条目拥有者： Scot Breitenfeld.
最后更新于 2023-09-05 17:54:26 UTC, 最后更新于 2025-12-03 17:51:05 UTC。