quantumclaw/clawhdf5
3
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity

docs: conformance numbers after the review fixes (598 of 697 ok)

Browse Source 
cve-2025-44905 now reads as h5py reads it (the v1 chunk B-tree lookup),
leaving 5 our-errors: cve-2025-2308, cve-2025-44904 and
bad_nbit_parms_walk (corrupt data HDF5 2.0 reads through a bug), and
the Blosc2 and ZFP filters. The five unloadable-cache-image files stay
ok, now with the library behaving as the probe reports.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
This commit is contained in:
osobh
2026-09-26 11:53:46 -05:00
co-authored by Claude Opus 5.5
parent 00f94d57ed
commit 55e0e7e9cf
1 changed files with 6 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
CHANGELOG.md
+6 -3
View File
@@ -3,10 +3,13 @@
## Unreleased ## Unreleased
### Remaining conformance errors (2026-09-26) ### Remaining conformance errors (2026-09-26)
Conformance on tank, `conformance/run.sh --no-fetch`: 597 of 697 files Conformance on tank, `conformance/run.sh --no-fetch`: 598 of 697 files
ok (575 before). Of the 6 our-errors left, 4 are corrupt data HDF5 2.0 ok (575 before). Of the 5 our-errors left, 3 are corrupt data HDF5 2.0
reads only through a bug (listed in `CONFORMANCE.md`), 2 are the Blosc2 and reads only through a bug (listed in `CONFORMANCE.md`), 2 are the Blosc2 and
ZFP filters; the 2 mismatches are the known h5py big-endian VL bug. ZFP filters; the 2 mismatches are the known h5py big-endian VL bug. The
five files whose cache image libhdf5 cannot load (`cve-2025-6269-*`,
`cve-2025-6516`) count as ok because the library, like libhdf5, opens them
and fails their objects (see below).
- **Metadata cache images are read.** A file written with a metadata cache - **Metadata cache images are read.** A file written with a metadata cache
image keeps its metadata cache entries in an image block the superblock image keeps its metadata cache entries in an image block the superblock
extension points at, and libhdf5 reads them in place of the file's own extension points at, and libhdf5 reads them in place of the file's own