gheber
Should [HDFGroup/cve_hdf5](https://github.com/HDFGroup/cve_hdf5) continue on its own or be incorporated into H5Lens?
#88 · open · 1 comments
Should [HDFGroup/cve_hdf5](https://github.com/HDFGroup/cve_hdf5) continue on its own or be incorporated into H5Lens?
# Pros and cons of retaining the separate repository ## Keeping cve_hdf5 separate has real advantages: - It remains a general `libhdf5`/tool regression archive usable by projects other than `h5policy`. - Upstream contributors do not need to understand this repository’s finding registry, profiles, or promotion workflow. - Historical advisory and fix-release maintenance does not churn the policy implementation. - Its permissive license can remain clearly attributed; vendoring should retain its `cve_hdf5/COPYING:1`. ## The disadvantages are mostly synchronization problems: - A new specimen, its metadata, its execution command, and a new validator rule cannot land atomically. - Independent lists drift—as the current inventory demonstrates. - A sibling checkout or CI download cannot satisfy “exercise on every test” reliably. - Historical advisory claims may be mistaken for current evidence. In this repository, the old files remain valuable attack-surface specimens, but current conclusions must be re-measured against the newest `libhdf5`. ## Preliminary conclusion The vendored-consumer model retains the advantages while controlling the drift through revision and digest pins.