gamertan/sandwich-hime
1
0
Fork 0
Code Issues Pull Requests Actions Releases 3 Activity

release: prepare Sandwich Hime v1 beta

Browse Source 
Publish the sanitized Beta 1 source candidate with version-stable generated provenance, classroom/evaluation support boundaries, provisional macOS support, signed-source release policy, and an exact candidate preflight.

Material implementation, drafting, and review were assisted by OpenAI Codex. Cole Speelman reviewed the public snapshot and accepts human responsibility for the contribution.

Signed-off-by: Cole Speelman <crspeelman@gmail.com>
This commit is contained in:
gamertan
2026-08-12 14:37:53 -04:00
parent 113c95c21e
commit b7a84054d7
22 changed files with 824 additions and 193 deletions
Download Patch File Download Diff File Expand all files Collapse all files
SECURITY.md
+31 -13
View File
@@ -2,21 +2,28 @@
# Security policy
Sandwich Hime is a public pre-1.0 source preview. Security reports are welcome
now, even though no version is currently designated as supported for production
use. The project would rather receive a careful early report than project
confidence it has not earned.
Sandwich Hime `v1.0.0-beta.1` is supported within a deliberately narrow
scope: learning, classroom projects, evaluation, and compatibility testing.
Security reports are welcome and receive best-effort maintainer assessment and
fixes while Beta 1 is the current prerelease. This is not production support,
an SLA, a fitness guarantee, or a promise that a fix will preserve beta APIs.
The community is invited to help find compatibility gaps, especially on macOS.
That invitation does not outsource security assurance. Maintainers retain
responsibility for vulnerability review, triage, remediation decisions,
advisories, and release decisions.
## Supported versions
| Version | Security status |
| --- | --- |
| Public `main` source preview | Best-effort assessment and fixes; interfaces may change |
| Versioned releases | None published yet |
| `v1.0.0-beta.1` and `sando/v1.0.0-beta.1` | Current evaluation/classroom prerelease once published; best-effort security assessment and fixes; interfaces may change |
| Public `main` | Development source; reports welcome, but no compatibility or production-support promise |
| Older prereleases | Superseded when a newer prerelease or final version is published; reports are still triaged to determine affected versions |
This table will name supported release lines once immutable compiler and runtime
versions are published. A pre-1.0 release is not a promise of API stability or
fitness for a particular application.
Beta support lasts until it is superseded or explicitly withdrawn in the
supported-version table and release notes. Published tags are immutable. A
security fix is issued as a new version, never by silently replacing a tag.
## Report a vulnerability privately
@@ -24,6 +31,12 @@ Email **security@sandwichhime.com**. Please do not put an undisclosed
vulnerability, working exploit, credential, secret, or personal data in a
public issue.
If that new mailbox rejects or bounces a message, retain the report and open a
canonical Gitea issue containing only the fact that the private security contact
failed. Do not include technical details or sensitive data. The maintainer will
publish a corrected private route. Ordinary usage, classroom, and macOS
compatibility reports that do not reveal a vulnerability may use a public issue.
Helpful reports include:
- the affected compiler/runtime version or exact commit;
@@ -40,7 +53,9 @@ ownership, backup, and recovery procedure have been tested.
## What to expect
These are best-effort targets for a founder-maintained project, not an SLA:
These are best-effort targets for a founder-maintained project, not an SLA.
They describe maintainer responsibilities; asking the community to test a beta
does not ask reporters to investigate or remediate it:
- acknowledge a report within 7 calendar days;
- provide an initial severity/scope assessment within 14 calendar days when a
@@ -118,8 +133,11 @@ an independent security audit, certification, or formal verification. Coverage
percentages, passing scanners, and a clean vulnerability database result are
evidence of specific checks—not proof that no vulnerability exists.
Release artifacts and tags are intended to carry signatures, checksums, an
SBOM, and exact source/build provenance. Those controls are publication gates
until the first versioned release is actually available.
Beta 1 publication requires signed annotated source tags, but may precede the
complete prebuilt-artifact and key-recovery system. Signed binaries, checksums,
an SBOM, reproducible archives, and complete source/build provenance are
release-candidate and final-v1 gates. Their absence from a source-only beta must
not be read as evidence of artifact authenticity beyond the verified tag and
canonical source.
This policy is practical project guidance, not legal advice.