diff --git a/docs/OPENSSF_TECHNICAL_REVIEW.md b/docs/OPENSSF_TECHNICAL_REVIEW.md index 2633bf98..875f3acf 100644 --- a/docs/OPENSSF_TECHNICAL_REVIEW.md +++ b/docs/OPENSSF_TECHNICAL_REVIEW.md @@ -1,8 +1,8 @@ # ExecSurface — OpenSSF Technical Review Pack Tracking: #94, #114, #118 -Current public release: `v0.1.0-alpha.5` -Release source: `9e73b925d55557e33de1b0813995609aaefdc037` +Current public release: `v1.0.0` +Release source: `e70169b959f2163715090c371335fa6c5591e3e4` Audience: OpenSSF engineers, maintainers and researchers evaluating technical fit, overlap, reproducibility, architecture and interoperability. The prior Alpha.4 review pack is retained unchanged at `docs/archive/engagement/OPENSSF_TECHNICAL_REVIEW_ALPHA4.md`. @@ -29,7 +29,7 @@ Native ptrace is the bounded public reference observer, not universal authority ## Current limitations reviewers should challenge -- Linux x86_64 public alpha only; ARM64 support is not claimed. +- Stable v1.0.0 support is bounded to Linux x86_64; ARM64 support is not claimed. - ptrace availability depends on kernel/security/container/namespace configuration. - ptrace can perturb workloads and has workload-dependent overhead. - pathname userspace observations are not kernel-object identity. @@ -44,23 +44,23 @@ Native ptrace is the bounded public reference observer, not universal authority ### Registry ```bash -cargo install execsurface --version "=0.1.0-alpha.5" --locked +cargo install execsurface --version "=1.0.0" --locked execsurface --version execsurface doctor ``` ### GitHub Action -Stable public-alpha channel: +Stable v1 channel: ```yaml -uses: AETHERXGLOBAL/execsurface@v0.1 +uses: AETHERXGLOBAL/execsurface@v1 ``` Immutable review pin: ```yaml -uses: AETHERXGLOBAL/execsurface@v0.1.0-alpha.5 +uses: AETHERXGLOBAL/execsurface@v1.0.0 ``` ## Minimal falsification walkthrough @@ -88,7 +88,7 @@ Do not send secrets or private payload data. ## Post-release validation governance -Alpha.5 was published under explicit owner authorization before P8 independent external validation closed. P8 remains open after release. Internal release proofs do not become independent evidence merely because the release is public. +Stable v1.0.0 was published after the repository's strengthened internal qualification and release-control gates. Independent external validation remains open as additional evidence and is not claimed. Internal release proofs do not become independent evidence merely because the release is public. Do not describe external interaction as OpenSSF validation, Linux Foundation approval, partnership, endorsement or adoption unless exact external evidence supports that wording. diff --git a/docs/external/OPENSSF_ENGAGEMENT.md b/docs/external/OPENSSF_ENGAGEMENT.md index 10c24f19..e8043dd2 100644 --- a/docs/external/OPENSSF_ENGAGEMENT.md +++ b/docs/external/OPENSSF_ENGAGEMENT.md @@ -2,16 +2,16 @@ Tracking: #94 Status: `POST-RELEASE TECHNICAL ENGAGEMENT — EXTERNAL EVIDENCE OPEN` -Current public release: `v0.1.0-alpha.5` -Release source: `9e73b925d55557e33de1b0813995609aaefdc037` -Stable Action: `AETHERXGLOBAL/execsurface@v0.1` +Current public release: `v1.0.0` +Release source: `e70169b959f2163715090c371335fa6c5591e3e4` +Stable Action: `AETHERXGLOBAL/execsurface@v1` Current baseline: `docs/external/OPENSSF_CURRENT_STATE_BASELINE.md` ## Relationship classification Treat OpenSSF as: -`EXTERNAL TECHNICAL COMMUNITY / OPEN-SOURCE SECURITY ECOSYSTEM` +`EXTERNAL TECHNICAL COMMUNITY / SOFTWARE SUPPLY-CHAIN & OPEN-SOURCE ENGINEERING ECOSYSTEM` Do not describe OpenSSF / Linux Foundation as customer, validator, partner, approver, or endorser unless a later explicit agreement supports that wording. @@ -21,7 +21,7 @@ AETHER X previously asked OpenSSF for independent technical evaluation of ExecSu OpenSSF / Linux Foundation responded that OpenSSF projects are community-driven, recommended participating directly in OpenSSF Working Groups for technical insight, invited AETHER X to join the community, and noted that membership can be discussed separately. -That routing is historical context only. All new technical engagement is governed by the current Alpha.5 baseline and the post-release P8 evidence program. +That routing is historical context only. All new technical engagement is governed by the current stable-v1 baseline and the post-release external-evidence program. ## Current engagement objective @@ -72,18 +72,18 @@ Do not split initial technical engagement across many groups without a specific ## Public review target -External reviewers should evaluate the published Alpha.5 release, not an obsolete candidate: +External reviewers should evaluate the published stable v1.0.0 release, not an obsolete Alpha candidate: -- release: `v0.1.0-alpha.5` -- immutable Action: `AETHERXGLOBAL/execsurface@v0.1.0-alpha.5` -- stable Action: `AETHERXGLOBAL/execsurface@v0.1` -- registry package: `execsurface = 0.1.0-alpha.5` +- release: `v1.0.0` +- immutable Action: `AETHERXGLOBAL/execsurface@v1.0.0` +- stable Action: `AETHERXGLOBAL/execsurface@v1` +- registry package: `execsurface = 1.0.0` - platform scope: Linux x86_64 - public reference observer: native `ptrace` - public review hub: issue #118 - P8 evidence tracking: issue #114 -Alpha.5 publication was owner-authorized with P8 waived only as a pre-publication condition. This is not a statement that P8 passed. Independent external validation remains open post-release. +Stable v1.0.0 is internally qualified under the recorded governance and release-control gates. Independent external validation remains open as additional evidence and is not claimed. ## Community-entry rule diff --git a/docs/external/RUST_CODE_REVIEW_ENGAGEMENT.md b/docs/external/RUST_CODE_REVIEW_ENGAGEMENT.md index f24d4a8c..8f300b94 100644 --- a/docs/external/RUST_CODE_REVIEW_ENGAGEMENT.md +++ b/docs/external/RUST_CODE_REVIEW_ENGAGEMENT.md @@ -2,7 +2,7 @@ Status: **PREPARED — FORUM POSTING PENDING AUTHENTICATED ACCOUNT** Date opened: **2026-09-29** -Last aligned to public release: **2026-10-01** +Last aligned to public release: **2026-10-08** External referral: Rust Foundation → official Rust Users Forum `code review` category ## 1. Source event @@ -18,16 +18,16 @@ The original outreach named an earlier alpha; that reference is historical only. Current public review target: - repository: `AETHERXGLOBAL/execsurface` -- public release: `v0.1.0-alpha.5` -- release source commit: `9e73b925d55557e33de1b0813995609aaefdc037` -- immutable Action: `AETHERXGLOBAL/execsurface@v0.1.0-alpha.5` -- stable Action: `AETHERXGLOBAL/execsurface@v0.1` -- registry package: `execsurface = 0.1.0-alpha.5` +- public release: `v1.0.0` +- release source commit: `e70169b959f2163715090c371335fa6c5591e3e4` +- immutable Action: `AETHERXGLOBAL/execsurface@v1.0.0` +- stable Action: `AETHERXGLOBAL/execsurface@v1` +- registry package: `execsurface = 1.0.0` - platform boundary: Linux x86_64 - public reference observer: native `ptrace` - product boundary: runtime behavioral-integrity and verification for observed execution-surface drift; not antivirus, EDR, malware detection, sandboxing, or proof of software safety. -Alpha.5 keeps incomplete or ambiguous observation non-PASS-eligible, preserves conservative shared-FD incompleteness where exact attribution is not established, and keeps BPF-LSM/kernel-hook work research/managed and non-default. +Stable v1.0.0 keeps incomplete or ambiguous observation non-PASS-eligible, preserves conservative shared-FD incompleteness where exact attribution is not established, and keeps BPF-LSM/kernel-hook work research/managed and non-default. ## 3. Why ask the Rust community @@ -55,9 +55,9 @@ Architecture questions such as ptrace vs LSM/BPF are tracked separately in `docs - `docs/STATUS.md` — current public state - `docs/TECHNICAL_EVALUATION.md` — independent technical evaluation path - `docs/architecture/PTRACE_VS_LSM_ARCHITECTURE_REVIEW.md` — observer-authority review -- `docs/releases/v0.1.0-alpha.5.md` — current release record +- `docs/releases/v1.0.0.md` — current release record - public CI/adversarial fixtures under `.github/workflows/` and `.github/m12-fixtures/` -- issue #118 — public Alpha.5 post-release review hub +- issue #118 — stable-v1 external evaluation and post-release review hub Failures, REVIEWs, incomplete observations, usability friction, and code defects are useful evidence and must be retained rather than tuned away. @@ -73,7 +73,7 @@ Hello, The Rust Foundation pointed me to this category as the appropriate place to ask for community code review. -I maintain **ExecSurface**, an Apache-2.0 Rust CLI/GitHub Action for runtime behavioral-integrity verification on Linux x86_64. The current public release is **v0.1.0-alpha.5**. +I maintain **ExecSurface**, an Apache-2.0 Rust CLI/GitHub Action for runtime behavioral-integrity verification on Linux x86_64. The current public release is **v1.0.0**. I am **not** looking for endorsement or a broad security claim. I would specifically value criticism of the Rust/Linux implementation boundary, especially the native ptrace observer: @@ -95,7 +95,7 @@ Known limitations are intentionally public. Pathname data copied at syscall entr Repository: `https://github.com/AETHERXGLOBAL/execsurface` -Current release: `https://github.com/AETHERXGLOBAL/execsurface/releases/tag/v0.1.0-alpha.5` +Current release: `https://github.com/AETHERXGLOBAL/execsurface/releases/tag/v1.0.0` Observer implementation: `https://github.com/AETHERXGLOBAL/execsurface/blob/main/crates/execsurface-observe/src/linux_ptrace.rs`