Open adonayb-ami opened 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.
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.
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.
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.