Update osCPE field example to use cpe 2.3 format, as is in active use by
AmazonLinux 2023 for example.
Add appCPE field example to document the upstream application CPE for the
applicable CVEs. Often distribution source package names are different from the
upstream CPE. For example adding/removing "lib" prefix, or adding version
stream "-3" suffix. This typically leads to guessing or fuzzy matching. Adding
appCPE in such cases can help to disambiguate (or collate) correct application
CPEs; especially beyond the lifetime of osCPE support timeframes.
The package notes are nice standard mechanism to figure out the exact name and
version of a program or a library stored in a file, without running the code.
In the beginning this was designed for the purpose of analyzing core dumps, but
we've since started to use it more generically to identify files. The same need
to identify PE/COFF files occurs, for example for systemd-boot and other files
intended for UEFI. It has also been requested by people working on bootupd
(https://github.com/coreos/bootupd).
The text is changed to say "Executable" or "ELF or PE/COFF" wherever "ELF" was
used previously.
The description for PE/COFF files is very brief. AFAIK, we don't have the same
"note" mechanism there [1], so just a normal section is used. The alignment
rules for PE/UEFI are different and change over time, so no specific alignment
is specified.
Other requirements for the PE/COFF section are based on what ukify currently
does for the .osrel section:
5 .osrel 00000056 000000010132f000 000000010132f000 0002b600 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
The name ".pkgnote" is used as suggested by Daan De Meyer. This corresponds to
the ".note.package" name used for ELF. ".package" was also suggested, but I
think that is too generic and carries more risk of a conflict with a different
use.
[1] https://learn.microsoft.com/en-us/windows/win32/debug/pe-format
Also zero/0 is replaced by NUL to clarify that a single 0 byte is meant.
We described the "how", but not the "why". And the text was a bit dated,
still mostly talking about core files. Let's make it more general
and describe why a section is used.
Add a recommendation/explanation for the debugInfoUrl field.
This document is renamed without any changes in a separate commit.
Otherwise, git does not show a diff, which makes it very hard
to review what is actually changed in the text.
