Help shape the future of HDF5 safety, security, and privacy.
Two August events will focus on making HDF5 more transparent, inspectable, and secure:
FOSSY 2026 — Aug 6, Vancouver:A GNU poke-based, machine-readable file-format specification for HDF5
HDF5 SHINES / Safe-OSE Workshop — Aug 12 afternoon, SDSC / UC San Diego + Zoom: HDF5 safety, security, privacy, supply-chain risk, audit findings, mitigation priorities, and community next steps. Registration required!
This is for HDF5 users, developers, administrators, packagers, integrators, security researchers, data managers, digital librarians, and anyone who depends on HDF5.
Please join us by replying below with your HDF5 SSP concerns or use cases, and tell us what the community should prioritize.
For sensitive vulnerability details, please do not post exploit information publicly. Use the HDF5 vulnerability reporting channel instead: https://ssp.hdfgroup.org/
We would like this thread to collect practical input before the SHINES / Safe-OSE workshop.
Useful replies include:
Use cases: Where do HDF5 files come from in your workflow? Who writes them? Who reads them? Are they trusted, semi-trusted, or untrusted?
Operational concerns: Do you use HDF5 on shared HPC systems, cloud systems, institutional archives, instruments, embedded systems, or regulated environments?
Plugins and extensions: Do you rely on filters, VOL connectors, VFDs, external links, virtual datasets, or dynamically loaded plugins?
Safety issues: What HDF5 failure modes matter most to you: corrupted files, unexpected crashes, unreadable archives, silent data changes, compatibility breaks, or wrong results?
Security issues: What concerns you most: malformed files, untrusted input, plugin loading, dependency risk, vulnerable old versions, package provenance, or CVE communication?
Privacy issues: What metadata, attributes, paths, names, logs, or provenance information should not leak when HDF5 files are shared?
Mitigation priorities: What stricter defaults would help? What would break if HDF5 became more conservative about untrusted files, external references, or plugins?
Please keep public replies high-level. Do not post exploit details, private data, sensitive files, credentials, or unpublished vulnerability information in this thread.
This talk focuses on using GNU poke to describe HDF5 on-disk structures as executable, machine-readable specifications. The goal is to make HDF5 internals easier to inspect, test, validate, document, and reason about.
HDF5 SHINES / Safe-OSE Workshop at SSDBM 2026
When: Wednesday, August 12, 2026, afternoon Where: San Diego Supercomputer Center, UC San Diego Participation: In person or remote via Zoom Link:Safe-OSE Workshop - SSDBM 2026
The workshop will bring together HDF5 developers, users, administrators, integrators, security practitioners, data managers, and researchers to discuss HDF5 safety, security, privacy, software supply-chain risk, audit findings, mitigation priorities, and practical next steps for the HDF5 ecosystem.
Security researchers:
“Help define the threat model for HDF5: malformed files, metadata trust boundaries, plugin loading, supply-chain risk, and file-format-aware validation.”
Administrators / HPC centers:
“What should your site do when users bring arbitrary HDF5 files, filters, VOL connectors, VFDs, and long-lived data into shared infrastructure?”
Developers / maintainers:
“Machine-readable HDF5 specifications, GNU poke pickles, validation tools, conformance testing, fuzzing targets, and safer extension mechanisms.”
Users / scientists:
“What do safety, security, and privacy mean when your experiment, simulation, model, or archive is stored in HDF5?”
Digital librarians / archivists:
“HDF5 as long-lived scientific data: preservation, metadata exposure, trust, validation, repair, and evidence that a file means what it claims to mean.”
Help shape the future of HDF5 safety, security, and privacy.