Minimal command-line hashing utility for EriX SHA-2 workflows.
Find a file
Erik Inkinen 978713f922
All checks were successful
CI / markdown (push) Successful in 5s
CI / test (push) Successful in 13s
Tighten CI markdown policy
2026-05-22 15:10:41 +03:00
.github Tighten CI markdown policy 2026-05-22 15:10:41 +03:00
src Enhance README and main.rs to support SHA-256 hashing and update usage instructions 2026-02-26 17:08:32 +02:00
.editorconfig Initial commit 2026-02-26 15:55:53 +01:00
.gitignore Ignore local .ci workspace 2026-04-15 21:53:03 +03:00
.markdownlint-cli2.yaml Tighten CI markdown policy 2026-05-22 15:10:41 +03:00
ARCHITECTURE.md Tighten CI markdown policy 2026-05-22 15:10:41 +03:00
Cargo.toml Update CI policy checks 2026-05-22 15:01:55 +03:00
CODE_OF_CONDUCT.md Tighten CI markdown policy 2026-05-22 15:10:41 +03:00
CONTRIBUTING.md Tighten CI markdown policy 2026-05-22 15:10:41 +03:00
LICENSE Initial commit 2026-02-26 15:55:53 +01:00
README.md Tighten CI markdown policy 2026-05-22 15:10:41 +03:00
ROADMAP.md Tighten CI markdown policy 2026-05-22 15:10:41 +03:00
rustfmt.toml sha2-tool: drop unstable rustfmt options for stable toolchains 2026-03-23 10:19:57 +02:00
SECURITY.md Tighten CI markdown policy 2026-05-22 15:10:41 +03:00

sha2-tool

sha2-tool provides host-side tooling for the sha2 workflow in EriX builds and validation.

EriX is a clean-room, capability-based microkernel operating system written entirely in Rust.

Technical requirements are tracked in the EriX requirements, conventions, and project documentation.

See:

  • docs for design documents, specifications, and development plans.
  • Related architecture repositories for kernel, services, libraries, drivers, and integration tooling.

Purpose of This Repository

This repository implements the EriX sha2 tool. Its purpose in EriX is to support the sha2 workflow used by builds and validation.

Functionally, it implements command-line behavior, input validation, and usage documentation. The repository keeps the implementation, interface contracts, tests, and documentation for that behavior in one reviewable ownership boundary.

The maintained responsibilities are:

  • provide command-line operations for sha2 development workflows
  • validate inputs and produce deterministic output artifacts
  • keep CLI behavior covered by tests and repository documentation

Clean-Room Policy

EriX follows a strict clean-room philosophy:

  • No external source code may be copied.
  • No external Rust crates are allowed.
  • No code generation tools that embed third-party code.
  • All code must be authored within the project.

Violations will result in rejection of the contribution.

License

All EriX repositories are licensed under the ISC License.

Development Model

EriX development is modular, deterministic, reproducible, authority-explicit, security-first, and self-hosting oriented.

This repository follows the project roadmap and the validation rules documented in its own roadmap.

Planned usage shape

Examples:

  • sha2-tool sha512 <file>
  • sha2-tool sha256 <file>
  • sha2-tool sha512 - (read stdin)

Dependencies

  • lib-sha2 for hashing implementation

Status

Implemented baseline.

sha256 and sha512 command paths, stdin mode, and sum-style output are implemented. Remaining work focuses on robustness tests and optional compatibility flags.

See ARCHITECTURE.md and ROADMAP.md.

Governance Principles

sha2-tool governance is scoped to deterministic host-side sha2 tooling.

The scoped governance rules are:

  • It must operate only on caller-provided host paths and command-line inputs.
  • It keeps generated artifacts reproducible and inspectable by project tooling.
  • It reports validation failures explicitly rather than modifying inputs silently.
  • It does not define runtime kernel or service authority.

Tool Boundaries

  • sha2-tool has host process authority only while invoked by the developer or CI.
  • Any generated artifact contract must be documented for consumers.

Contact

Development occurs in EriX organization and discussions happen in issues and design documents.

No decisions are considered valid without documented rationale.

Maintainers can be reached via email: admin@erikinkinen.fi.