mirror of https://github.com/wolfSSL/wolfBoot.git
wolfBoot_start() in hal/library.c ended its exit: path with an unconditional 'return 0;', so a rejected image (bad header, hash or signature) still made the test-lib process exit 0. main() propagates wolfBoot_start()'s return value, so the failure was only visible in the printed "Failure" message, which the test-library workflow had to grep for (TODO referencing PR #625). Return ret, which carries the wolfBoot_verify_*() error on every path that reaches exit: with a failure. The success path never returns: do_boot() jumps to the firmware. The test-library workflow drops the status-rewriting workaround and asserts the non-zero exit code directly, keeping the "Failure" message check as a diagnostic. Verification: - Built: make test-lib (host, library.config, ED25519/SHA256). - Tested: local repro of the workflow flow: corrupt the last byte of a signed image; before the fix the process exited 0 while printing "Failure -1", after the fix it exits 255; a valid image still exits 0 with "Firmware Valid". - Pitfalls: 'return ret' only changes the error paths; do_boot() does not return on success. - Style: the cstyle-check.sh FMT flag on hal/library.c is present on the pre-change file as well (not introduced here). - Message: F-9749: prefix, no co-author trailers. |
||
|---|---|---|
| .. | ||
| docker/renesas-rx | ||
| workflows | ||