Current Situation
I noticed during my review of the eos_pkg implementation that the package verification logic currently relies on "stub" functions. Specifically:
eos_ed25519_verify_stub: Always returns 0 (Success) without performing any cryptographic verification.eos_sha256_stub: Implements a simple XOR/addition-based hashing algorithm instead of a cryptographically secure hash like SHA256.
Problem Description
The use of these stubs in a project aiming for production-level embedded safety and security (as indicated by the architecture and products like aerospace.h and medical.h) creates a false sense of security. An attacker could easily craft a malicious .eapp package that satisfies the weak hash requirement and bypasses signature verification entirely.
Proposed Improvement
I recommend prioritizing a transition from these stubs to production-grade cryptographic implementations:
- Integrate a real Ed25519 library: Replace the stub with a proper verification routine.
- Use standard SHA256: Replace the custom XOR-sum with the project's existing SHA256 implementation (which I saw in
services/crypto/).
- Harden the .eapp header: Ensure the header contains all necessary metadata for full integrity and authenticity checks.
Why This Matters
For a next-gen embedded OS, the integrity of the package management system is a foundational security property. Moving away from these placeholders will bring the project closer to its stated security goals and provide real protection for end-users.
I'm happy to discuss the architectural implications of these changes if there's interest in moving this forward.
Current Situation
I noticed during my review of the
eos_pkgimplementation that the package verification logic currently relies on "stub" functions. Specifically:eos_ed25519_verify_stub: Always returns0(Success) without performing any cryptographic verification.eos_sha256_stub: Implements a simple XOR/addition-based hashing algorithm instead of a cryptographically secure hash like SHA256.Problem Description
The use of these stubs in a project aiming for production-level embedded safety and security (as indicated by the architecture and products like
aerospace.handmedical.h) creates a false sense of security. An attacker could easily craft a malicious.eapppackage that satisfies the weak hash requirement and bypasses signature verification entirely.Proposed Improvement
I recommend prioritizing a transition from these stubs to production-grade cryptographic implementations:
services/crypto/).Why This Matters
For a next-gen embedded OS, the integrity of the package management system is a foundational security property. Moving away from these placeholders will bring the project closer to its stated security goals and provide real protection for end-users.
I'm happy to discuss the architectural implications of these changes if there's interest in moving this forward.