HDF5 Library and File Format

Miradi inayofuata mazoea bora hapa chini inaweza kujihakikisha kwa hiari na kuonyesha kuwa wamepata nishani ya mazoea bora ya Open Source Security Foundation (OpenSSF).

Hakuna seti ya mazoea yawezayo kuhakikisha kuwa programu haitakuwa na kasoro au udhaifu; hata mbinu rasmi zinaweza kushindwa ikiwa vipimo au dhana ni sahihi. Wala hakuna seti ya mazoea yawezayo kuhakikisha kuwa mradi utaendelea kuwa na jamii ya maendeleo yenye afya na inayofanya kazi vizuri. Hata hivyo, kufuata mazoea bora kunaweza kusaidia kuboresha matokeo ya miradi. Kwa mfano, baadhi ya mazoea huwezesha ukaguzi wa watu wengi kabla ya kutolewa, ambayo inaweza kusaidia kupata udhaifu wa kiufundi ambao vinginevyo ni vigumu kupata na kusaidia kujenga uaminifu na hamu ya mwingiliano wa kurudia kati ya wasanidi programu kutoka makampuni tofauti. Ili kupata nishani, vigezo vyote vya LAZIMA na LAZIMA WALA USIWAHI lazima vifuatwe, vigezo vyote vya INAPASWA lazima vifuatwe AU visivyo fufufutiliana na thibitisho, na vigezo vyote vya PENDEKEZA lazima vifuatwe AU visivyo fufufutiliana (tunataka vifikiwe angalau). Ikiwa unataka kuingiza maandishi ya thibitisho kama maoni ya jumla, badala ya kuwa maelezo ya busara kwamba hali ni inakubaliwa, anza kifungu cha maandishi na '//' ikifuatiwa na nafasi. Maoni ni karibu kupitia tovuti ya GitHub kama masuala au maombi ya kuvuta Kuna pia orodha ya barua pepe kwa majadiliano ya jumla.

