security: publish hardened v1 initiative snapshot
Publish the reviewed security policy and evidence, exact runtime ABI enforcement, orphan-output and permission safeguards, dead-upstream cleanup, and the evidence-gated v1 launch plan. This commit is an exact sanitized export from the private development record. Material implementation and review were assisted by OpenAI Codex; Cole Speelman reviewed the changes and accepts human responsibility. Himesan-Output-Permission: v1.0 Signed-off-by: Cole Speelman <gamertan@noreply.localhost>
This commit is contained in:
@@ -31,4 +31,8 @@ The stable proxy reserves `/__himesan/events` for SSE. It injects a fixed reload
|
||||
|
||||
When an existing CSP is present, the proxy adds the fixed script's SHA-256 source and same-origin SSE connection permission; it does not add `unsafe-inline` or `unsafe-eval`. The proxy and every candidate upstream are literal loopback addresses. Replaced process groups are terminated and waited for on Unix and Windows.
|
||||
|
||||
If the active application exits, the proxy immediately forgets that exact upstream and closes its idle connections. Requests receive the waiting page until another candidate passes its health check; a different process that later acquires the old loopback port is not selected implicitly.
|
||||
|
||||
Loopback is host-local, not user-local. Host, Origin, and Fetch Metadata checks defend against browser cross-site and DNS-rebinding requests, but they are not authentication against another process or account on the same workstation. Run `himesan dev` only on a trusted, single-user development machine and do not place secrets in its diagnostics. It invokes the configured Go toolchain, may fetch dependencies according to the user's Go environment, executes the project binary with the user's inherited environment, and forwards the application's requests and responses. Eligible HTML responses may be buffered up to 16 MiB for reload injection; application request, response, and SSE concurrency limits remain the application's and operating system's responsibility.
|
||||
|
||||
This is not a production proxy, TLS terminator, public preview server, process orchestrator, or deployment system. V1 refuses non-loopback binding.
|
||||
|
||||
@@ -0,0 +1,163 @@
|
||||
<!-- SPDX-License-Identifier: AGPL-3.0-only -->
|
||||
|
||||
# Security evidence ledger
|
||||
|
||||
This ledger records what was actually inspected and executed. It is a
|
||||
maintainer-led self-assessment, not an independent audit, certification, formal
|
||||
verification, or guarantee that no vulnerability exists.
|
||||
|
||||
## Assessment identity
|
||||
|
||||
| Field | Value |
|
||||
| --- | --- |
|
||||
| Assessment date | 2026-08-12 |
|
||||
| Public evidence identity | Exact file checksums in the co-published `PUBLIC-SNAPSHOT.sha256`; private/public commit mapping is retained only in the non-exported operational ledger |
|
||||
| Assessment phases | Clean pre-remediation source followed by clean remediated source |
|
||||
| Primary environment | Linux amd64 under WSL, Go 1.26.5 |
|
||||
| Declared minimum Go | Go 1.25 |
|
||||
| Assessor | Project maintainer with AI-assisted code review; human responsibility retained |
|
||||
|
||||
Security remediation discovered during this assessment was committed and the
|
||||
named checks were rerun from a clean source state. Before this ledger can support
|
||||
a versioned release, the complete campaign must be rerun from the exact
|
||||
sanitized public release commit. Private-to-public commit mappings are retained
|
||||
outside the exported source rather than being disclosed here.
|
||||
|
||||
## Observed evidence
|
||||
|
||||
| Property examined | Enforcement or test surface | Result observed on 2026-08-12 |
|
||||
| --- | --- | --- |
|
||||
| Root correctness | `go test -count=1 ./...` | Pass |
|
||||
| Concurrent access | `go test -race -count=1 ./...` | Pass |
|
||||
| Runtime concurrency | `(cd sando && go test -race -count=1 ./...)` | Pass |
|
||||
| Standard static analysis | `go vet ./...` and runtime equivalent | Pass |
|
||||
| Reachable known vulnerabilities | `govulncheck@v1.6.0` on both modules | No vulnerabilities found on 2026-08-12 |
|
||||
| Dependency surface | `go list -m -json all` in both modules | Zero third-party module requirements |
|
||||
| Statement coverage | Go cover profiles on remediated source | compiler 75.2%; devserver 80.2%; runtime 96.6% |
|
||||
| Parser robustness smoke | Two bounded Go fuzz targets | Pass; no panic found |
|
||||
| Deterministic generation | repeated generate/check/hash/mtime gates | Pass |
|
||||
| Writer failures | runtime error/short-write/nil-writer tests | Pass |
|
||||
| HTML text/attribute/RCDATA escaping | compiler and runtime adversarial cases | Pass for enumerated cases |
|
||||
| URL scheme handling | ordinary/trusted URL test matrix | Pass for enumerated cases |
|
||||
| Filesystem boundaries | symlink, nested-module, VCS, ownership, stale-output tests | Pass for tested cases; see open findings |
|
||||
| Development proxy browser boundary | Host, Origin, Fetch Metadata, CSP, fragment and response tests | Pass for tested cases |
|
||||
| Native platform behavior | Linux execution; Windows/macOS cross-compilation | Native Windows/macOS execution not yet evidenced |
|
||||
|
||||
Coverage measures statements executed by tests. It is not branch completeness
|
||||
and is not evidence that the executed behavior is secure.
|
||||
|
||||
`govulncheck` reports vulnerabilities known to the Go vulnerability database
|
||||
and reachable through its analysis. A clean result cannot detect unknown flaws,
|
||||
design errors, or vulnerabilities outside its model.
|
||||
|
||||
## Security-relevant design evidence
|
||||
|
||||
### Production boundary
|
||||
|
||||
The production `sando` module contains rendering contracts and contextual write
|
||||
helpers. It contains no HTTP server, router, middleware, template discovery,
|
||||
development proxy, plugin loader, or production process manager. Both compiler
|
||||
and runtime modules currently have no third-party Go module requirements.
|
||||
|
||||
### Compiler behavior
|
||||
|
||||
Compilation builds and formats outputs in memory before generation writes.
|
||||
Recursive discovery rejects or skips observed symlinks, nested modules, VCS
|
||||
trees, vendor trees, and detected filesystem crossings. Existing non-owned,
|
||||
symlink, and non-regular output files are rejected. Each changed file uses an
|
||||
atomic replacement primitive; the whole set is not a filesystem transaction if
|
||||
a later replacement fails.
|
||||
|
||||
`generate` and `check` do not run project code, invoke the Go toolchain, fetch
|
||||
dependencies, or edit module metadata. `himesan dev` is intentionally separate:
|
||||
it builds and executes trusted project code and may fetch modules under the
|
||||
user's normal Go configuration.
|
||||
|
||||
### Output contexts
|
||||
|
||||
The compiler accepts dynamic values only in its enumerated contexts. It rejects
|
||||
dynamic markup construction, unquoted attributes, event-handler values,
|
||||
dynamic style attributes, unsupported URL lists, foreign content, meta refresh,
|
||||
malformed tags, and unbalanced generated components. Runtime helpers escape
|
||||
ordinary text/attributes, validate ordinary whole-URL schemes before writing,
|
||||
and escape every trusted wrapper in RCDATA.
|
||||
|
||||
Script and style output require opaque trusted types. Those types deliberately
|
||||
move responsibility to trusted application code; they are not sanitizers.
|
||||
|
||||
## Reproduction commands
|
||||
|
||||
Run from a clean canonical checkout. Networked scans contact the Go module proxy
|
||||
and vulnerability database.
|
||||
|
||||
```sh
|
||||
go version
|
||||
git status --short
|
||||
git rev-parse HEAD^{commit} HEAD^{tree}
|
||||
|
||||
./scripts/check-licenses.sh
|
||||
HIMESAN_RACE=1 ./scripts/verify.sh
|
||||
|
||||
go test -count=1 -cover ./...
|
||||
(cd sando && go test -count=1 -cover ./...)
|
||||
|
||||
go run golang.org/x/vuln/cmd/govulncheck@v1.6.0 ./...
|
||||
(cd sando && go run golang.org/x/vuln/cmd/govulncheck@v1.6.0 ./...)
|
||||
|
||||
go test ./internal/compiler -run '^$' \
|
||||
-fuzz '^FuzzCompileNeverPanics$' -fuzztime=20s
|
||||
go test ./internal/compiler -run '^$' \
|
||||
-fuzz '^FuzzGoDelimiterNeverPanics$' -fuzztime=20s
|
||||
```
|
||||
|
||||
The fuzz targets currently assert process robustness and result bounds. They do
|
||||
not yet prove semantic HTML safety.
|
||||
|
||||
## Assessment findings and remediation status
|
||||
|
||||
The 2026-08-12 assessment identified six concrete gaps. Their current
|
||||
working-tree status is recorded here without rewriting the original baseline:
|
||||
|
||||
| Finding | Current remediation | Executable evidence |
|
||||
| --- | --- | --- |
|
||||
| Generated code named an ABI but did not enforce the exact contract | Generated code now requires the version-specific `sando.ABISandoV1` symbol | `TestGeneratedCodeRequiresVersionedRuntimeABIMarker`; `TestRuntimeABIMarker` |
|
||||
| Deleted or renamed sources could leave owned `.sando.go` orphans invisible to directory-level `check` | Directory discovery now reports owned outputs whose adjacent source is absent or non-regular and blocks the operation before writes | `TestDirectoryOperationsRejectOrphanedOwnedOutputBeforeWrites` |
|
||||
| Component-context prose included arbitrary handwritten implementations in the generated-component guarantee | Runtime documentation, policy, and threat model now classify handwritten components as trusted output capabilities | API documentation plus policy review; generated-balance tests retain their narrower scope |
|
||||
| An exited development child left its former upstream selected | Exit notification now clears only the matching active target immediately, independent of the watcher poll interval | `TestClearTargetOnlyClearsSelectedUpstream`; `TestSupervisorClearsTargetWhenCurrentApplicationExits` |
|
||||
| Trusted-value warnings were described more broadly than their analysis supports | Policy and threat-model copy now call them best-effort lexical audit hints rather than type or taint analysis | Documentation assertion and review |
|
||||
| Public copy implied a completed systematic `html/template` differential campaign | Policy and public security copy now describe fixed adversarial cases and list systematic differential work as open | Documentation assertion and review |
|
||||
|
||||
The remediated clean source passed the race-enabled repository verifier,
|
||||
sanitized-snapshot tests, both bounded fuzz-smoke targets, compiler/runtime
|
||||
known-vulnerability scans, and Windows/macOS cross-compilation on 2026-08-12.
|
||||
Those results do not become release evidence until the changes are committed,
|
||||
exported to the sanitized canonical public tree, and re-run from that exact
|
||||
public commit. Native Windows/macOS execution and the other gaps below remain
|
||||
separate release decisions.
|
||||
|
||||
## Open assurance gaps
|
||||
|
||||
- confidential mailbox delivery and response/recovery procedure must be tested;
|
||||
- release signing, checksum, SBOM, and provenance rehearsal is incomplete;
|
||||
- native Windows/macOS execution remains outstanding;
|
||||
- browser-parser differential and semantic property testing need expansion;
|
||||
- compiler input size, CPU, and memory have no built-in hard budget;
|
||||
- filesystem checks do not defend against a hostile local actor racing path
|
||||
components between inspection and use;
|
||||
- the watcher is a convenience mechanism, not a filesystem-integrity monitor;
|
||||
- human-readable diagnostics can include hostile local filenames or child-tool
|
||||
output and should not be treated as a sanitized log protocol;
|
||||
- development CSP rewriting is convenience, not production CSP validation;
|
||||
- deliberately detached child descendants may evade process-tree cleanup;
|
||||
- rendering has no built-in recursion, output-size, allocation, CPU, panic, or
|
||||
deadline enforcement;
|
||||
- static cycle detection and trust-use warnings are best-effort analyses; and
|
||||
- the project has no independent security audit or bug-bounty program.
|
||||
|
||||
## Interpreting this ledger
|
||||
|
||||
“Pass” means the named command or case produced its expected result in the named
|
||||
environment on the assessment date. It does not mean “secure.” Confidence comes
|
||||
from keeping the boundary small, making risky capabilities explicit, preserving
|
||||
ordinary generated Go for review, publishing reproducible tests, recording
|
||||
failures, and correcting claims when evidence is weaker than the prose.
|
||||
+167
-22
@@ -2,38 +2,183 @@
|
||||
|
||||
# Threat model
|
||||
|
||||
## Trusted
|
||||
This document separates demonstrated behavior from intended release work. It
|
||||
defines the boundary Sandwich Hime can reasonably defend; it is not a claim
|
||||
that the project or an application using it is universally secure.
|
||||
|
||||
- `.sando` files and embedded Go statements;
|
||||
- handwritten application Go;
|
||||
- explicit calls to `sando.TrustHTML`, `TrustURL`, `TrustJS`, and `TrustCSS`;
|
||||
- the selected compiler binary and runtime module version.
|
||||
## Security objective
|
||||
|
||||
## Untrusted
|
||||
For supported HTML contexts, data supplied to a compiler-generated component
|
||||
should remain data. It must not change HTML structure, create executable code,
|
||||
escape a quoted attribute, or introduce a disallowed URL scheme unless trusted
|
||||
application source makes an explicit security-sensitive decision.
|
||||
|
||||
- values supplied to components unless deliberately wrapped in a trusted type;
|
||||
That objective follows the same high-level model documented by Go's
|
||||
`html/template`: template authors are trusted while rendered data is not. The
|
||||
implementations and accepted languages differ. A systematic differential test
|
||||
campaign against `html/template` remains open work; current tests cover fixed
|
||||
adversarial cases and do not establish equivalence.
|
||||
|
||||
## Trusted capabilities
|
||||
|
||||
- `.sando` source, including its static markup and embedded Go statements;
|
||||
- handwritten application Go and values whose formatting methods execute Go;
|
||||
- handwritten implementations of `sando.Component`;
|
||||
- explicit `sando.TrustHTML`, `TrustURL`, `TrustJS`, and `TrustCSS` calls;
|
||||
- the selected compiler binary, Go toolchain, runtime module, and generated Go;
|
||||
- local project code built and executed by `himesan dev`; and
|
||||
- the user account, filesystem, environment, and other processes on the
|
||||
development workstation.
|
||||
|
||||
Template semantics become trusted source when built into an application;
|
||||
templates are not an untrusted-content sandbox. Someone allowed to edit one can
|
||||
execute ordinary Go through the application build and must receive the same
|
||||
trust as any other code contributor. Arbitrary or malformed template bytes
|
||||
remain adversarial input to compiler robustness while they are being inspected.
|
||||
|
||||
A handwritten `sando.Component` is a trusted output capability. It may write
|
||||
arbitrary bytes, change HTML parser context, recurse, block, panic, or perform
|
||||
side effects. Hime-generated components are independently checked for balanced
|
||||
HTML and may be inserted with `<?~` only at an HTML content boundary. The open
|
||||
Go interface does not extend that proof to handwritten implementations.
|
||||
|
||||
The `Trust*` constructors do not sanitize. They record that trusted application
|
||||
code accepts responsibility for the supplied bytes. `himesan check` emits
|
||||
best-effort lexical audit hints for direct constructor/type use visible inside
|
||||
`.sando` source; it is not Go type analysis, taint analysis, or a complete
|
||||
inventory of trust created transitively in handwritten Go.
|
||||
|
||||
## Untrusted inputs
|
||||
|
||||
- ordinary values supplied to generated components;
|
||||
- filenames and directory entries encountered during discovery;
|
||||
- stale or manually modified generated output;
|
||||
- missing, stale, or manually modified generated output;
|
||||
- browser requests reaching the development proxy;
|
||||
- child process output and health failures.
|
||||
- child-process output, exit behavior, and health failures; and
|
||||
- malformed template bytes from a repository being inspected, provided the
|
||||
template is not subsequently built and executed as trusted Go.
|
||||
|
||||
## Guarantees sought by v1
|
||||
## Demonstrated controls
|
||||
|
||||
- Context-sensitive escaping for supported HTML text, quoted attributes, URL attributes, and explicitly trusted script/style values.
|
||||
- Compilation failure for unsupported or ambiguous output contexts.
|
||||
- Dangerous normalized URL schemes fail rendering unless explicitly trusted.
|
||||
- Component calls cannot change the surrounding HTML parser context.
|
||||
- Dynamic `title` and `textarea` content uses a distinct RCDATA writer that escapes even `TrustedHTML`; trusted HTML cannot close those elements.
|
||||
- Writer failures propagate and partial output is visible to the caller as an error; applications can buffer when atomic responses matter.
|
||||
- Generation plans all outputs before atomic replacement, targets only owned files, preserves last-good output on failure, and follows neither symlinks nor nested-module traversal.
|
||||
- `generate` and `check` do not execute project code, invoke Go tooling, fetch dependencies, or alter `go.mod`.
|
||||
These are point-in-time implementation and test observations indexed to named
|
||||
commits in the evidence ledger, not continuous assurance.
|
||||
|
||||
- Untrusted dynamic output is accepted only in supported HTML text, quoted
|
||||
attribute, URL, and RCDATA contexts. Script and style interpolation requires
|
||||
an explicit `TrustedJS` or `TrustedCSS` capability.
|
||||
- Dynamic tag names, attribute names, unquoted values, event-handler values,
|
||||
style attributes, foreign SVG/MathML content, URL lists, `srcdoc`, meta
|
||||
refresh, malformed HTML, and ambiguous parser states are rejected.
|
||||
- Ordinary text and quoted attributes are escaped; `title` and `textarea` use
|
||||
an RCDATA writer that escapes every trusted wrapper as ordinary text.
|
||||
- Ordinary whole URL values are normalized and checked before any bytes are
|
||||
written. Schemes outside `http`, `https`, `mailto`, and `tel` fail unless a
|
||||
`TrustedURL` deliberately bypasses that check.
|
||||
- Writer errors and contract-violating short writes propagate to the caller.
|
||||
- All sources in one operation are parsed/context-checked/formatted in memory
|
||||
before the first output change. Each changed output is replaced atomically,
|
||||
and existing destinations lacking the generated-file ownership marker, plus
|
||||
symlink or non-regular destinations, are rejected. The marker prevents
|
||||
accidents; it is not authentication against a hostile local actor.
|
||||
- Recursive discovery skips VCS, vendor, symlink, nested-module, and detected
|
||||
filesystem boundaries. Explicit files are still subject to no-symlink and
|
||||
regular-file checks.
|
||||
- `generate` and `check` do not invoke the Go toolchain, fetch dependencies,
|
||||
execute project code, or edit `go.mod`. `himesan dev` is a separate command
|
||||
that intentionally does all of generate, build, and execute trusted project
|
||||
code.
|
||||
- The development proxy binds to a literal loopback address, validates Host
|
||||
authority, and checks Origin and Sec-Fetch-Site when those headers are
|
||||
present. These checks are hardening, not a user-authentication boundary. Its
|
||||
injected client is fixed and authorized with a hash rather than
|
||||
`unsafe-inline`.
|
||||
|
||||
Executable tests and their latest maintainer-observed results are indexed in
|
||||
[SECURITY_EVIDENCE.md](SECURITY_EVIDENCE.md).
|
||||
|
||||
## Important limits
|
||||
|
||||
### URLs
|
||||
|
||||
URL checking prevents disallowed or ambiguous schemes; it does not decide
|
||||
whether a destination is authorized or trustworthy. `https:` and relative URLs
|
||||
can still leave an origin, submit data, change a document base, or load active
|
||||
content depending on the element and attribute. Applications must validate
|
||||
destinations and apply tighter policy for sensitive sinks.
|
||||
|
||||
### Trusted raw values
|
||||
|
||||
`TrustedHTML`, `TrustedJS`, and `TrustedCSS` are intentional escape hatches.
|
||||
Their authors must preserve the surrounding HTML parser state, including
|
||||
container-closing and legacy parser-transition sequences. Prefer ordinary data,
|
||||
keep trust conversion beside its validator, and review each use manually.
|
||||
|
||||
### Rendering resources and failures
|
||||
|
||||
The runtime does not impose output-size, recursion, CPU, allocation, or time
|
||||
limits; recover panics; or make an arbitrary `io.Writer` transactional.
|
||||
Applications should render into a buffer when an all-or-error HTTP body matters
|
||||
and should apply their own request deadlines, bounded writers, input limits, and
|
||||
panic policy. A context is passed through components, but generated output does
|
||||
not automatically stop between writes when it is canceled.
|
||||
|
||||
The compiler likewise has no hard source-size, memory, or compile-time budget.
|
||||
Run it only against repositories whose resource use the caller is willing to
|
||||
accept.
|
||||
|
||||
### Filesystem concurrency
|
||||
|
||||
Discovery and generation defend against symlinks and non-regular files observed
|
||||
at their checks. They are not currently a security boundary against a hostile
|
||||
local actor racing path components between inspection and use. Run the compiler
|
||||
inside a trusted workspace and user account. Atomic replacement describes each
|
||||
file's visibility; a multi-file generation is not a filesystem transaction if
|
||||
a later replacement fails.
|
||||
|
||||
The watcher is a development convenience, not a filesystem-integrity monitor.
|
||||
It may miss adversarial changes engineered to preserve the metadata it samples.
|
||||
|
||||
### Development supervisor
|
||||
|
||||
Loopback is host-local, not user-local. The development supervisor has no user
|
||||
authentication boundary against another process/account on the workstation. It
|
||||
builds and executes project code with the user's inherited environment and may
|
||||
fetch dependencies according to the user's Go configuration. It is not a
|
||||
production proxy, public preview host, TLS terminator, deployment system, or
|
||||
safe runner for untrusted repositories.
|
||||
|
||||
The watcher scans configured trees and eligible HTML responses may be buffered
|
||||
up to 16 MiB for reload injection. The application and operating system retain
|
||||
responsibility for request, response, SSE, file-count, and process resource
|
||||
limits.
|
||||
|
||||
Development CSP rewriting is reload convenience, not production CSP
|
||||
validation. Process cleanup is best-effort; a deliberately detached descendant
|
||||
may outlive the process tree the supervisor can identify. Human-readable
|
||||
diagnostics may also contain filenames or child-tool output supplied by a local
|
||||
repository, so terminals and log consumers remain part of the trusted
|
||||
development environment.
|
||||
|
||||
## Non-goals
|
||||
|
||||
Templates are not a sandbox. A malicious template author can write malicious Go in a statement tag. Sandwich Hime does not validate business authorization, prevent unsafe application logic, make an arbitrary `io.Writer` transactional, or secure an application router/server. Trusted constructors are intentionally sharp tools and must remain conspicuous in review and `himesan check` reporting. A `TrustedHTML` fragment must be balanced and context-neutral; `TrustedJS` and `TrustedCSS` authors are responsible for excluding container-closing HTML sequences.
|
||||
Sandwich Hime does not:
|
||||
|
||||
The v1 HTML state machine is deliberately smaller than a browser parser. Any construct it cannot prove safe is rejected rather than guessed. Differential testing against Go `html/template` is a baseline, not a claim of byte-identical output or universal parser equivalence.
|
||||
- sandbox template authors or embedded Go;
|
||||
- sanitize arbitrary trusted HTML, JavaScript, CSS, or URLs;
|
||||
- provide application authentication, authorization, CSRF policy, CSP, routing,
|
||||
database security, TLS, caching, or production process isolation;
|
||||
- type-check all embedded Go during `himesan check` (the normal Go build/test
|
||||
remains required);
|
||||
- detect every dynamic or handwritten component cycle;
|
||||
- guarantee safety under hostile concurrent mutation of the workspace; or
|
||||
- replace independent review, browser testing, vulnerability response, or the
|
||||
consuming application's threat model.
|
||||
|
||||
## Principal attack classes
|
||||
## Open release work
|
||||
|
||||
Tests cover delimiter confusion, malformed HTML, quote/entity injection, event attributes, dangerous and obfuscated URLs, script/style termination, Unicode and NUL handling, component context breaks, import/source-map injection, CRLF and path behavior, symlinks, nested modules, stale outputs, interrupted/read-only writes, writer failures, component cycles, development-proxy exposure, CSP weakening, compression/content-length mistakes, and orphaned child processes.
|
||||
- broaden semantic and browser-parser differential testing;
|
||||
- execute the native Windows/macOS security and process-lifecycle matrix;
|
||||
- complete signed release provenance, checksums, and SBOM evidence;
|
||||
- test the confidential reporting and signing-key recovery procedures; and
|
||||
- close or explicitly accept every finding listed in the evidence ledger before
|
||||
assigning a supported release line.
|
||||
|
||||
@@ -0,0 +1,152 @@
|
||||
<!-- SPDX-License-Identifier: AGPL-3.0-only -->
|
||||
|
||||
# v1.0.0 launch initiative
|
||||
|
||||
Sandwich Hime v1 is a compatibility and evidence milestone, not a reason to
|
||||
accumulate features. The intended product is already visible: an HTML-first,
|
||||
ahead-of-time template engine for Go, typed generated components, a small
|
||||
HTTP-independent runtime, and an optional opinionated local development loop.
|
||||
|
||||
The private development initiative lives on `codex/v1-launch` in
|
||||
`sandwich-hime-dev`. Public releases never originate from that private history.
|
||||
|
||||
## Repository and publication topology
|
||||
|
||||
| Surface | Purpose | History and tags |
|
||||
| --- | --- | --- |
|
||||
| Private Gitea `sandwich-hime-dev` | development, working branches, private review records, and historical context | normal private history; no public release tags |
|
||||
| Public Gitea `sandwich-hime` | canonical sanitized source, contribution venue, module origin, releases, and signed tags | fresh reviewed publication history; authoritative `sando/vX.Y.Z` and `vX.Y.Z` tags |
|
||||
| GitHub `gamertan/sandwich-hime` | discoverability and a convenient sanitized source snapshot | no private refs, force-mirrors, workflows, contribution authority, release artifacts, or semver tags |
|
||||
|
||||
Each public update is exported through the exact committed allowlist, inspected,
|
||||
committed as a fresh public snapshot, and compared byte-for-byte with the
|
||||
reviewed export. GitHub receives that public tree only. It never receives the
|
||||
private repository or an indiscriminate Git mirror.
|
||||
|
||||
## Current readiness
|
||||
|
||||
At the 2026-08-12 v1 initiative baseline, the project is a strong engineering
|
||||
preview, but not yet a release candidate. Exact private/public commit mappings
|
||||
remain in the non-exported operational ledger.
|
||||
|
||||
### Demonstrated now
|
||||
|
||||
- race-enabled tests, vet, builds, deterministic generation, license checks,
|
||||
and sanitized-export tests pass on Linux;
|
||||
- the compiler module and nested `sando` runtime declare zero third-party Go
|
||||
module requirements;
|
||||
- generated/runtime compatibility uses a version-specific compile-time ABI
|
||||
marker with an incompatible-runtime regression;
|
||||
- owned-output, orphan, stale, symlink, nested-module, restrictive-permission,
|
||||
last-good, writer-error, and enumerated contextual-output cases are tested;
|
||||
- the development proxy is loopback-only, browser-origin hardened, and clears
|
||||
a dead selected upstream immediately; and
|
||||
- the security policy, threat model, and dated evidence ledger state both the
|
||||
demonstrated controls and the unresolved limits.
|
||||
|
||||
### Not demonstrated yet
|
||||
|
||||
- native Windows and macOS execution of the complete supported matrix;
|
||||
- a stable public API/CLI/schema snapshot and compatibility test;
|
||||
- systematic browser-parser and `html/template` differential testing;
|
||||
- a long semantic fuzz campaign beyond bounded no-panic smoke;
|
||||
- committed, reproducible comparative benchmarks and a predefined regression
|
||||
threshold;
|
||||
- real-browser SSE/reload/overlay evidence for `himesan dev`;
|
||||
- deterministic release artifacts, checksums, SBOMs, signatures, and tested
|
||||
signing/recovery procedures; or
|
||||
- clean direct and public-proxy installation of signed release tags.
|
||||
|
||||
## Milestone 1: contract freeze
|
||||
|
||||
Required before security/platform release-candidate work is declared complete:
|
||||
|
||||
- [ ] Decide and specify whether generic component function signatures are v1.
|
||||
- [ ] Inventory and freeze every exported `sando` symbol, trusted type,
|
||||
sentinel error, concrete error field, helper, and ABI marker.
|
||||
- [ ] Freeze CLI commands, exit-code meanings, diagnostic codes, JSON schemas,
|
||||
`himesan.json` schema, and generated provenance fields.
|
||||
- [ ] Specify nil/stringification behavior, supported HTML-context matrix,
|
||||
component trust boundary, URL semantics, and explicit unsupported cases.
|
||||
- [ ] Add machine-checked public API, CLI, diagnostic, schema, and generated
|
||||
output compatibility snapshots.
|
||||
- [ ] Define the v1 deprecation and security-support policy.
|
||||
|
||||
## Milestone 2: security and native-platform evidence
|
||||
|
||||
- [ ] Run the minimum supported Go line and the latest two stable Go lines on
|
||||
native Linux, macOS, and Windows hosts.
|
||||
- [ ] Prove identical generated bytes across those hosts and exercise native
|
||||
path, replacement, permission, race, process-tree, and watcher behavior.
|
||||
- [ ] Build a systematic differential corpus against Go's documented
|
||||
`html/template` safety baseline for overlapping supported contexts.
|
||||
- [ ] Parse representative outputs in real browsers and test structure/code
|
||||
invariants rather than only byte equality.
|
||||
- [ ] Extend semantic fuzzing across delimiters, HTML transitions, imports,
|
||||
paths, source maps, URL normalization, and filesystem operations.
|
||||
- [ ] Resolve or explicitly accept every open item in
|
||||
`SECURITY_EVIDENCE.md`; no accepted item may contradict a public guarantee.
|
||||
- [ ] Test delivery and reply through `security@sandwichhime.com`.
|
||||
- [ ] Define severity, advisory, retraction, and CVE-request handling.
|
||||
|
||||
## Milestone 3: measured performance and development UX
|
||||
|
||||
- [ ] Commit a synthetic, repository-owned benchmark corpus comparing
|
||||
equivalent typed views and output with `html/template`.
|
||||
- [ ] Define “no material regression” before measuring the release candidate;
|
||||
publish hardware, OS, Go version, commands, samples, allocations, and output
|
||||
equivalence with every result.
|
||||
- [ ] Test SSE reconnect, reload, diagnostic overlays, CSP changes, fragment/API
|
||||
exclusions, caching, and child cleanup in a real browser on supported hosts.
|
||||
- [ ] Remove any v1 development-supervisor guarantee that cannot be evidenced
|
||||
reliably instead of substituting prose for a test.
|
||||
|
||||
## Milestone 4: release rehearsal
|
||||
|
||||
- [ ] Make version validation identical in the CLI, generated headers, scripts,
|
||||
and release artifacts; reject ambiguous build metadata.
|
||||
- [ ] Build the candidate compiler at its candidate version and prove its
|
||||
committed outputs are current under that exact binary.
|
||||
- [ ] Produce deterministic archives/binaries, checksums, SBOMs, signatures,
|
||||
and source/build provenance from a clean sanitized canonical checkout.
|
||||
- [ ] Test release-key backup and two-person recovery for Gitea, domains,
|
||||
signing material, and publication instructions.
|
||||
- [ ] Make evidence gates validate content and commit identity rather than only
|
||||
the presence of non-empty files.
|
||||
- [ ] Rehearse runtime-first publication and rollback without creating public
|
||||
semver tags.
|
||||
|
||||
## Milestone 5: release candidates and final launch
|
||||
|
||||
1. Export and review the sanitized canonical release tree.
|
||||
2. Publish signed `sando/v1.0.0-rc.1`, then signed `v1.0.0-rc.1` from the same
|
||||
reviewed public Gitea commit.
|
||||
3. Verify documented installs through fresh `GOPROXY=direct` and
|
||||
`proxy.golang.org` caches on supported Go versions and native platforms.
|
||||
4. Run the complete evidence suite again from the exact public commit.
|
||||
5. Operate the official Sandwich Hime website on the RC runtime for a 14-day
|
||||
observation period with no unresolved Hime render, security, accessibility,
|
||||
or rollback regression. This is product dogfooding, not a dependency on EQL
|
||||
or another application's private repository.
|
||||
6. Fix findings in a new RC; restart the observation period when the affected
|
||||
boundary warrants it.
|
||||
7. Finalize the changelog, supported-version table, migration notes, release
|
||||
notes, legal/trademark review, checksums, SBOMs, and signatures.
|
||||
8. Publish `sando/v1.0.0` first and `v1.0.0` second. Never move a tag.
|
||||
9. Refresh the untagged GitHub discovery snapshot and point it to canonical
|
||||
Gitea releases and contribution channels.
|
||||
|
||||
## Explicitly deferrable after v1
|
||||
|
||||
Unless testing finds a release-blocking consequence, v1 need not include every
|
||||
possible context, hostile-local filesystem hardening, typed trust-flow analysis,
|
||||
complete dynamic cycle detection, an encrypted reporting key, or an external
|
||||
audit. Those limits must remain visible and must not be contradicted by
|
||||
marketing. New features do not outrank a small stable contract.
|
||||
|
||||
## Definition of confidence
|
||||
|
||||
“Ready for v1” means a reviewer can trace each promise to a stable public
|
||||
contract, executable evidence from supported native environments, and a signed
|
||||
artifact built from the exact canonical source. It does not mean perfect,
|
||||
invulnerable, or finished forever.
|
||||
Reference in New Issue
Block a user