hughsie / uefi-sbom-best-practices

UEFI SBOM Best Practices
Creative Commons Attribution 4.0 International
1 stars 0 forks source link

Components that are not Portable Executables (PE) Section #15

Open adonayb-ami opened 7 months ago

adonayb-ami commented 7 months ago

Do we want a "Best Practice" document to get to this level of detail referencing the "header version" and "compression algorithms" the reader MUST use? Also, if the recommendation is to use a specific tool, we may have to consider moving or forking the repo to a UEFI project space...

Example: "0x01: zlib | 0x02: lzma" - details are likely required to ensure interoperability at this level. Although zlib and lzma are well-established compression algorithms, various software embodiments may produce incompatible binaries (i.e. tool chain X may be incapable of decompressing a binary compressed with tool chain Y). For example, edk2 LZMA library prepends buffer returned by LZMA SDK with an edk2-specific header.

hughsie commented 7 months ago

uswid isnt uefi specific, it's being used for peripheral firmware and non-uefi firmware too

Choosing two compression formats was pragmatic, decoding each in python is "free" and each are required at encode time by different frameworks. i.e. require both in the thing with the smarts, but allow producing in either (or none!) in the constrained environment.

MatchPoint commented 7 months ago

I like the idea of forking any tools into a UEFI repo. Tighter control over modifications and less chance of backwards compatibility issues being introduced or undetected regressions that may impact UEFI vendors.

hughsie commented 7 months ago

Tighter control over modifications and less chance of backwards compatibility issues

Couldn't we use a git tag?

Or, for validation we do keep track of when a specific check was added, e.g.

Validation problems:
acbd84ff-9898-4922-8ade-dd4bbe2e40ba         entity: No entity marked as TagCreator (uSWID >= v0.4.7)

...so we could have something like a --validate --le 0.4.7 to ensure that we don't issue validation failures for 0.4.8 and newer.