From 13a8ffa2d19f0252f471c0a9b702a153d271887d Mon Sep 17 00:00:00 2001 From: kartikey1306 Date: Wed, 2 Sep 2026 19:34:50 +0530 Subject: [PATCH 1/3] fix(build): restore the low-order Ed25519 suite that #93 removed MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `CI — eos` and `Python Unit Tests` are red on master (769191a), and both fail for one reason: these suites exist in tests/ but no add_executable() in tests/CMakeLists.txt builds them, so they never run: ['test_crypto_ed25519_loworder.c'] 3aa8644 (#93, "remove duplicate test targets from tests/CMakeLists.txt") removed all four lines that build and register test_crypto_ed25519_loworder. It was not a duplicate — there was exactly one registration before that commit, and it took it. What stopped running is the suite that guards #101: Ed25519 rejecting low-order public keys. A low-order key makes every term of the verification equation collapse to the identity regardless of the message, so a signature of all zeros verifies against any content at all. The fix is still in services/crypto/src/ed25519_verify.c and still correct; nothing has been checking it since #93 merged, and nothing would have noticed if a later change had removed it too. Restored verbatim from 3aa8644^, in its original position before test_crypto_sha512. No other file changes. The guard that caught this is test_cmake_test_registration.py, added recently. It did exactly its job — this is the first thing it found. Verified: test_cmake_test_registration.py -> 5 passed (1 failed on master) pytest tests/ -> 15 passed (14 passed 1 failed on master) test_crypto_ed25519_loworder -> 5/5 tests passed ctest -> 39/39 passed (master builds 38) --- tests/CMakeLists.txt | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/tests/CMakeLists.txt b/tests/CMakeLists.txt index bfc0e049..f2d6c600 100644 --- a/tests/CMakeLists.txt +++ b/tests/CMakeLists.txt @@ -90,6 +90,11 @@ add_executable(test_crypto_rsa test_crypto_rsa.c) target_link_libraries(test_crypto_rsa PRIVATE eos_crypto) add_test(NAME test_crypto_rsa COMMAND test_crypto_rsa) +# --- test_crypto_ed25519_loworder: reject keys outside the prime-order subgroup --- +add_executable(test_crypto_ed25519_loworder test_crypto_ed25519_loworder.c) +target_link_libraries(test_crypto_ed25519_loworder PRIVATE eos_crypto) +add_test(NAME test_crypto_ed25519_loworder COMMAND test_crypto_ed25519_loworder) + # --- test_crypto_sha512: SHA-512 against NIST vectors --- add_executable(test_crypto_sha512 test_crypto_sha512.c) target_link_libraries(test_crypto_sha512 PRIVATE eos_crypto) From fafec15061c9cfcccd967989239e032233eb2746 Mon Sep 17 00:00:00 2001 From: kartikey1306 Date: Thu, 3 Sep 2026 15:35:59 +0530 Subject: [PATCH 2/3] chore(tests): drop the unused assert.h include from test_net.c Retitles and reduces this PR to what it still does, per the review. Both repairs it was opened for have landed on master by other routes: net/src/net_posix.c is byte-identical to origin/master, and master's default configuration builds clean. Against current master the branch's only real content was this one line -- and merging it as it stood would have *reverted* 646 lines that landed since, including #120's pkg trust anchor, tests/test_pkg_trust_anchor.c and tests/unit/test_cmake_test_registration.py. Reset to master and re-applied the one surviving change rather than leave a stale branch that still looks mergeable. The include is genuinely unused: tests/test_net.c has zero assert() calls and uses its own CHECK() macro at 22 call sites. Worth correcting the record, per finding 2: #124 added it one commit ago as "the missing assert.h include that broke master", and the file had no assert() at #124's parent either. What fixed that link error was the assert() -> CHECK() conversion already on master; the include was never load-bearing, so removing it changes nothing except the next reader's understanding. Stacked on #127, which restores the test_crypto_ed25519_loworder registration master is currently red on. Verified: pytest tests/ 15 passed ctest 39/39 PASS Refs #116, #124 --- tests/test_net.c | 1 - 1 file changed, 1 deletion(-) diff --git a/tests/test_net.c b/tests/test_net.c index ceec707e..1f4c00a3 100644 --- a/tests/test_net.c +++ b/tests/test_net.c @@ -2,7 +2,6 @@ #include #include #include -#include #define EOS_ENABLE_NET 1 #include "eos/eos_config.h" #include "eos/net.h" From 2a32e3a919c161e62f8323f2138a268f6828272b Mon Sep 17 00:00:00 2001 From: kartikey1306 Date: Thu, 3 Sep 2026 23:25:31 +0530 Subject: [PATCH 3/3] ci: pin the eBoot and ebuild checkouts instead of floating on master Every open eos pull request is currently red on `EoS Full-Stack Simulation`, and none of them caused it. The kernel job checks out embeddedos-org/eBoot at `ref: master`, and eBoot master does not compile: include/eos_image.h:135 and :142 static-assert offsetof(eos_image_header_t, reserved) for a member that became tlv_len + tlv_hash, and core/ed25519_verify.c redefines point_is_identity -- two pairs of PRs that each merged clean and broke the build together. eBoot #94 repairs it and waits on review; until it lands, no change to any eos PR can make this job pass, and after it lands the next broken eBoot master does the same thing again. A floating `ref: master` makes every eos PR's CI depend on the moment-to- moment state of another repository's default branch. Pinning the two compiled-against checkouts makes the job a function of this repository plus two recorded SHAs -- red means the PR broke something, green means it did not, and a cross-repo bump is a reviewable one-line diff with CI on it. EBOOT_COMMIT a172a6d6e1e6 the newest eBoot master ancestor that compiles; found by walking master back and building each candidate. Its child 8a015b2 already carries the ed25519 redefinition. EBUILD_COMMIT e5d8052f3e2c ebuild's current master, frozen as-is. Both of its checkouts feed steps that are commented out (eFab does not exist), so this pin only removes the float. The middleware matrix (10 repos) still floats; it runs those repos' own tests rather than compiling eos against them, and 10 more pins deserve their own decision. When eBoot #94 merges, bump EBOOT_COMMIT to the merge SHA. Verified before pushing, master vs pin under the job's own configuration (-DEBLDR_BOARD=qemu_arm64 -DEBLDR_VERIFY_STAGE1=OFF -DCMAKE_BUILD_TYPE=Release, cross-compile mode): eBoot@master fails at the eos_image.h asserts, the exact error in the job log; eBoot@a172a6d builds every target, rc=0. Both pinned SHAs verified reachable from their repos' master. Workflow parses; the three `ref:` edits and the env block are the whole diff. This PR's own simulation run is the live test: it uses this branch's workflow and should go green while every master-based PR stays red. Carried onto this branch from #135 (001128d8) so this PR's own simulation job runs against a buildable eBoot: each pull request executes its own copy of the workflow, so the fix greens a PR only once its branch contains it. Byte-identical to #135's commit -- git drops it as already-upstream the moment #135 merges. The pin itself is #135's to review. --- .github/workflows/eos-simulation.yml | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/.github/workflows/eos-simulation.yml b/.github/workflows/eos-simulation.yml index 1dbcd1e8..4cda5497 100644 --- a/.github/workflows/eos-simulation.yml +++ b/.github/workflows/eos-simulation.yml @@ -9,6 +9,15 @@ on: env: EOS_VERSION: "0.6.0" + # The kernel job compiles eBoot and checks out ebuild. Those used to float on + # `ref: master`, so the moment either repo's master stopped compiling, every + # open eos PR went red for a reason no eos change caused and no eos change + # could fix (2026-09-03: eBoot master's eos_image.h asserts a member that no + # longer exists, and its ed25519_verify.c has a redefined helper -- eBoot #94 + # repairs it). A dependency is pinned and bumped deliberately; when eBoot #94 + # lands, bump EBOOT_COMMIT to that merge and CI will say whether it holds. + EBOOT_COMMIT: "a172a6d6e1e66877413ed546401a65ee4f4f90db" + EBUILD_COMMIT: "e5d8052f3e2cfdcb1c91bab8300087aa07e02679" CROSS_COMPILE: "aarch64-linux-gnu-" QEMU_MACHINE: "virt" QEMU_CPU: "cortex-a57" @@ -29,14 +38,14 @@ jobs: uses: actions/checkout@v4 with: repository: embeddedos-org/eBoot - ref: master + ref: ${{ env.EBOOT_COMMIT }} path: eBoot - name: Checkout ebuild uses: actions/checkout@v4 with: repository: embeddedos-org/ebuild - ref: master + ref: ${{ env.EBUILD_COMMIT }} path: ebuild # embeddedos-org/eFab does not exist -- the checkout 404s and takes this @@ -276,7 +285,7 @@ jobs: uses: actions/checkout@v4 with: repository: embeddedos-org/ebuild - ref: master + ref: ${{ env.EBUILD_COMMIT }} # Same missing repository as in build-kernel. # - name: Checkout eFab