feat: add a hasher for spdx#476
Conversation
Add a hasher similar to profile.Hash for spdx, this allows us to invalidate caches when we have an errata. The current change to use hasher now has the effect that all existing ones are invalidated, since we dropped the `spdx-` prefix to align with how hashes are used for profiles too. So no errata are being added now. Signed-off-by: Noel Georgi <git@frezbo.dev>
| // | ||
| // Operators are expected to use distinct cache repositories for OSS vs | ||
| // Enterprise deployments since the bundle content differs by build flavor. | ||
| func Hash(schematicID, version, arch string) string { |
There was a problem hiding this comment.
I would like us to move way forward on this one, and do proper caching for SBOMs.
If we just depend on schematic IDs, two schematics with e.g. just a different kernel args will not produce same SBOM ID.
Let's reconsider this, probably @shanduur can help here.
It feels like we only need list of extensions from the schematic (plus overlay?), but let's do a proper tested hashing here to avoid recomputing the SPDX.
Same applies to scan results - if a scan is requested, if the SPDX hash is same, don't re-run the scan unless vulndb/VEX changed.
There was a problem hiding this comment.
If we just depend on schematic IDs, two schematics with e.g. just a different kernel args will not produce same SBOM ID.
Ahhh that's bad already, we should rely on extensions only, overlays don't ship sboms, unless we want them to
There was a problem hiding this comment.
Yeah, schematicID is too fragile, we should cache on Version+Arch+Extensions.
|
We can close this, right? |
yes |
Add a hasher similar to profile.Hash for spdx, this allows us to invalidate caches when we have an errata.
The current change to use hasher now has the effect that all existing ones are invalidated, since we dropped the
spdx-prefix to align with how hashes are used for profiles too. So no errata are being added now.