With the default APP_RETRIEVE_LEN_ELF_SHA setting, core dump files only have a
truncated ELF SHA256 in them. Account for this when comparing the core dump SHA
with the app ELF SHA.
The comment says it returns the "SHA256 hash of the input ELF file", but this is
not true - it was the SHA256 hash of the output ELF file. As the parser may
change some bytes around in minor ways, these were often not the same.
The check that the app ELF file SHA256 matches the one stored in the core dump
would never fail, leading to gdb loading the wrong ELF file and either crashing
or producing misleading debug information.
Specifics:
The note_sec.name field was incorrectly read back as b'ESP_CORE_DUMP_INFO\x00E',
because the namesz length includes the terminating NUL byte and possible junk
padding bytes:
https://github.com/espressif/esp-idf/blob/master/components/espcoredump/src/core_dump_elf.c#L212
In addition, as 'note_sec.name' is a bytes object Python 3 would have never
successfully compared it with a string.
ESP32S2/C3/S3: fixed S2 dangerous power parameters in sleep modes and support S2/C3/S3 different sleep mode(v4.4)
See merge request espressif/esp-idf!23758
1 Fixed disconnection delay on peripheral when slave latency is not zero
2 Fixed LLCP info init for central and peripheral
3 Fixed sent cmd status evt twice when process disconnect cmd
Conflicts:
- protobuf-c submodule version and hash changed to v1.4.0
- removed pytest dependency
This adds SBOM information for submodules, which are not managed
by Espressif. Meaning there is no fork for them in the espressif
namespace. Other submodules should add sbom.yml manifest file to
the root of their git repository.
The SBOM information for submodules is stored in the .gitmodules file.
Each SBOM related variable has the "sbom-" prefix and the following
variables may be used:
sbom-version:
submodule version
sbom-cpe:
CPE record if available in NVD. This will be used by the SBOM
tool to check for possible submodule vulnerabilities. The
version in the CPE can be replaced with the "{}" placeholder,
which will be replaced by the "sbom-version" value from above.
sbom-supplier:
Person or organization who is providing the submodule.
It has to start with "Person:" or "Organization:" prefix
as required by the SPDX-2.2 standard.
sbom-url:
URL to the project if exists, e.g. github.
sbom-description:
Project description.
sbom-hash:
Submodule SHA as recorded in the git-tree. This field is used by
CI to check that the submodule checkout hash and info in .gitmodules
are in sync. IOW if submodule is updated and it has SBOM info in
.gitmodules, the .gitmodules has to be updated too. The test is
part of this commit. The checkout has of the submodule can be found
by using "git submodule status".
Example for micro-ecc submodule
---8<---
[submodule "components/bootloader/subproject/components/micro-ecc/micro-ecc"]
path = components/bootloader/subproject/components/micro-ecc/micro-ecc
url = ../../kmackay/micro-ecc.git
sbom-version = 1.0
sbom-cpe = cpe:2.3🅰️micro-ecc_project:micro-ecc:{}:*:*:*:*:*:*:*
sbom-supplier = Person: Ken MacKay
sbom-url = https://github.com/kmackay/micro-ecc
sbom-description = A small and fast ECDH and ECDSA implementation for 8-bit, 32-bit, and 64-bit processors
sbom-hash = d037ec89546fad14b5c4d5456c2e23a71e554966
---8<---
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
