Backport version reporting (PR #5093 and #5111) to 0.15.x #5126

Copilot · 2025-11-27T18:08:02Z

Original prompt

This section details on the original issue you should resolve

<issue_title>Back port version reporting for to 0_15_x</issue_title>
<issue_description>please create a new PR back porting the two PRs listed, using cherry-pick then new commits for any compatibility issues

Backport
#5093
And
#5111</issue_description>

Comments on the Issue (you are @copilot in this section)

Fixes Back port version reporting for to 0_15_x #5125

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

Summary by CodeRabbit

New Features
- Device ID generation with deterministic fingerprinting for unique device identification
- Bootloader SHA256 integrity verification on ESP32 devices
- New JSON metadata fields exposing device repository and ID information
- Cross-platform SHA1 computation support
Chores
- Configuration file updates

_{✏️ Tip: You can customize this high-level summary in your review settings.}

coderabbitai · 2025-11-27T18:08:07Z

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Walkthrough

This PR backports device identification and bootloader integrity features. It adds platform-specific device fingerprinting via SHA1-based IDs, bootloader SHA256 hashing for ESP32, and expands JSON info serialization with device and repository identifiers.

Changes

Cohort / File(s)	Change Summary
Build Configuration `.gitignore`	Adds CodeQL-detected source root to ignore list
Function Declarations `wled00/fcn_declare.h`, `wled00/ota_update.h`	Declares new public functions: `computeSHA1()`, `getDeviceId()` for device identification; `calculateBootloaderSHA256()`, `getBootloaderSHA256Hex()`, `invalidateBootloaderSHA256Cache()` for bootloader integrity on ESP32
Implementation - Device ID & Cryptography `wled00/util.cpp`	Implements platform-specific SHA1 hashing (ESP8266 native, ESP32 mbedtls), deterministic device fingerprinting combining MAC/flash/chip metadata, and caching for device ID generation
Implementation - Bootloader Hashing `wled00/ota_update.cpp`	Implements ESP32 bootloader SHA256 calculation with chunked flash reads, hex formatting, cache storage, and invalidation logic; guarded by platform and OTA compile flags
JSON Serialization `wled00/json.cpp`	Adds `deviceId` and `repo` fields to info JSON output; conditionally includes `bootloaderSHA256` when OTA is enabled; includes `ota_update.h` header

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~35 minutes

Cryptographic operations (SHA1, SHA256) require verification of implementation correctness and security
Device fingerprinting algorithm uses multiple platform-specific data sources; determinism across restarts must be confirmed
Bootloader offset constants (0x1000) and size (32KB) should be validated against ESP32 IDF specifications
Conditional compilation guards and platform detection logic span multiple files; consistency checks needed
Cache invalidation and memory safety in hex formatting functions

Possibly related PRs

Safe uid generation #5111 — Introduces generateDeviceFingerprint() and platform-specific device ID logic that this PR backports
Add Device ID to JSON Info #5093 — Adds device ID and SHA1 declarations/implementations to JSON serialization, directly backported here
Add ESP32 bootloader upgrade capability to OTA update page with JSON API support and ESP-IDF validation #4984 — Implements ESP32 bootloader SHA256 computation and OTA metadata exposure matching this PR's changes

Suggested reviewers

netmindz
DedeHai
willmmiles

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 55.56% which is insufficient. The required threshold is 80.00%.	You can run `@coderabbitai generate docstrings` to improve docstring coverage.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the backport of version reporting features from two upstream PRs to the 0.15.x branch, reflecting the main change.
Linked Issues check	✅ Passed	The PR implements all coding requirements: Device ID reporting, improved fingerprinting, and bootloader SHA256 support across both ESP32 and ESP8266 platforms.
Out of Scope Changes check	✅ Passed	All changes are directly related to backporting version reporting features (Device ID, fingerprinting, bootloader SHA256) as specified in linked issue #5125.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

Co-authored-by: netmindz <[email protected]>

wled00/util.cpp

softhack007 · 2025-11-27T20:52:17Z

@netmindz if you also want the bootloader hash reported, then calculateBootloaderSHA256() needs to be added in 0.15.2, too.

netmindz · 2025-11-27T22:58:58Z

@copilot we also need to cherry-pick calculateBootloaderSHA256() from the main branch

Co-authored-by: netmindz <[email protected]>

Copilot · 2025-11-27T23:12:07Z

@copilot we also need to cherry-pick calculateBootloaderSHA256() from the main branch

Added calculateBootloaderSHA256(), getBootloaderSHA256Hex(), and invalidateBootloaderSHA256Cache() functions to ota_update.cpp, along with the bootloaderSHA256 field in the JSON info response. Used spi_flash_read() instead of esp_flash_read() for compatibility with ESP-IDF v3. Commit: bb3ee7c

wled00/ota_update.cpp

wled00/util.cpp

softhack007 · 2025-11-29T00:29:39Z

@coderabbitai review

coderabbitai · 2025-11-29T00:29:44Z

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

coderabbitai

Actionable comments posted: 0

♻️ Duplicate comments (1)

wled00/ota_update.cpp (1)

6-8: ESP32 bootloader offset handling looks correct across variants

The new BOOTLOADER_OFFSET selection via CONFIG_IDF_TARGET_* should fix the earlier S3/C3 mis-hash issue while keeping legacy ESP32/ESP32-S2 at the traditional 0x1000 offset. Using ESP32/CONFIG_IDF_TARGET_* here is consistent with established patterns for variant detection. One small follow-up: the later comment inside calculateBootloaderSHA256() still claims a fixed 0x1000 offset; consider updating it to reflect the new BOOTLOADER_OFFSET logic.

Also applies to: 15-22

🧹 Nitpick comments (3)

wled00/json.cpp (1)

2-2: JSON info extensions are wired correctly and respect feature guards

Including ota_update.h is appropriate given the new bootloaderSHA256 field and matches the ESP32+OTA guard around getBootloaderSHA256Hex().

Adding "repo" (repoString) and "deviceId" (getDeviceId()) to serializeInfo() cleanly extends the info schema without breaking existing consumers.

On ESP32, "bootloaderSHA256" is only emitted when OTA is enabled, which is consistent with the implementation being compiled under the same guard.

The deviceId is derived from a salted, hashed fingerprint and is used only for version/upgrade statistics, which aligns with the intended low-privacy-risk usage. Based on learnings, this is acceptable for the opt‑in reporting use case.

Also applies to: 635-637, 740-761

wled00/ota_update.cpp (1)

270-321: Bootloader SHA256 computation is sound, but read errors are silently ignored

The hashing flow (fixed-size region, 256‑byte chunks, mbedTLS SHA256, cached hex string) is reasonable and guarded correctly by ARDUINO_ARCH_ESP32 && !WLED_DISABLE_OTA. Two potential improvements:

If esp_flash_read / spi_flash_read fails for a chunk, the loop still proceeds and a hash is emitted; that could mask partial‑read issues. Consider bailing out (and leaving the cache empty) or logging an explicit error when a read fails.

The 0x8000 bootloader size is currently a magic number; a named constexpr size_t BOOTLOADER_SIZE = 0x8000; would make intent clearer and simplify future adjustments.

wled00/util.cpp (1)

6-6: Device ID hashing flow is consistent and privacy‑aware

computeSHA1 correctly normalizes the SHA1 implementation across ESP8266 (Hash.h) and ESP32 (mbedTLS), returning a 40‑char hex string.

getDeviceId()’s “double‑hash and append last 2 chars” approach yields a deterministic 42‑character ID while making it non‑trivial to recover the underlying fingerprint or MAC.

Caching the result in a static String avoids repeated hashing overhead for frequent JSON info requests.

Given this ID is only used for opt‑in version/upgrade statistics and not behavioral tracking, the MAC+salt‑based design is aligned with the intended low‑risk usage. Based on learnings, the privacy trade‑off looks acceptable.

Also applies to: 14-16, 752-776, 826-845

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d85ef56 and f9e72f9.

⛔ Files ignored due to path filters (1)

package-lock.json is excluded by !**/package-lock.json

📒 Files selected for processing (6)

.gitignore (1 hunks)
wled00/fcn_declare.h (1 hunks)
wled00/json.cpp (3 hunks)
wled00/ota_update.cpp (2 hunks)
wled00/ota_update.h (1 hunks)
wled00/util.cpp (2 hunks)

🧰 Additional context used

📓 Path-based instructions (2)

wled00/**/*.cpp

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

Use 2-space indentation for C++ source files (.cpp)

Files:

wled00/json.cpp
wled00/ota_update.cpp
wled00/util.cpp

wled00/**/!(html_*)*.h

📄 CodeRabbit inference engine (.github/copilot-instructions.md)

Use 2-space indentation for non-generated C++ header files (.h)

Files:

wled00/ota_update.h
wled00/fcn_declare.h

🧠 Learnings (21)

📓 Common learnings

Learnt from: netmindz
Repo: wled/WLED PR: 5093
File: wled00/util.cpp:1159-1182
Timestamp: 2025-11-20T00:04:04.829Z
Learning: In WLED PR #5093, the deviceId feature is designed for opt-in usage reporting that tracks only version/upgrade information (non-behavioral data), not user activity patterns. The deterministic salt approach (MAC + "WLED" + chip model/revision) is acceptable for this limited use case, as correlating MAC addresses to version history represents minimal privacy risk compared to behavioral tracking.