Tunafuraha kutoa habari katika lugha nyingi, hata hivyo, ikiwa kuna mgongano au kutokuwa na usawa kati ya tafsiri, toleo la Kiingereza ni toleo lenye mamlaka.
Ikiwa huu ni mradi wako, tafadhali onyesha hadhi ya nishani yako kwenye ukurasa wa mradi wako! Hadhi ya nishani inaonekana kama hii: Kiwango cha nishani kwa mradi 7802 ni in_progress Hapa ni jinsi ya kuiweka:
Unaweza kuonyesha hali ya nishani yako kwa kuweka hii katika faili yako ya markdown:
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/7802/badge)](https://www.bestpractices.dev/projects/7802)
au kwa kuweka hii katika HTML yako:
<a href="https://www.bestpractices.dev/projects/7802"><img src="https://www.bestpractices.dev/projects/7802/badge"></a>


Hizi ni vigezo vya kiwango cha Kupita. Unaweza pia kuangalia vigezo vya kiwango cha Fedha au Dhahabu.

Baseline Series: Kiwango cha Msingi 1 Kiwango cha Msingi 2 Kiwango cha Msingi 3

        

 Misingi 13/13 ●

  • Jumla

    Kumbuka kwamba miradi mingine inaweza kutumia jina sawa.

    Official HDF5® Library Repository

    Tafadhali tumia muundo wa maneno ya leseni ya SPDX; mifano ni pamoja na "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "GPL-2.0+", "LGPL-3.0+", "MIT", na "(BSD-2-Clause OR Ruby)". Usitumie alama za nukuu za moja au mbili.
    Ikiwa kuna lugha zaidi ya moja, ziorodhe kama thamani zilizotengwa kwa koma (nafasi ni za hiari) na ziorodhe kuanzia iliyotumiwa zaidi hadi iliyotumiwa kidogo. Ikiwa kuna orodha ndefu, tafadhali orodhesha angalau tatu za kawaida zaidi. Ikiwa hakuna lugha (k.m., huu ni mradi wa nyaraka tu au wa majaribio tu), tumia herufi moja "-". Tafadhali tumia herufi kubwa za kawaida kwa kila lugha, k.m., "JavaScript".
    Common Platform Enumeration (CPE) ni mpango wa kuweka majina yenye muundo kwa mifumo ya teknolojia ya habari, programu, na vifurushi. Inatumika katika mifumo na hifadhidata nyingi wakati wa kuripoti udhaifu.

  • Maudhui ya kimsingi ya tovuti ya mradi


    Ya kutosha kwa nishani!

    Tovuti ya mradi LAZIMA ieleze kwa ufupi programu inafanya nini (inasuluhu tatizo gani?). [description_good]
    Hii LAZIMA iwe katika lugha ambayo watumiaji watarajiwa wanaweza kuelewa (k.m., inatumia lugha ya kiufundi kidogo).

    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:


    Ya kutosha kwa nishani!

    Tovuti ya mradi LAZIMA itoe habari juu ya jinsi ya: kupata, kutoa maoni (kama ripoti za hitilafu au maboresho), na kuchangia kwenye programu. [interact]

    1 How to Obtain the Software

    The README includes multiple sources for obtaining HDF5:

    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.


    Ya kutosha kwa nishani!

    Habari juu ya jinsi ya kuchangia LAZIMA ieleze mchakato wa uchangiaji (kwa mfano, je! Maombi ya kuvuta yanatumika?) (URL inahitajika) [contribution]
    Tunafikiria kuwa miradi kwenye GitHub hutumia maswala na kuvuta maombi isipokuwa palipoonyeshwa vingine. Habari hii inaweza kuwa fupi, kwa mfano, ikisema kuwa mradi hutumia maombi ya kuvuta, msako wa suala, au machapisho kwenye orodha ya barua (ipi?)

    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.


    Ya kutosha kwa nishani!

    Habari juu ya jinsi ya kuchangia INAPASWA kujumuisha mahitaji ya michango inayokubalika (k.m., rejeleo la kiwango chochote kinachohitajika cha usimbaji). (URL inahitajika) [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

  • Leseni ya FLOSS


    Ya kutosha kwa nishani!

    Programu iliyozalishwa na mradi LAZIMA itolewa kama FLOSS. [floss_license]
    FLOSS ni programu iliyotolewa kwa njia inayokidhi Ufafanuzi wa Chanzo Wazi au Ufafanuzi wa Programu Huria. Mifano ya leseni kama hizo ni pamoja na CC0, MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0, Lesser GNU General Public License (LGPL), na GNU General Public License (GPL). Kwa madhumuni yetu, hii inamaanisha kuwa leseni LAZIMA iwe: Programu YAWEZA pia kupatiwa leseni kwa njia nyingine (k.m., "GPLv2 au ya kibinafsi" inakubaliwa).

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


    Ya kutosha kwa nishani!

    INAPENDEKEZA kwamba leseni yoyote inayohitajika kwa programu iliyozalishwa na mradi iwe imeidhinishwa na Open Source Initiative (OSI). [floss_license_osi]
    OSI inatumia mchakato mgumu wa uidhinishaji kuamua ni leseni zipi ni OSS.

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


    Ya kutosha kwa nishani!

    Mradi LAZIMA uweke leseni za matokeo yake mahali pa kawaida katika hazina yake ya chanzo. (URL inahitajika) [license_location]
    Desturi moja ni kuweka leseni kama faili ya ngazi ya juu inayoitwa LICENSE au COPYING, ambayo YAWEZA kufuatiwa na kiendelezi kama ".txt" au ".md". Desturi mbadala ni kuwa na saraka inayoitwa LICENSES inayohifadhi faili za leseni; faili hizi kwa kawaida zinaitwa kama kitambulisho chao cha leseni ya SPDX kikifuatiwa na kiendelezi kinachofaa, kama ilivyoelezwa katika Maelezo ya REUSE. Kumbuka kwamba kigezo hiki ni mahitaji tu kwenye hazina ya chanzo. Huhitaji kuingiza faili ya leseni wakati wa kuzalisha kitu kutoka kwenye msimbo wa chanzo (kama programu inayotekelezeka, kifurushi, au chombo). Kwa mfano, wakati wa kuzalisha kifurushi cha R kwa Mtandao wa Kumbukumbu Kamili wa R (CRAN), fuata mazoea ya kawaida ya CRAN: ikiwa leseni ni leseni ya kawaida, tumia maelezo mafupi ya kawaida ya leseni (ili kuepuka kusakinisha nakala nyingine ya maandishi) na orodhesha faili ya LICENSE katika faili ya kutengwa kama .Rbuildignore. Vivyo hivyo, wakati wa kuunda kifurushi cha Debian, unaweza kuweka kiungo katika faili ya hakimiliki kwa maandishi ya leseni katika /usr/share/common-licenses, na utenge faili ya leseni kutoka kwenye kifurushi kilichoundwa (k.m., kwa kufuta faili baada ya kuita dh_auto_install). Tunashauri jumuisha maelezo ya leseni yanayoweza kusomwa na mashine katika miundo iliyozalishwa mahali inapofaa.

    The project posts its license in the standard location:


  • Nyaraka


    Ya kutosha kwa nishani!

    Mradi LAZIMA utoe nyaraka za msingi za programu iliyozalishwa na mradi. [documentation_basics]
    Nyaraka hizi lazima ziwe katika vyombo fulani (kama maandishi au video) vinavyojumuisha: jinsi ya kuisakinisha, jinsi ya kuianzisha, jinsi ya kuitumia (huenda ikijumuisha mafunzo kwa kutumia mifano), na jinsi ya kuitumia kwa usalama (k.m., nini cha kufanya na nini cha kutofanya) ikiwa hiyo ni mada inayofaa kwa programu. Nyaraka za usalama lazima zisiwe ndefu. Mradi YAWEZA kutumia viungo vya hypertext kwa nyenzo zisizo za mradi kama nyaraka. Ikiwa mradi hauzalishi programu, chagua "haihusiki" (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).


    Ya kutosha kwa nishani!

    Mradi LAZIMA utoe nyaraka za marejeleo zinazofafanua kiolesura cha nje (ingizo na matokeo) cha programu iliyozalishwa na mradi. [documentation_interface]
    Nyaraka za kiolesura cha nje zinaeleza kwa mtumiaji wa mwisho au msanidi jinsi ya kuitumia. Hii itajumuisha kiolesura chake cha programu ya programu (API) ikiwa programu ina. Ikiwa ni maktaba, andika madarasa/aina kuu na mbinu/vitendakazi vinavyoweza kuitwa. Ikiwa ni programu ya wavuti, fafanua kiolesura chake cha URL (mara nyingi kiolesura chake cha REST). Ikiwa ni kiolesura cha mstari wa amri, andika vigezo na chaguo zinazosaidia. Katika hali nyingi ni bora ikiwa nyingi ya nyaraka hizi zinazalishwa kiotomatiki, ili nyaraka hizi zibaki zikisawazishwa na programu inavyobadilika, lakini hii haihitajiki. Mradi YAWEZA kutumia viungo vya hypertext kwa nyenzo zisizo za mradi kama nyaraka. Nyaraka ZIWEZA kuzalishwa kiotomatiki (ambapo ni vitendo hii mara nyingi ndiyo njia bora ya kufanya hivyo). Nyaraka za kiolesura cha REST zinaweza kuzalishwa kwa kutumia Swagger/OpenAPI. Nyaraka za kiolesura cha msimbo ZINAWEZA kuzalishwa kwa kutumia zana kama vile JSDoc (JavaScript), ESDoc (JavaScript), pydoc (Python), devtools (R), pkgdown (R), na Doxygen (nyingi). Kuwa na maoni tu katika msimbo wa utekelezaji haitoshi kutosheleza kigezo hiki; kunahitaji kuwa na njia rahisi ya kuona habari bila kusoma kupitia msimbo wote wa chanzo. Ikiwa mradi hauzalishi programu, chagua "haihusiki" (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.


  • Mengine


    Ya kutosha kwa nishani!

    Tovuti za mradi (tovuti, hifadhi, na URL za kupakua) LAZIMA zisaidie HTTPS kwa kutumia TLS. [sites_https]
    Hii inahitaji kwamba URL ya ukurasa wa nyumbani wa mradi na URL ya hifadhi ya udhibiti wa toleo vianze na "https:", si "http:". Unaweza kupata vyeti vya bure kutoka Let's Encrypt. Miradi YAWEZA kutekeleza kigezo hiki kwa kutumia (kwa mfano) GitHub pages, GitLab pages, au SourceForge project pages. Ikiwa unasaidia HTTP, tunakuhimiza uelekeze trafiki ya HTTP kwenda 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.


    Ya kutosha kwa nishani!

    Mradi LAZIMA uwe na taratibu moja au zaidi za majadiliano (ikiwa ni pamoja na mabadiliko yaliyopendekezwa na masuala) yenye utafutaji, inaruhusu ujumbe na mada kuelekezwa kwa URL, inaruhusu watu wapya kushiriki katika baadhi ya majadiliano, na haihitaji usakinishaji wa upande wa mteja wa programu ya kibinafsi. [discussion]
    Mifano ya taratibu zinazokubalika ni pamoja na orodha za barua pepe zilizohifadhiwa, majadiliano ya suala la GitHub na ombi la kuvuta, Bugzilla, Mantis, na Trac. Taratibu za majadiliano yasiyo ya wakati mmoja (kama IRC) zinakubaliwa ikiwa zinakidhi vigezo hivi; hakikisha kuna utaratibu wa kuhifadhi unaoelekezwa kwa URL. JavaScript ya kibinafsi, ingawa haikubalika, inaruhusiwa.

    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.


    Ya kutosha kwa nishani!

    Mradi UNAPASWA kutoa nyaraka kwa Kiingereza na uweze kukubali ripoti za hitilafu na maoni kuhusu msimbo kwa Kiingereza. [english]
    Kiingereza kwa sasa ni lingua franca ya teknolojia ya kompyuta; kusaidia Kiingereza huongeza idadi ya wasanidi na wakaguzi tofauti wa uwezekano duniani kote. Mradi unaweza kukidhi kigezo hiki hata ikiwa lugha ya msingi ya wasanidi wake wakuu si Kiingereza.

    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.


    Ya kutosha kwa nishani!

    Mradi LAZIMA utunzwe. [maintained]
    Kama kiwango cha chini, mradi unapaswa kujaribu kujibu ripoti za tatizo muhimu na udhaifu. Mradi unaofuata kwa bidii nishani pengine unatengenezwa. Miradi yote na watu wana rasilimali zilizowekewa mipaka, na miradi ya kawaida lazima ikatae baadhi ya mabadiliko yaliyopendekezwa, hivyo rasilimali zilizowekewa mipaka na kukataa mapendekezo sio ishara ya mradi usiotekelezwa.

    Mradi unapojua kwamba hautatengenezwa tena, unapaswa kuweka kigezo hiki kama "Haikidhi" na utumie utaratibu sahihi ili kuwaonyesha wengine kwamba hautengenezwi. Kwa mfano, tumia "DEPRECATED" kama kichwa cha kwanza cha README yake, ongeza "DEPRECATED" karibu na mwanzo wa ukurasa wake wa nyumbani, ongeza "DEPRECATED" mwanzoni mwa maelezo ya mradi wa hifadhi ya msimbo, ongeza nishani isiyolindwa katika README yake na/au ukurasa wa nyumbani, iweke kama iliyolemewa katika hifadhi yoyote ya kifurushi (k.m., npm deprecate), na/au utumie mfumo wa alama wa hifadhi ya msimbo ili kuihifadhi (k.m., mpangilio wa "archive" wa GitHub, alama ya "archived" ya GitLab, hali ya "readonly" ya Gerrit, au hali ya mradi wa "abandoned" wa SourceForge). Majadiliano ya ziada yanaweza kupatikana hapa.

    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.


 Udhibiti wa Mabadiliko 9/9 ●

  • Hifadhi ya chanzo ya kudhibiti toleo ya hadharani


    Ya kutosha kwa nishani!

    Mradi LAZIMA uwe na hifadhi ya chanzo ya kudhibiti toleo ambayo inaweza kusomwa hadharani na ina URL. [repo_public]
    URL YAWEZA kuwa sawa na URL ya mradi. Mradi YAWEZA kutumia matawi ya faragha (yasiyo ya umma) katika hali maalum wakati mabadiliko hayajatolewa hadharani (k.m., kwa kurekebisha udhaifu kabla haujafichuliwa kwa umma).

    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.


    Ya kutosha kwa nishani!

    Hifadhi ya chanzo ya mradi LAZIMA ifuatilie mabadiliko yaliyofanywa, nani alifanya mabadiliko, na mabadiliko yalifanywa lini. [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.


    Ya kutosha kwa nishani!

    Ili kuwezesha ukaguzi wa ushirikiano, hifadhi ya chanzo ya mradi LAZIMA ijumuishe matoleo ya kati kwa ukaguzi kati ya matoleo; HAIPASWA kujumuisha matoleo ya mwisho tu. [repo_interim]
    Miradi YAWEZA kuchagua kuondoa matoleo maalum ya kati kutoka hifadhi zao za chanzo za umma (k.m., zile zinazorekebi udhaifu maalum usiokuwa wa umma, huenda zisitolewe hadharani, au zijumuishe nyenzo ambazo haziwezi kuwekwa kisheria na haziko katika toleo la mwisho).

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


    Ya kutosha kwa nishani!

    INASHAURIWA kwamba programu ya kawaida ya udhibiti wa toleo iliyosambazwa itumike (k.m., git) kwa hifadhi ya chanzo ya mradi. [repo_distributed]
    Git haihitajiki kihususa na miradi inaweza kutumia programu ya udhibiti wa toleo iliyokusanyika (kama subversion) na sababu.

    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.


  • Unambari wa toleo wa kipekee


    Ya kutosha kwa nishani!

    Matokeo ya mradi LAZIMA yawe na kitambulisho cha kipekee cha toleo kwa kila toleo linalokusudiwa kutumiwa na watumiaji. [version_unique]
    Hii YAWEZA kukidhi kwa njia mbalimbali ikiwa ni pamoja na vitambulisho vya kuwasilisha (kama kitambulisho cha kuwasilisha cha git au kitambulisho cha seti ya mabadiliko cha mercurial) au nambari ya toleo (ikiwa ni pamoja na nambari za toleo zinazotumia uainishaji wa maana au mipango ya tarehe kama 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.


    Ya kutosha kwa nishani!

    INASHAURIWA kwamba muundo wa nambari ya toleo ya Semantic Versioning (SemVer) au Calendar Versioning (CalVer) itumike kwa matoleo. INASHAURIWA kwamba wale wanaotumia CalVer wajumuishe thamani ya kiwango cha mdogo. [version_semver]
    Miradi kwa ujumla inapaswa kupendelea muundo wowote unaotarajiwa na watumiaji wao, k.m., kwa sababu ni muundo wa kawaida unaotumiwa na ikolojia yao. Ikolojia nyingi zinapendelea SemVer, na SemVer kwa ujumla hupendelewa kwa kiolesura cha programu ya programu (API) na zana za maendeleo ya programu (SDK). CalVer hutumiwa na miradi ambayo ni kubwa, ina idadi kubwa ya utegemezi ulioundwa kwa uhuru, ina upeo wa mara kwa mara unaobadilika, au ni ya muda muhimu. INASHAURIWA kwamba wale wanaotumia CalVer wajumuishe thamani ya kiwango cha mdogo, kwa sababu kujumuisha kiwango cha mdogo kunasaidia matawi yaliyotunzwa kwa wakati mmoja wakati wowote hilo linakuwa lazima. Miundo mingine ya nambari ya toleo inaweza kutumiwa kama nambari za toleo, ikiwa ni pamoja na vitambulisho vya kuwasilisha cha git au vitambulisho vya seti ya mabadiliko cha mercurial, mradi tu vikitambulisha matoleo kwa kipekee. Hata hivyo, baadhi ya mbadala (kama vitambulisho vya kuwasilisha cha git) vinaweza kusababisha matatizo kama vitambulisho vya toleo, kwa sababu watumiaji huenda wasiwe na uwezo wa kuamua kwa urahisi ikiwa wako na toleo la hivi karibuni. Muundo wa kitambulisho cha toleo unaweza kutokuwa wa maana kwa kutambulisha matoleo ya programu ikiwa wapokeaji wote wanaendesha toleo la hivi karibuni tu (k.m., ni msimbo wa tovuti moja au huduma ya mtandao ambayo inasasishwa mara kwa mara kupitia utoaji wa kuendelea).

    Ya kutosha kwa nishani!

    INASHAURIWA kwamba miradi itambulishe kila toleo ndani ya mfumo wao wa udhibiti wa toleo. Kwa mfano, INASHAURIWA kwamba wale wanaotumia git watambulishe kila toleo kwa kutumia lebo za 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.


  • Maelezo ya kutolewa


    Ya kutosha kwa nishani!

    Mradi LAZIMA utoe, katika kila toleo, maelezo ya toleo ambayo ni muhtasari unaosomeka na binadamu wa mabadiliko makuu katika toleo hilo ili kuwasaidia watumiaji kuamua ikiwa wanapaswa kusasisha na athari ya kusasisha itakuwa nini. Maelezo ya toleo LAZIMA yasiwe matokeo ghafi ya kumbukumbu ya udhibiti wa toleo (k.m., matokeo ya amri ya "git log" si maelezo ya toleo). Miradi ambayo matokeo yake hayakusudiwa kutumika tena katika maeneo mengi (kama programu kwa tovuti moja au huduma) NA wanaotumia utoaji wa kuendelea WAWEZA kuchagua "N/A". (URL inahitajika) [release_notes]
    Maelezo ya toleo YAWEZA kutekelezwa kwa njia mbalimbali. Miradi mingi hutoa katika faili inayoitwa "NEWS", "CHANGELOG", au "ChangeLog", kwa hiari na viendelezi kama ".txt", ".md", au ".html". Kihistoria neno "change log" lilimaanisha kumbukumbu ya kila mabadiliko, lakini ili kukidhi vigezo hivi kinachohitajika ni muhtasari unaosomeka na binadamu. Maelezo ya toleo YAWEZA badala yake kutolewa na taratibu za mfumo wa udhibiti wa toleo kama mtiririko wa Matoleo ya 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.


    Ya kutosha kwa nishani!

    Maelezo ya toleo LAZIMA yatambulishe kila udhaifu wa muda wa kutekeleza uliojulikana hadharani uliorekebishwa katika toleo hili ambao tayari ulikuwa na mgawanyo wa CVE au sawa wakati toleo lilipobuniwa. Kigezo hiki kinaweza kuwekwa alama kama haihusiki (N/A) ikiwa watumiaji kwa kawaida hawawezi kwa vitendo kusasisha programu wao wenyewe (k.m., kama inavyokuwa kweli mara nyingi kwa masasisho ya kernel). Kigezo hiki kinatumika tu kwa matokeo ya mradi, si kwa utegemezi wake. Ikiwa hakuna maelezo ya toleo au hakujawa na udhaifu uliojulikana hadharani, chagua N/A. [release_notes_vulns]
    Kigezo hiki kinawasaidia watumiaji kuamua ikiwa sasisho fulani litarekebisha udhaifu ambao unajulikana hadharani, ili kuwasaidia watumiaji kufanya uamuzi wa habari kuhusu kusasisha. Ikiwa watumiaji kwa kawaida hawawezi kwa vitendo kusasisha programu wao wenyewe kwenye kompyuta zao, lakini badala yake lazima wategemee wapatanishi mmoja au zaidi kutekeleza sasisho (kama inavyokuwa mara nyingi kwa kernel na programu ya kiwango cha chini ambayo imefungwa na kernel), mradi unaweza kuchagua "haihusiki" (N/A) badala yake, kwani habari hii ya ziada haitakuwa ya msaada kwa watumiaji hao. Vivyo hivyo, mradi unaweza kuchagua N/A ikiwa wapokeaji wote wanaendesha toleo la hivi karibuni tu (k.m., ni msimbo wa tovuti moja au huduma ya mtandao ambayo inasasishwa mara kwa mara kupitia utoaji wa kuendelea). Kigezo hiki kinatumika tu kwa matokeo ya mradi, si kwa utegemezi wake. Kuorodhesha udhaifu wa utegemezi wote wa mpito wa mradi unakuwa mgumu kadiri utegemezi unavyoongezeka na kutofautiana, na haihitajiki kwani zana zinazochunguza na kufuatilia utegemezi zinaweza kufanya hivi kwa njia inayopanuka.

    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.


 Kuripoti 7/8 ●

  • Mchakato wa kuripoti hitilafu


    Ya kutosha kwa nishani!

    Mradi LAZIMA utoe mchakato kwa watumiaji kuwasilisha ripoti za hitilafu (k.m., kwa kutumia kifuatiliaji cha masuala au orodha ya barua pepe). (URL inahitajika) [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.


    Ya kutosha kwa nishani!

    Mradi UNAPASWA kutumia kifuatiliaji cha masuala kwa kufuatilia masuala ya mtu binafsi. [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.


    Ya kutosha kwa nishani!

    Mradi LAZIMA uthibitishe wengi wa ripoti za hitilafu zilizowasilishwa katika miezi 2-12 iliyopita (ikiwemo); jibu halihitaji kuwa na marekebisho. [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.


    Ya kutosha kwa nishani!

    Mradi UNAPASWA kujibu wengi (>50%) wa maombi ya maboresho katika miezi 2-12 iliyopita (ikiwemo). [enhancement_responses]
    Jibu LIWEZA kuwa 'hapana' au majadiliano kuhusu manufaa yake. Lengo ni kwamba kuwe na jibu fulani kwa baadhi ya maombi, ambayo inaonyesha kwamba mradi bado unaishi. Kwa madhumuni ya kigezo hiki, miradi haihitaji kuhesabu maombi ya bandia (k.m., kutoka kwa wafanyabiashara haramu au mifumo ya kiotomatiki). Ikiwa mradi hauendelei kufanya maboresho tena, tafadhali chagua "haijatimizwa" na jumuisha URL inayofanya hali hii kuwa wazi kwa watumiaji. Ikiwa mradi huwa na msongo wa maombi ya maboresho, tafadhali chagua "haijatimizwa" na eleza.

    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.


    Ya kutosha kwa nishani!

    Mradi LAZIMA uwe na kumbukumbu inayopatikana hadharani kwa ripoti na majibu kwa utaftaji wa baadaye. (URL inahitajika) [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.


  • Mchakato wa kuripoti udhaifu


    Ya kutosha kwa nishani!

    Mradi LAZIMA uchapishe mchakato wa kuripoti udhaifu kwenye tovuti ya mradi. (URL inahitajika) [vulnerability_report_process]
    Miradi iliyohifadhiwa kwenye GitHub INAPASWA kuzingatia kuwezesha kuripoti udhaifu wa usalama kwa faragha. Miradi kwenye GitLab INAPASWA kuzingatia kutumia uwezo wake wa kuripoti udhaifu kwa faragha. Miradi YAWEZA kutambulisha anwani ya barua pepe kwenye https://PROJECTSITE/security, mara nyingi katika muundo wa security@example.org. Mchakato huu wa kuripoti udhaifu UWEZA kuwa sawa na mchakato wake wa kuripoti hitilafu. Ripoti za udhaifu ZIWEZA kuwa za umma kila wakati, lakini miradi mingi ina utaratibu wa kuripoti udhaifu wa faragha.

    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.


    Ya kutosha kwa nishani!

    Ikiwa ripoti za udhaifu wa faragha zinasaidiwa, mradi LAZIMA ujumuishe jinsi ya kutuma habari kwa njia ambayo inawekwa faragha. (URL inahitajika) [vulnerability_report_private]
    Mifano ni pamoja na ripoti ya kasoro ya faragha iliyowasilishwa kwenye wavuti kwa kutumia HTTPS (TLS) au barua pepe iliyosimbwa kwa kutumia OpenPGP. Ikiwa ripoti za udhaifu ni za umma kila wakati (kwa hiyo hakuna ripoti za udhaifu za faragha), chagua "haihusiki" (N/A).

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

    1 Private Reporting Method Specified
    SECURITY.md states:

    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.


    Si ya kutosha kwa nishani.

    Muda wa majibu ya awali ya mradi kwa ripoti yoyote ya udhaifu iliyopokelewa katika miezi 6 iliyopita LAZIMA uwe chini ya au sawa na siku 14. [vulnerability_report_response]
    Ikiwa hakujawa na udhaifu ulioripotiwa katika miezi 6 iliyopita, chagua "haihusiki" (N/A).

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


 Ubora 13/13 ●

  • Mfumo wa ujenzi unaofanya kazi


    Ya kutosha kwa nishani!

    Ikiwa programu iliyotengenezwa na mradi inahitaji ujenzi wa matumizi, mradi LAZIMA utoe mfumo wa kujenga ambao unaweza kujenga programu kiotomatiki kutoka kwa chanzo-msimbo. [build]
    Mfumo wa kujenga huamua ni hatua gani zinahitaji kutendeka ili kujenga tena programu (na kwa mpangilio gani), na kisha kutekeleza hatua hizo. Kwa mfano, inaweza kuomba kikusanyaji kukusanya fumbo-chanzo. Ikiwa inayoweza kutekelezwa imeundwa kutoka kwa fumbo-chanzo, lazima iwezeshe marekebisho kwenye fumbo-chanzo ya mradi na kisha itengeneze msasisho inayoweza kutekelezwa na marekebisho hayo. Ikiwa programu iliyotolewa na mradi unategemea maktaba ya nje, mfumo wa kujenga haina haja ya kujenga maktaba hizo za nje. Ikiwa hakuna haja ya kujenga chochote kutumia programu baada ya fumbo-chanzo kubadilishwa, chagua "haitumiki" (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.


    Ya kutosha kwa nishani!

    INAPENDEKEZWA kuwa zana za kawaida zitumike kujenga programu. [build_common_tools]
    Kwa mfano, Maven, Ant, cmake, autotools, make, rake (Ruby), au 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.


    Ya kutosha kwa nishani!

    Mradi UNAPASWA kujengwa kwa kutumia zana za FLOSS pekee yake. [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.


  • Seti ya majaribio otomatiki


    Ya kutosha kwa nishani!

    Mradi LAZIMA utumie angalau seti moja ya majaribio ya kiotomatiki ambayo imetolewa hadharani kama FLOSS (seti hii ya majaribio inaweza kutunzwa kama mradi tofauti wa FLOSS). Mradi LAZIMA uonyeshe wazi au uandike jinsi ya kuendesha seti za majaribio (k.m., kupitia hati ya uingizaji wa kuendelea (CI) au kupitia nyaraka katika faili kama BUILD.md, README.md, au CONTRIBUTING.md). [test]
    Mradi YAWEZA kutumia seti nyingi za majaribio ya kiotomatiki (k.m., moja inayoendesha haraka, dhidi ya nyingine ambayo ni ya kina zaidi lakini inahitaji vifaa maalum). Kuna mifumo mingi ya majaribio na mifumo ya kusaidia majaribio inayopatikana, ikiwemo Selenium (uendeshaji kiotomatiki wa kivinjari cha wavuti), Junit (JVM, Java), RUnit (R), testthat (R).

    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.


    Ya kutosha kwa nishani!

    Seti ya majaribio INAPASWA kuwa inaweza kuitwa kwa njia ya kawaida kwa lugha hiyo. [test_invocation]
    Kwa mfano, "make check", "mvn test", au "rake test" (Ruby).

    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.


    Ya kutosha kwa nishani!

    INAPENDEKEZWA kwamba seti ya majaribio ifuate wengi (au kwa kawaida wote) matawi ya msimbo, sehemu za kuingiza, na utendakazi. [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.


    Ya kutosha kwa nishani!

    INAPENDEKEZWA kwamba mradi utekeleze ujumuishaji wendeleo (ambapo msimbo mpya au uliobadiishwa unajumuishwa mara kwa mara katika hifadhi ya msimbo ya kati na majaribio otomatiki hufanyika kwenye matokeo). [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.


  • Upimaji wa utendaji mpya


    Ya kutosha kwa nishani!

    Mradi LAZIMA uwe na sera ya jumla (rasmi au la) kwamba utendakazi mkubwa mpya unavyoongezwa kwenye programu inayotengenezwa na mradi, majaribio ya utendakazi huo unapaswa kuongezwa kwenye seti ya majaribio otomatiki. [test_policy]
    Mradi uwe na sera tu, hata kwa maneno ya mdomo, inayosema wasanidi programu wanapaswa kuongeza majaribio kwenye seti ya majaribio otomatiki kwa utendakazi mkubwa mpya, chagua "Kukidhi."

    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.


    Ya kutosha kwa nishani!

    Mradi LAZIMA uwe na ushahidi kwamba test_policy ya kuongeza majaribio imefuatwa katika mabadiliko makubwa ya hivi karibuni kwenye programu inayotengenezwa na mradi. [tests_are_added]
    Utendakazi mkubwa kawaida ungetajwa katika maelezo ya toleo. Ukamilifu hauhitajiki, ni ushahidi tu kwamba majaribio kawaida huongezwa kimakosa kwenye seti ya majaribio otomatiki utendakazi mkubwa mpya unavyoongezwa kwenye programu inayotengenezwa na mradi.

    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.


    Ya kutosha kwa nishani!

    INAPENDEKEZWA kwamba sera hii ya kuongeza majaribio (angalia test_policy) iwe imeandikwa katika maelekezo ya mapendekezo ya mabadiliko. [tests_documented_added]
    Hata hivyo, hata sheria isiyo rasmi inakubaliwa mradi majaribio yaongezwe kimakosa.

    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.


  • Bendera za maonyo


    Ya kutosha kwa nishani!

    Mradi LAZIMA uwashe bendera moja au zaidi za onyo la mkusanyaji, hali ya lugha "salama", au tumia zana tofauti ya "linter" kutafuta makosa ya ubora wa msimbo au makosa rahisi ya kawaida, ikiwa kuna angalau zana moja ya FLOSS inaweza kutekeleza kigezo hiki katika lugha iliyochaguliwa. [warnings]
    Mifano ya bendera za onyo la mkusanyaji ni pamoja na gcc/clang "-Wall". Mifano ya hali ya lugha "salama" ni pamoja na JavaScript "use strict" na perl5's "use warnings". Zana tofauti ya "linter" ni zana tu inayoangalia msimbo wa chanzo kutafuta makosa ya ubora wa msimbo au makosa rahisi ya kawaida. Hizi kawaida huwashwa ndani ya msimbo wa chanzo au maelekezo ya ujenzi.

    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.


    Ya kutosha kwa nishani!

    Mradi LAZIMA ukabiliane na maonyo. [warnings_fixed]
    Haya ni maonyo yaliyotambuliwa na utekelezaji wa kigezo cha warnings. Mradi unapaswa kurekebisha maonyo au kuyaweka alama katika msimbo wa chanzo kama hasi za uwongo. Kwa kawaida pasingeweza kuwa na maonyo, lakini mradi YAWEZA kukubali baadhi ya maonyo (kawaida chini ya onyo 1 kwa mistari 100 au chini ya maonyo 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.


    Ya kutosha kwa nishani!

    INAPENDEKEZWA kwamba miradi iwe na ukali mkubwa sana na maonyo katika programu inayotengenezwa na mradi, ambapo ni ya vitendo. [warnings_strict]
    Baadhi ya maonyo hayawezi kuwashwa kwa ufanisi kwenye miradi fulani. Kinachohitajika ni ushahidi kwamba mradi unajitahidi kuwasha bendera za onyo ambapo inaweza, ili makosa yagundulika mapema.

    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.


 Usalama 14/16 ●

  • Maarifa ya maendeleo yenye usalama


    Ya kutosha kwa nishani!

    Mradi LAZIMA uwe na angalau msanidi mmoja mkuu anayejua jinsi ya kuunda programu salama. (Angalia 'maelezo' kwa mahitaji halisi.) [know_secure_design]
    Hii inahitaji kuelewa kanuni zifuatazo za muundo, ikiwa ni pamoja na kanuni 8 kutoka Saltzer na Schroeder:
    • uchumi wa utaratibu (weka muundo kuwa rahisi na mdogo iwezekanavyo, k.m., kwa kupitisha urahisishaji wa kufunga)
    • mipangilio ya kuzuia makosa (maamuzi ya kuingia yanapaswa kukataa kwa chaguo-msingi, na usakinishaji wa miradi unapaswa kuwa salama kwa chaguo-msingi)
    • kikuu cha kati kikamilifu (kuingia kote kunaweza kuwekwa kikomo lazima kufanyiwa ukaguzi wa mamlaka na kutowezesha kuvukwa)
    • muundo wazi (taratibu za usalama hazipaswi kutegemea ujinga wa mshambuliaji wa muundo wake, lakini badala yake kwenye habari iliyolindwa na kubadilishwa kwa urahisi kama funguo na nywila)
    • kutenganisha kwa upendeleo (kwa kawaida, ufikiaji kwa vitu muhimu unapaswa kutegemea zaidi ya sharti moja, ili kushinda mfumo mmoja wa ulinzi hautawasha ufikiaji kamili. K.m., uthibitishaji wa vipengele vingi, kama vile kuhitaji nywila na ishara za vifaa, ni imara zaidi kuliko uthibitishaji wa kipengele kimoja)
    • upendeleo mdogo zaidi (michakato inapaswa kufanya kazi na upendeleo mdogo zaidi unaohitajika)
    • utaratibu wa kawaida mdogo zaidi (muundo unapaswa kupunguza utaratibu wa kawaida kwa zaidi ya mtumiaji mmoja na kutegemewa na watumiaji wote, k.m., saraka za mafaili ya muda)
    • kukubalika kwa kisaikolojia (kiolesura cha binadamu lazima kiwe kimeundwa kwa urahisi wa matumizi - kuunda kwa "mshangao mdogo" kunaweza kusaidia)
    • uso wa shambulio uliowekewa mipaka (uso wa shambulio - seti ya sehemu tofauti ambapo mshambuliaji anaweza kujaribu kuingia au kutoa data - unapaswa kuwekwa mipaka)
    • uthibitishaji wa ingizo na orodha zinazokubalika (pembejeo kawaida zinapaswa kuangaliwa ili kuamua kama ni halali kabla ya kukubalika; uthibitishaji huu unapaswa kutumia orodha zinazokubalika (zinazokubali tu thamani zinazojulikana-nzuri), siyo orodha zinazokana (zinaozojaribu kuorodhesha thamani zinazojulikana-mbaya)).
    "Msanidi mkuu" katika mradi ni mtu yeyote ambaye anajua msingi wa msimbo wa mradi, ana faraja kufanya mabadiliko kwake, na anatambuliwa hivyo na washiriki wengine wengi katika mradi. Msanidi mkuu kawaida atafanya michango mingi kwa mwaka uliopita (kupitia msimbo, nyaraka, au kujibu maswali). Wasanidi kawaida wangeweza kuchukuliwa wasanidi wakuu ikiwa walianzisha mradi (na hawajatoka kwenye mradi zaidi ya miaka mitatu iliyopita), wana chaguo la kupokea habari kwenye kituo cha kuripoti udhaifu wa kibinafsi (ikiwa kuna), wanaweza kukubali ahadi kwa niaba ya mradi, au kufanya matoleo ya mwisho ya programu ya mradi. Ikiwa kuna msanidi mmoja tu, mtu huyo ndiye msanidi mkuu. Vitabu vingi na kozi zinapatikana kukusaidia kuelewa jinsi ya kuunda programu salama zaidi na kujadili muundo. Kwa mfano, kozi ya Misingi ya Maendeleo ya Programu Salama ni seti huru ya kozi tatu zinazoeleza jinsi ya kuunda programu salama zaidi (ni bure ukiifanyia ukaguzi; kwa ada ya ziada unaweza kupata cheti kuthibitisha ulijifunza nyenzo).

    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.


    Ya kutosha kwa nishani!

    Angalau mmoja wa wasanidi wakuu wa mradi LAZIMA wajue aina za kawaida za makosa ambayo husababisha udhaifu katika aina hii ya programu, pamoja na angalau mbinu moja ya kukabiliana au kupunguza kila moja. [know_common_errors]
    Mifano (kulingana na aina ya programu) ni pamoja na uvamizi wa SQL, uvamizi wa OS, mtiririko wa kipengele cha kawaida, uandishi wa tovuti-tofauti, uthibitishaji unaokosekana, na uidhinishaji unaokosekana. Angalia CWE/SANS top 25 au OWASP Top 10 kwa orodha zinazotumika kawaida. Vitabu vingi na kozi zinapatikana kukusaidia kuelewa jinsi ya kuunda programu salama zaidi na kujadili makosa ya kawaida ya utekelezaji ambayo husababisha udhaifu. Kwa mfano, kozi ya Misingi ya Maendeleo ya Programu Salama ni seti huru ya kozi tatu zinazoeleza jinsi ya kuunda programu salama zaidi (ni bure ukiifanyia ukaguzi; kwa ada ya ziada unaweza kupata cheti kuthibitisha ulijifunza nyenzo).

    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.


  • Tumia mazoea mazuri ya msingi ya usimbuaji

    Kumbuka kwamba programu fulani haihitaji kutumia taratibu za usimbuaji. Ikiwa mradi wako unazalisha programu ambayo (1) inajumuisha, inaamilisha, au inafanya usimbuaji kuwa hai, na (2) inaweza kutolewa kutoka Marekani (US) kwenda nje ya Marekani au kwa raia asiye wa Marekani, inaweza kuwa ni lazima kisheria kuchukua hatua chache za ziada. Kawaida hii inahusisha tu kutuma barua pepe. Kwa maelezo zaidi, tazama sehemu ya usimbuaji ya Kuelewa Teknolojia ya Chanzo Wazi & Udhibiti wa Usafirishaji wa Marekani.

    Ya kutosha kwa nishani!

    Programu iliyotengenezwa na mradi LAZIMA itumie, kwa chaguo-msingi, tu itifaki za kriptografia na mifumbo ambazo zimechapishwa hadharani na kukaguliwa na wataalam (ikiwa itifaki za kriptografia na mafumbo imetumika). [crypto_published]
    Vigezo hivi vya kriptografia mara mingi havitumiki kwa sababu programu zingine hazina haja ya kutumia moja kwa moja uwezo wa kriptografia.

    Ya kutosha kwa nishani!

    Ikiwa programu iliyotengenezwa na mradi ni programu au maktaba, na kusudi lake la msingi sio kutekeleza usimbuaji, basi INAPASWA tu kuita programu iliyoundwa kihususa kutekeleza kazi za kielelezo; HAIPASWI kutekeleza-upya shughuli hiyo. [crypto_call]

    Ya kutosha kwa nishani!

    Utendaji wote katika programu iliyotengenezwa na mradi ambayo inategemea usimbuaji LAZIMA iweze kutekelezwa kwa kutumia FLOSS. [crypto_floss]
    Tazama Mahitaji ya Viwango wazi ya Programu kupitia Open Source Initiative.

    Ya kutosha kwa nishani!

    Mifumo ya usalama ndani ya programu inayozalishwa na mradi LAZIMA itumie kwa msingi keylengths ambazo angalau zinakidhi mahitaji ya chini ya NIST kufikia mwaka wa 2030 (kama ilivyoelezwa mnamo 2012). LAZIMA iwe rahisi kusanidi programu ili keylengths ndogo zimezimwa kabisa. [crypto_keylength]
    Vipimo hivi vya urefu wa charaza ni: symmetric key 112, factoring modulus 2048, discrete logarithm key 224, discrete logarithmic group 2048, elliptic curve 224, na hash 224 (ufichuzi wa nywila haujashughulikiwa kwenye urefu wa charaza hii, maelezo zaidi ya ufichuzi wa nywila yanapatikana ndani ya kigezo cha crypto_password_storage). Ona https://www.keylength.com kwa mliganisho wa mapendekezo ya funguo-refu kutoka mashirika mbali mbali. Programu YAWEZA kubali funguo-refu ndogo katika usanidi (haifai kukubali, maana hii huwacha mashambulizi ya kushusha, lakini funguo-refu fupi wakati mwingine ina manufaa ya upatanifu).

    Ya kutosha kwa nishani!

    Mifumo ya usalama ya chaguo-msingi ndani ya programu inayozalishwa na mradi LAZIMA ISITEGEMEE algoriti zilizovunjika za kriptologia (k.m., MD4, MD5, DES moja, RC4, Dual_EC_DRBG), au kutumia hali za cipher ambazo si sahihi kwa muktadha, isipokuwa ni muhimu kutekeleza itifaki inayoweza kushirikiana (ambapo itifaki iliyotekelezwa ni toleo la hivi karibuni zaidi la kiwango hicho kinachotegemeana sana na mfumo wa mtandao, mfumo huo unahitaji matumizi ya algoriti au hali hiyo, na mfumo huo haupatii chaguo lolote salama zaidi). Nyaraka LAZIMA zieleze hatari zozote za usalama husika na upungufu wowote unaojulikana ikiwa algoriti hizi zilizovunjika au hali ni muhimu kwa itifaki inayoweza kushirikiana. [crypto_working]
    Hali ya ECB ni karibu kamwe haifai kwa sababu inaonyesha block zinazofanana ndani ya ciphertext kama ilivyoonyeshwa na penguin wa ECB, na hali ya CTR mara nyingi si sahihi kwa sababu haifanyi uthibitishaji na husababisha nakala ikiwa hali ya ingizo inarudiwa. Katika hali nyingi ni bora kuchagua hali ya algoriti ya block cipher iliyoundwa kuchanganya siri na uthibitishaji, k.m., Galois/Counter Mode (GCM) na EAX. Miradi YAWEZA kuwaruhusu watumiaji kuwasha taratibu zilizovunjika (k.m., wakati wa usanidi) ambapo ni muhimu kwa upatanifu, lakini hapo watumiaji wanajua wanafanya hivyo.

    Ya kutosha kwa nishani!

    Mifumo ya usalama ya chaguo-msingi ndani ya programu inayozalishwa na mradi INAPASWA ISITEGEMEE algoriti za kriptologia au hali zenye udhaifu mkubwa unaojulikana (k.m., algoriti ya hash ya kriptologia ya SHA-1 au hali ya CBC katika SSH). [crypto_weaknesses]
    Wasiwasi kuhusu hali ya CBC katika SSH unajadiliwa katika CERT: SSH CBC vulnerability.

    Ya kutosha kwa nishani!

    Mifumo ya usalama ndani ya programu iliyotengenezwa na mradi INAPASWA kutekeleza kwa ukamilifu usiri wa umbele ya itifaki za makubaliano ya funguo ili funguo la kipindi kilicho tokana na kikao cha vifungo muda-mrefu haziwezi kuridhi mabaya ikiwa mojawapo ya vifunguo vya muda-mrefu imeridhi mabaya katika usoni. [crypto_pfs]

    Ya kutosha kwa nishani!

    Ikiwa programu iliyotengenezwa na mradi imesababisha uhifadhi wa nywila kwa minajili ya uthibitishaji ya watumiaji wa kutoka nje, nywila LAZIMA zihifadhiwe kwa mficho uliorudiarudia na chumvi kwa kila-mtumiaji kwa kutumia kanuni ya upanuaji (rudiarudia) wa funguo (k.m., Argon2id, Bcrypt, Scrypt, or PBKDF2). Ona pia Kurasadogo ya Uhifadhi wa Nywila la OWASP). [crypto_password_storage]
    Kigezo hili linatumika tu wakati programu linatekeleza uthibitishaji wa watumiaji kutumia nywila kwa watumiaji wa nje (ambayo pia ni uthibitishaji unaelekezwa ndani), kama vile programu za tovuti zinazobakia seva). Haitumiki katika visa ambavyo programu inahifadhi nywila ili kudhibitisha ndani ya mifumo mingine (ambayo pia ni ithibitishaji unaelekezwa nje, k.m., programu inatekeleza teja la mfumo lingineyo), maana angalau sehemu za programu lazima ziwe na njia ya kupata hiyo nywila isigalifichwa.

    Ya kutosha kwa nishani!

    Mifumo ya usalama ndani ya programu iliyotengenezwa na mradi LAZIMA itoe funguo zote za kriptologia na nonces kwa kutumia kitengeneza cha nambari za bahati kuptia kriptologia salama, na ISIWEZE kufanya hivo kutumia vitengenezi zisizo salama kikriptologia. [crypto_random]
    Kitengeneza cha nambari za bahati nasibu za kriptologia salama kinaweza kuwa kitengeneza cha nambari za bahati nasibu za vifaa, au kinaweza kuwa kitengeneza cha nambari za bahati nasibu za kriptologia salama (CSPRNG) kwa kutumia algoriti kama vile Hash_DRBG, HMAC_DRBG, CTR_DRBG, Yarrow, au Fortuna. Mifano ya simu kwa vitengeneza cha nambari za bahati nasibu salama ni pamoja na java.security.SecureRandom ya Java na window.crypto.getRandomValues ya JavaScript. Mifano ya simu kwa vitengeneza cha nambari za bahati nasibu zisizo salama ni pamoja na java.util.Random ya Java na Math.random ya JavaScript.

  • Utoaji salama dhidi ya mashambulizi ya mtu-katikati (MITM)


    Ya kutosha kwa nishani!

    Mradi LAZIMA utumie utaratibu wa utoaji ambao unakabiliana na mashambulizi ya MITM. Kutumia https au ssh+scp ni inakubaliwa. [delivery_mitm]
    Utaratibu wenye nguvu zaidi ni kutoa programu na vifurushi vilivyosainiwa kidigitali, kwa kuwa hiyo inapunguza mashambulizi kwenye mfumo wa usambazaji, lakini hii inafanya kazi tu ikiwa watumiaji wanaweza kuwa na uhakika kwamba funguo za umma kwa saini ni sahihi na ikiwa watumiaji watakagua saini kweli kweli.

    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.


    Ya kutosha kwa nishani!

    Hash ya kriptologia (k.m., sha1sum) LAZIMA ISICHUKULIWE kupitia http na kutumika bila kuangalia saini ya kriptologia. [delivery_unsigned]
    Hash hizi zinaweza kurekebishwa wakati wa usafiri.

    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.


  • Udhaifu uliofahamika hadharani umeshughulikiwa


    Si ya kutosha kwa nishani.

    LAZIMA kuwe hakuna udhaifu usiorekebishwa wa kiwango cha kati au juu zaidi ambao umejulikana hadharani kwa zaidi ya siku 60. [vulnerabilities_fixed_60_days]
    Udhaifu lazima urekebishwe na kutolewa na mradi wenyewe (rekebisho zinaweza kutengenezwa mahali pengine). Udhaifu unakuwa unajulikana hadharani (kwa kusudi hili) mara tu unapata CVE yenye taarifa zilizotolewa hadharani zisizolipwa (zilizoripotiwa, kwa mfano, katika Hifadhidata ya Taifa ya Udhaifu) au wakati mradi umefahamishwa na taarifa imetolewa kwa umma (labda na mradi). Udhaifu unazingatiwa kuwa wa kiwango cha kati au juu ikiwa alama yake ya Common Vulnerability Scoring System (CVSS) ya msingi ya ubora ni kati au juu. Katika matoleo ya CVSS 2.0 hadi 3.1, hii ni sawa na alama ya CVSS ya 4.0 au zaidi. Miradi inaweza kutumia alama ya CVSS kama ilivyochapishwa katika hifadhidata ya udhaifu inayotumika sana (kama vile Hifadhidata ya Taifa ya Udhaifu) kwa kutumia toleo la hivi karibuni la CVSS lililoripotiwa katika hifadhidata hiyo. Miradi badala yake inaweza kuhesabu ukali wao wenyewe kwa kutumia toleo la hivi karibuni la CVSS wakati wa ufunuzi wa udhaifu, ikiwa ingizo la hesabu linatangazwa hadharani mara tu udhaifu unajulikana hadharani. Kumbuka: hii inamaanisha kwamba watumiaji wanaweza kuachwa katika hatari kwa washambuliaji wote duniani kwa siku hadi 60. Kigezo hiki ni rahisi zaidi kukidhi kuliko yale Google inapendekeza katika Rebooting responsible disclosure, kwa sababu Google inapendekeza kwamba kipindi cha siku 60 kianze wakati mradi unafahamishwa hata ikiwa ripoti si ya umma. Pia kumbuka kwamba kigezo hiki cha nishani, kama vigezo vingine, kinatumika kwa mradi wa mtu binafsi. Baadhi ya miradi ni sehemu ya mashirika makubwa ya mwavuli au miradi mikubwa, labda katika safu nyingi, na miradi mingi inatoa matokeo yao kwa mashirika mengine na miradi kama sehemu ya mnyororo wa usambazaji wenye utata. Mradi wa mtu binafsi mara nyingi hauwezi kudhibiti wengine, lakini mradi wa mtu binafsi unaweza kufanya kazi kutoa rekebisho ya udhaifu kwa wakati. Kwa hiyo, tunazingatia tu muda wa jibu wa mradi wa mtu binafsi. Mara tu rekebisho inapatikana kutoka kwa mradi wa mtu binafsi, wengine wanaweza kuamua jinsi ya kushughulikia rekebisho (k.m., wanaweza kusasisha kwenye toleo jipya au wanaweza kutumia rekebisho tu kama suluhisho lililochaguliwa-cherry).

    Taarifa inayohitajika haijulikani, si ya kutosha kwa nishani.

    Miradi INAPASWA kurekebisha udhaifu wote muhimu haraka baada ya kuripotiwa. [vulnerabilities_critical_fixed]

  • Masuala mengine ya usalama


    Ya kutosha kwa nishani!

    Hazina za umma LAZIMA ZISIVUJE uthibitisho halali wa faragha (k.m., nywila inayofanya kazi au funguo ya faragha) ambayo imekusudiwa kupunguza upatikanaji wa umma. [no_leaked_credentials]
    Mradi UNAWEZA kuvuja uthibitisho wa "sampuli" kwa majaribio na hifadhidata zisizo muhimu, mradi tu hazikusudiwa kupunguza upatikanaji wa umma.

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


 Uchanganuzi 6/8 ●

  • Uchambuzi tuli wa msimbo


    Si ya kutosha kwa nishani.

    Angalau zana moja ya uchambuzi wa msimbo tuli (zaidi ya maonyo ya mkusanyaji na hali za lugha "salama") LAZIMA itumike kwa toleo lolote lililopendekezwa kubwa la uzalishaji wa programu kabla ya toleo lake, ikiwa kuna angalau zana moja ya FLOSS inayotekeleza kigezo hiki katika lugha iliyochaguliwa. [static_analysis]
    Zana ya uchambuzi wa msimbo tuli inachunguza msimbo wa programu (kama msimbo wa chanzo, msimbo wa kati, au utekelezaji) bila kuutekeleza na ingizo maalum. Kwa madhumuni ya kigezo hiki, maonyo ya mkusanyaji na hali za lugha "salama" hazihesabiwi kama zana za uchambuzi wa msimbo tuli (hizi kwa kawaida huepuka uchambuzi wa kina kwa sababu kasi ni muhimu). Baadhi ya zana za uchambuzi wa msimbo tuli zinazingatia kugundua hitilafu za jumla, nyingine zinazingatia kupata aina fulani za hitilafu (kama vile udhaifu), na baadhi hufanya mchanganyiko. Mifano ya zana hizo za uchambuzi wa msimbo tuli ni pamoja na cppcheck (C, C++), clang static analyzer (C, C++), SpotBugs (Java), FindBugs (Java) (ikiwa ni pamoja na FindSecurityBugs), PMD (Java), Brakeman (Ruby on Rails), lintr (R), goodpractice (R), Coverity Quality Analyzer, SonarQube, Codacy, na HP Enterprise Fortify Static Code Analyzer. Orodha kubwa za zana zinaweza kupatikana katika maeneo kama vile orodha ya Wikipedia ya zana za uchambuzi wa msimbo tuli, taarifa za OWASP kuhusu uchambuzi wa msimbo tuli, orodha ya NIST ya vichambua usalama wa msimbo wa chanzo, na orodha ya Wheeler ya zana za uchambuzi tuli. Ikiwa hakuna zana za uchambuzi tuli za FLOSS zinazopatikana kwa lugha za utekelezaji zilizotumika, unaweza kuchagua 'N/A'.

    Kwa shida ya kutosha kwa nishani.

    INAPENDEKEZWA kwamba angalau moja ya zana za uchambuzi tuli zilizotumika kwa kigezo cha static_analysis ijumuishe sheria au njia za kutafuta udhaifu wa kawaida katika lugha au mazingira yaliyochambuliwa. [static_analysis_common_vulnerabilities]
    Zana za uchambuzi tuli ambazo zimeundwa hasa kutafuta udhaifu wa kawaida zina uwezekano mkubwa wa kuzipata. Hata hivyo, kutumia zana zozote za tuli kwa kawaida itasaidia kupata baadhi ya matatizo, kwa hivyo tunashauri lakini hatunahitaji hii kwa kiwango cha nishani ya 'kupita'.

    Si ya kutosha kwa nishani.

    Udhaifu wote wenye ukali wa kati na juu zaidi unaoweza kudhoofishwa uliogundulika kupitia uchambuzi wa msimbo tuli LAZIMA urekebishwe kwa wakati baada ya kuthibitishwa. [static_analysis_fixed]
    Udhaifu unazingatiwa kuwa wa kiwango cha kati au juu zaidi ikiwa alama yake ya Common Vulnerability Scoring System (CVSS) ya msingi ya ubora ni kati au juu. Katika matoleo ya CVSS 2.0 hadi 3.1, hii ni sawa na alama ya CVSS ya 4.0 au zaidi. Miradi inaweza kutumia alama ya CVSS kama ilivyochapishwa katika hifadhidata ya udhaifu inayotumika sana (kama vile Hifadhidata ya Taifa ya Udhaifu) kwa kutumia toleo la hivi karibuni la CVSS lililoripotiwa katika hifadhidata hiyo. Miradi badala yake inaweza kuhesabu ukali wao wenyewe kwa kutumia toleo la hivi karibuni la CVSS wakati wa ufunuzi wa udhaifu, ikiwa ingizo la hesabu linatangazwa hadharani mara tu udhaifu unajulikana hadharani. Kumbuka kwamba kigezo cha vulnerabilities_fixed_60_days kinahitaji kwamba udhaifu wote kama huo urekebishwe ndani ya siku 60 baada ya kuwa wa umma.

    Kwa shida ya kutosha kwa nishani.

    INAPENDEKEZWA kwamba uchambuzi wa msimbo wa chanzo tuli ufanyike kwenye kila ahadi au angalau kila siku. [static_analysis_often]

  • Uchambuzi wa msimbo wa nguvu za ziada


    Ya kutosha kwa nishani!

    INAPENDEKEZWA kwamba angalau zana moja ya uchambuzi wa nguvu itumike kwenye toleo kubwa lolote la uzalishaji lililopendekezwa la programu kabla ya kutolewa kwake. [dynamic_analysis]
    Zana ya uchambuzi wa nguvu inachunguza programu kwa kuitekeleza na ingizo maalum. Kwa mfano, mradi YAWEZA kutumia zana ya fuzzing (k.m., American Fuzzy Lop) au kitafutaji cha programu ya wavuti (k.m., OWASP ZAP au w3af). Katika hali fulani mradi wa OSS-Fuzz unaweza kuwa tayari kutumia majaribio ya fuzz kwenye mradi wako. Kwa madhumuni ya kigezo hiki zana ya uchambuzi wa nguvu inahitaji kubadilisha ingizo kwa njia fulani kutafuta aina mbalimbali za matatizo au kuwa seti kiotomatiki ya majaribio yenye angalau asilimia 80 ya ukaguzi wa tawi. Ukurasa wa Wikipedia kuhusu uchambuzi wa nguvu na ukurasa wa OWASP kuhusu fuzzing hutambulisha baadhi ya zana za uchambuzi wa nguvu. Zana za uchambuzi ZINAWEZA kuzingatia kutafuta udhaifu wa usalama, lakini hii haihitajiki.

    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.


    Ya kutosha kwa nishani!

    INAPENDEKEZWA kwamba ikiwa programu iliyozalishwa na mradi inajumuisha programu iliyoandikwa kwa kutumia lugha isiyosalama ya kumbukumbu (k.m., C au C++), basi angalau zana moja ya nguvu (k.m., fuzzer au kitafutaji cha programu ya wavuti) itumike kwa kawaida kwa pamoja na utaratibu wa kugundua matatizo ya usalama wa kumbukumbu kama vile uandikaji zaidi wa kipengele. Ikiwa mradi hauzalishi programu iliyoandikwa katika lugha isiyosalama ya kumbukumbu, chagua "haihusiki" (N/A). [dynamic_analysis_unsafe]
    Mifano ya taratibu za kugundua matatizo ya usalama wa kumbukumbu ni pamoja na Address Sanitizer (ASAN) (inapatikana katika GCC na LLVM), Memory Sanitizer, na valgrind. Zana nyingine zinazoweza kutumika ni pamoja na thread sanitizer na undefined behavior sanitizer. Madai ya kila mahali pia yaweza kufanya kazi.

    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.


    Ya kutosha kwa nishani!

    INAPENDEKEZWA kwamba mradi utumie usanidi wa angalau baadhi ya uchambuzi wa nguvu (kama vile majaribio au fuzzing) ambao huwezesha madai mengi. Katika hali nyingi madai haya yasipaswi kuwa yamewezeshwa katika mijengo ya uzalishaji. [dynamic_analysis_enable_assertions]
    Kigezo hiki hakipendekezi kuwezesha madai wakati wa uzalishaji; hilo ni kabisa kwa mradi na watumiaji wake kuamua. Lengo la kigezo hiki ni badala yake kuboresha ugunduzaji wa hitilafu wakati wa uchambuzi wa nguvu kabla ya kusambazwa. Kuwezesha madai katika matumizi ya uzalishaji ni tofauti kabisa na kuwezesha madai wakati wa uchambuzi wa nguvu (kama vile majaribio). Katika hali fulani kuwezesha madai katika matumizi ya uzalishaji ni busara sana (hasa katika vipengele vya uadilifu wa juu). Kuna hoja nyingi dhidi ya kuwezesha madai katika uzalishaji, k.m., maktaba hazipaswi kuvuruga waita, uwepo wao unaweza kusababisha kukataliwa na maduka ya programu, na/au kuamilisha madai katika uzalishaji kunaweza kufunua data za faragha kama vile funguo za faragha. Kumbuka kwamba katika usambazaji mwingi wa Linux NDEBUG haijafafanuliwa, hivyo C/C++ assert() kwa chaguo-msingi itawezeshwa kwa uzalishaji katika mazingira hayo. Inaweza kuwa muhimu kutumia utaratibu tofauti wa madai au kufafanua NDEBUG kwa uzalishaji katika mazingira hayo.

    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.


    Ya kutosha kwa nishani!

    Udhaifu wote wenye ukali wa kati na juu zaidi unaoweza kudhoofishwa uliogundulika kupitia uchambuzi wa msimbo wa nguvu LAZIMA urekebishwe kwa wakati baada ya kuthibitishwa. [dynamic_analysis_fixed]
    Ikiwa haujafanya uchambuzi wa msimbo wa nguvu na kwa hivyo hukupata udhaifu wowote kwa njia hii, chagua "haihusiki" (N/A). Udhaifu unazingatiwa kuwa wa kiwango cha kati au juu zaidi ikiwa alama yake ya Common Vulnerability Scoring System (CVSS) ya msingi ya ubora ni kati au juu. Katika matoleo ya CVSS 2.0 hadi 3.1, hii ni sawa na alama ya CVSS ya 4.0 au zaidi. Miradi inaweza kutumia alama ya CVSS kama ilivyochapishwa katika hifadhidata ya udhaifu inayotumika sana (kama vile Hifadhidata ya Taifa ya Udhaifu) kwa kutumia toleo la hivi karibuni la CVSS lililoripotiwa katika hifadhidata hiyo. Miradi badala yake inaweza kuhesabu ukali wao wenyewe kwa kutumia toleo la hivi karibuni la CVSS wakati wa ufunuzi wa udhaifu, ikiwa ingizo la hesabu linatangazwa hadharani mara tu udhaifu unajulikana hadharani.

    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.



Data hii inapatikana chini ya Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). Hii inamaanisha kuwa Mpokeaji wa Data anaweza kushiriki Data, na au bila marekebisho, mradi Mpokeaji wa Data anapatanisha maandishi ya mkataba huu na Data iliyoshirikiwa. Tafadhali tambua Scot Breitenfeld na wachangiaji wa nishani ya Mazoea Bora ya OpenSSF.

Ingizo la nishani ya mradi linamilikiwa na: Scot Breitenfeld.
Ingizo liliundwa siku 2023-09-05 17:54:26 UTC, iliyosasishwa mara ya mwisho siku 2025-12-03 17:51:05 UTC.