[srpatcha]

This repository has three files. The README said:

Status: Planned. There is no implementation in this repository yet.

The crypto services are Implemented under §28 — "feature exists and is
usable", evidenced by code and functional tests. In eos, at
services/crypto/: 15 source files and seven test suites, all passing.

test_crypto  test_crypto_aes  test_crypto_ecc  test_crypto_rsa
test_crypto_sha512  test_crypto_ed25519_loworder  test_crypto_failclosed

But flatly upgrading the status would overstate it

Package signature verification is Experimental at best, and this README
should not let a reader assume otherwise:

services/pkg/eos_pkg.c:94
static const uint8_t eos_pkg_public_key[32] = {0};

An all-zero trust anchor. The low-order-key rejection that makes such a key fail
closed rather than open only just landed (embeddedos-org/eos#99) — before it,
that key accepted roughly one arbitrary signature in four. Tracked as
embeddedos-org/eos#98.

A verifier with no real key authenticates nothing. A repository called "the
security framework for EmbeddedOS" is exactly the wrong place to round that up
to "Implemented", so the README now distinguishes the two.

This is the same reasoning eos#84 applies with EOS_ALLOW_STUB_CRYPTO, and that
eAI applies with its compile-time #warning on secure_boot.c: a stub that
announces itself is safe, and one that reads as finished is not.

Also in this change

Replaces the old §24 citation with v2.0's sharper pair:

§10: Repositories should not be the dependency API.

§21.1: A subsystem earns a separate repository when it has a stable interface,
independent release lifecycle, clear maintainers and multiple consumers.

Adds the component manifest (embeddedos-org/embeddedos-stack#20) as the way to
depend on eSec, and records why splitting early is costly: there are two
independent Ed25519 implementations in the platform, in eos and eBoot, and the
same low-order-key bypass was present in both. Duplication across repositories is
how one fix stops being one fix.

Fixes #2

[Aswin-V]

Daily-loop code review (the loop does review; not a merge).

Light review: the status correction is accurate — services/crypto/ in eos is implemented and tested (AES, SHA-256/512 pass NIST vectors; the Ed25519 side just grew signing support today), so "Planned" was stale. Framing it against the §28 maturity definitions keeps the repo's own taxonomy honest.

One note for the author: the "one part is Experimental" carve-out should name the part explicitly in the README (readers shouldn't have to guess which of the seven test suites it is). Otherwise good to merge from the docs side.

[srpatcha]

@Aswin-V done in 5f27056. I also merged master (57bd114), which brought in your Security section cleanly.

• The status line now names the part: "Implemented in eos, at services/crypto/, except package signature verification (services/pkg/eos_pkg.c), which is Experimental." The next paragraph says outright that it isn't one of the seven crypto suites.
• While checking which part it was, I found the paragraph describing it was out of date. It said eos_pkg verifies against eos_pkg_public_key[32] = {0}. fix(pkg): give eos_pkg a real trust anchor, or refuse to verify eos#120 removed that key on 09-01. eos_pkg now verifies only against a platform-supplied anchor (eos_pkg_set_trust_anchor() or EOS_PKG_TRUST_ANCHOR_HEX) and refuses otherwise, unless a test build sets EOS_ALLOW_UNSIGNED_PKG. The README now says that.
• I kept the Experimental classification. eos ships no key of its own, the v2 signature envelope (d1b52bb) only landed on 10-04, and eos_pkg accepts any package — signature verified against an all-zero key with no low-order rejection eos#98 is still open.