[Kartikey1306]

master has not compiled tests/test_crypto_ed25519_loworder.c since #93. The
file is still in the tree; no add_executable() builds it.

This is why #126 is red — its own change is one file under toolchains/,
and the failure is in Run Python tests on the Linux host. #126 did not cause
it and cannot fix it.

What happened

#101 registered the target alongside the fix it guards. #93 branched before
that, so when it removed duplicate test targets, this one looked like one more
duplicate. It was not, and it was the only non-duplicate the diff touched:

$ comm -23 <targets at 39640bb, before #93> <targets at 3aa8644, after #93>
test_crypto_ed25519_loworder

The four lines it removed:

-# --- 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)

Everything else #93 removed was a genuine duplicate, and removing those was
right.

Why it matters

That is the regression test for #98. An all-zero public key is one of
Ed25519's eight low-order points; before #101 it accepted forged signatures
over messages nobody signed, which is how eos_pkg accepted arbitrary
packages. Between #93 merging and this PR, nothing checked that the fix was
still in place.

A missing add_executable fails nothing — the file simply stops being built —
so the suite stayed green while the guard was gone.

The test is load-bearing, not decorative

Verified rather than assumed. Disabling the subgroup check in
services/crypto/src/ed25519_verify.c and rebuilding the restored target:

  test_all_zero_key_is_rejected   [FAIL]
    ed25519_verify(sig, m, strlen(FORGEABLE_MESSAGES[i]), key) != 1

Restored: 5/5, including test_every_low_order_key_is_rejected and
test_rfc8032_vector_still_verifies (so a verifier that rejected everything
would not pass either).

Verification

item	result
test_cmake_test_registration.py on master	FAIL — 1 failed, 4 passed
same, with this change	PASS — 5 passed
test_crypto_ed25519_loworder	PASS — 5/5
the same, with the subgroup check disabled	FAIL — as it should
ctest	PASS — 39/39
pytest tests/	PASS — 15 passed

The part worth acting on beyond this patch

tests/unit/test_cmake_test_registration.py — the guard that catches exactly
this — was already on master when #93 merged. It would have failed on
#93. It did not run, because #93's checks sat at action_required and nothing
evaluated them before the merge.

So the guard worked; the gate around it did not exist. That is the concrete
case for #92 and for #121, which adds a single CI Gate check that branch
protection can require. This is the second time the same shape has cost this
repository a test: test_mpu_validate carries a comment in this very file
saying it "landed with the fix it guards (#109) and lost its registration to a
merge".

I flagged this failure mode on #94 before #93 merged — that PR removes
test_crc and test_crypto_failclosed the same way, and
test_crypto_failclosed guards the EOS_ALLOW_STUB_CRYPTO fail-closed policy
from #84. Worth rebasing #94 before it lands.

[Kartikey1306]

Closing as a duplicate of #127, which does the same restore and has already
been reviewed clean.

Both PRs add back the test_crypto_ed25519_loworder target that #93 removed.
#127 restores the five lines verbatim to their original position; this one put
them beside test_mpu_validate with four lines of comment. The build result is
identical, so there is nothing here worth a second review of the same change —
two open PRs for one fix costs the maintainers more than the comment is worth.

Two sessions were working these repos in parallel and both reached this
independently, which is the actual defect worth noting.

Handing the one thing this PR had that #127 does not — the history in a
comment — to #127 as a suggestion rather than losing it.

The evidence gathered here still stands and is worth keeping in the record:

• The target was the only non-duplicate in fix(build): remove duplicate test targets from tests/CMakeLists.txt #93's diff:
  comm -23 <targets before #93> <targets after #93> → test_crypto_ed25519_loworder.
• It is load-bearing, not decorative. Disabling the subgroup check in
  services/crypto/src/ed25519_verify.c and rebuilding the restored target:
  test_all_zero_key_is_rejected [FAIL]. Restored: 5/5.
• test_cmake_test_registration.py — the guard that catches this — was already
  on master when fix(build): remove duplicate test targets from tests/CMakeLists.txt #93 merged and would have failed it. It did not run, because
  fix(build): remove duplicate test targets from tests/CMakeLists.txt #93's checks sat at action_required.

That last point is the reusable one, and it is the argument for #121.