Skip to content

Releases: Iron-Signal-Systems/engineering-standards

ISRAS 0.1.4 — Solo Developer Baseline

Choose a tag to compare

@kb2vhn kb2vhn released this 19 Jul 14:39
isras-v0.1.4
c9345d6

ISRAS 0.1.4 Release Notes

Release date: 2026-07-19

Assurance status: RELEASE CANDIDATE — SELF-VALIDATION REQUIRED

Release tag: isras-v0.1.4

Purpose

ISRAS 0.1.4 repairs the release-publication defects discovered during the first
formal publication attempt for the signed isras-v0.1.3 tag. It also carries
forward the hosted SSH signer-trust and evidence-retention corrections introduced
after the failed 0.1.2 consuming-project hosted run.

The signed isras-v0.1.3 tag remains immutable but was never published. Its exact
empty failed draft was independently verified and deleted. ISRAS 0.1.3 is not an
accepted release or project-adoption authority.

Publication repairs

This release candidate:

  • discovers releases through a complete paginated inventory that includes drafts;
  • rejects any existing draft or published release for the selected tag;
  • uploads each exact asset with gh release upload and never enables --clobber;
  • re-reads the exact draft by release ID after each upload;
  • accepts an ambiguous upload-command failure only when authoritative release-ID
    state proves the exact expected asset was uploaded;
  • inspects and deletes failed drafts only by the exact release ID created by the
    current invocation;
  • requires an authenticated ID-based absence check after cleanup;
  • rejects duplicate, altered, partial, or unexpected draft asset state; and
  • retains truthful cleanup evidence.

Exact release assets

A completed 0.1.4 release contains exactly:

isras-validator-linux-amd64
isras-project-framework.tar.gz
isras-contracts.tar.gz
provenance.json
SHA256SUMS
SHA512SUMS

Release completion

Release completion requires the exact signed 0.1.4 source commit, signed annotated
tag, deterministic six-asset build, read-only publication preflight, controlled
draft-first publication, complete remote metadata and downloaded-byte
verification, and final post-publication re-verification.

Adoption readiness

Publication is not project-adoption readiness. A neutral clean GitHub-hosted
consuming-project fixture must pin the exact published 0.1.4 release and pass the
complete reusable hosted workflow while retaining both required evidence trees.

Limitations

  • The release remains self-authored and self-validated.
  • No independent audit, certification, regulatory approval, or universal
    production-fitness claim is made.
  • The validator release artifact remains linux/amd64.
  • A later defect must be corrected through a later immutable release identity.

ISRAS 0.1.2 — Solo Developer Baseline

Choose a tag to compare

@kb2vhn kb2vhn released this 19 Jul 08:19
isras-v0.1.2
60c34c8

ISRAS 0.1.2 Release Notes

Release date: 2026-07-18

Assurance status: SELF-VALIDATED

Release tag: isras-v0.1.2

Purpose

ISRAS 0.1.2 establishes the first accepted project-initialization and reusable
hosted-validation boundary for the pinned-project architecture. It builds on the
0.1.1 release-consumption foundation by adding fail-closed initialization of
clean Go repositories, immutable caller and called-workflow identity, published-
validator digest binding, project-owned command execution, and retained runtime
evidence.

The release remains a solo-developer, self-validated assurance baseline. It does
not claim independent audit, certification, regulatory approval, or universal
production fitness.

Included boundaries

This release includes:

  • first project initialization through project-pin initialize for one explicitly
    selected accepted ISRAS release;
  • authority checks requiring the running executable to be the exact linker-bound
    validator artifact from the selected release before network or target authority
    is granted;
  • signed-tag, exact source-commit, six-asset, GitHub SHA-256, local SHA-256 and
    SHA-512, manifest, provenance, and reusable-workflow verification before any
    target publication;
  • one shared strict SSH/HTTPS GitHub-origin parser for initialization and project-
    command authorization;
  • canonical project pins, immutable caller workflows, stable timestamp-independent
    adoption evidence, and a non-mutating project-owned Go format checker;
  • atomic no-overwrite publication with complete idempotence, private temporary
    preparation, rollback reporting, and final exact-file and repository-identity
    verification;
  • rejection of dirty, partial, conflicting, tracked-evidence, symbolic-link,
    wrong-origin, unsafe-path, and executable-mode-drifted targets;
  • runtime validation evidence fixed to untracked .local/isras and rejection of
    tracked paths below that boundary;
  • immutable reusable hosted validation using the exact called workflow repository
    and SHA;
  • bootstrap verification of the release, download of the published validator,
    exact size and SHA-256/SHA-512 verification, and execution of repository,
    secret, pin, and project-command checks through that artifact;
  • retention of .local/isras workflow evidence through commit-pinned actions;
  • repository-wide hermetic Git test fixtures that do not inherit an operator's
    personal commit-signing or tag-signing policy; and
  • native Ubuntu Server validation plus official Arch Linux and Fedora Server
    userland validation within the documented evidence boundaries.

Exact release assets

The release contains exactly:

isras-validator-linux-amd64
isras-project-framework.tar.gz
isras-contracts.tar.gz
provenance.json
SHA256SUMS
SHA512SUMS

The output contains no additional release asset. Every non-manifest asset is
covered by both manifests. The project pin binds the final manifest bytes
separately to avoid self-referential manifest hashes.

Release identity and completion

Release completion requires all of the following to identify the same exact
source commit:

  1. stable VERSION value 0.1.2;
  2. verified signed release-source commit;
  3. successful pull-request and merged-dev validation;
  4. successful commit-mode and clean-clone release-mode validation;
  5. signed annotated local tag isras-v0.1.2;
  6. separately reviewed push of that exact tag object;
  7. deterministic production and local verification of the six assets;
  8. controlled draft creation and exact asset upload;
  9. remote metadata and downloaded-byte verification before publication;
  10. publication of the verified draft; and
  11. final remote metadata and downloaded-byte verification after publication.

A stable source declaration, branch name, tag name, or GitHub Release record is
not sufficient by itself.

Project adoption status

After publication, a clean Go project may adopt this exact release only through
the accepted initialization command executed by the exact published validator.
The initializer verifies the selected release before writing the canonical pin,
caller workflow, format checker, and adoption evidence. Local and hosted
validation then use the same immutable release identity.

Before publication of the exact signed tag and verified six-asset release, this
source candidate does not authorize modification of a consuming project.
isras-v0.1.1 remains immutable and is not a complete adoption release because
its framework archive does not contain the reusable project-validation workflow.

Known limitations

  • The release is self-authored and self-validated.
  • The Go profile is the first supported reference profile; other language
    profiles require their own accepted contracts and tooling.
  • Initialization targets a clean, explicitly selected repository and does not
    migrate partial or conflicting prior adoption.
  • Project-upgrade application remains outside this release boundary.
  • Container-userland validation does not establish complete native kernel,
    systemd, SELinux, firewall, hardware, deployment, or recovery compatibility.
  • Publication verification establishes exact release identity and bytes; it does
    not establish suitability for every consuming project or operating environment.

Recovery and immutability

Published tags, assets, manifests, and provenance are immutable. A defect in
0.1.2 must be corrected by a later release rather than replacing bytes under
the existing identity.

Recovery consists of checking out the signed release tag or exact source commit,
rebuilding or reacquiring the declared assets, and verifying their complete
identity and digests. Private validation, build, command, adoption, and
publication evidence under .local/ is intentionally excluded from the signed
source tree and should be retained according to operational policy.

ISRAS 0.1.1 — Solo Developer Baseline

Choose a tag to compare

@kb2vhn kb2vhn released this 18 Jul 18:13
isras-v0.1.1
f886c35

ISRAS 0.1.1 Release Notes

Release date: 2026-07-18

Assurance status: SELF-VALIDATED

Release tag: isras-v0.1.1

Purpose

ISRAS 0.1.1 establishes the first complete release-production and
release-consumption foundation for the pinned-project architecture. It adds
machine-readable project declarations, exact artifact verification,
deterministic release artifacts, isolated external-target validation, bounded
project-declared command execution, and controlled GitHub Release publication.

The release remains a solo-developer, self-validated assurance baseline. It does
not claim independent audit, certification, regulatory approval, or universal
production fitness.

Included boundaries

This release includes:

  • the ISRAS Engineering Standards emblem as a repository documentation and
    identity asset, rendered from the README but excluded from the exact six-file
    downloadable release artifact inventory;
  • portable fail-closed local release-tag discovery that accepts the expected
    pre-tag absence while distinguishing existing refs, malformed output, and Git
    execution failures;
  • the language-neutral ISRAS core and the first Go reference profile;
  • the strict v1 .isras/project.json declaration and semantic validator;
  • read-only project-pin validation and inspection;
  • exact published-release acquisition and verification using the signed tag,
    source commit, GitHub release record, SHA-256, SHA-512, both checksum manifests,
    and v1 provenance;
  • deterministic production of the exact six-file release asset set;
  • validator release identity bound through linker values rather than target-owned
    metadata;
  • explicit external repository selection through global --repo handling;
  • one exact project-declared command selected by name and invoked as an exact argv
    without an implicit shell;
  • credential-minimized process environments, timeout and output budgets, Linux
    process-group termination, repository-state drift detection, and private
    redacted command evidence;
  • controlled draft-first GitHub Release publication with remote asset metadata
    checks, bounded re-downloads, full byte verification before and after
    publication, and safe cleanup of only the exact incomplete draft;
  • disabled legacy publication paths that could create an assetless release, push
    tags, or move main without the new verifier;
  • native Ubuntu Server 22.04 and 24.04 validation plus official Arch Linux and
    Fedora Server 43 and 44 userland validation;
  • release-workflow output censoring and repository secret-scanner regression
    coverage.

Exact release assets

The initial release contains exactly:

isras-validator-linux-amd64
isras-project-framework.tar.gz
isras-contracts.tar.gz
provenance.json
SHA256SUMS
SHA512SUMS

The output contains no additional release asset. Every non-manifest asset is
covered by both manifests. The project pin binds the final manifest bytes
separately to avoid self-referential manifest hashes.

Release identity and completion

Release completion requires all of the following to identify the same exact
source commit:

  1. stable VERSION value 0.1.1;
  2. verified signed release-source commit;
  3. successful pull-request and merged-dev validation;
  4. successful commit-mode and clean-clone release-mode validation;
  5. signed annotated local tag isras-v0.1.1;
  6. separately reviewed push of that exact tag object;
  7. deterministic production and local verification of the six assets;
  8. controlled draft creation and exact asset upload;
  9. remote metadata and downloaded-byte verification before publication;
  10. publication of the verified draft;
  11. final remote metadata and downloaded-byte verification after publication.

A stable source declaration, branch name, tag name, or GitHub Release record is
not sufficient by itself.

Project adoption status

This release provides the declaration, validation, artifact, execution, and
publication foundation required by future project adoption. It does not yet
provide accepted project initialization or complete consuming-project adoption.

Until the initialization boundary passes its own hostile tests and acceptance
gates, a project shall not:

  • create a provisional .isras/project.json pin;
  • copy validator source from Engineering Standards;
  • use the deprecated project-validator exporter for initialization;
  • pin dev, main, or another floating branch;
  • invent artifact hashes or release identity;
  • treat publication of 0.1.1 alone as modification authority.

Known limitations

  • The release is self-authored and self-validated.
  • Project initialization is not implemented or accepted.
  • Complete existing-project adoption is not implemented or accepted.
  • Reusable hosted validation is not implemented.
  • Upgrade-plan application is not implemented.
  • The Go profile is the first supported reference profile; other language
    profiles require their own accepted contracts and tooling.
  • Container-userland validation does not establish complete native kernel,
    systemd, SELinux, firewall, hardware, deployment, or recovery compatibility.
  • Publication verification establishes exact release identity and bytes; it does
    not establish suitability for every consuming project or operating environment.

Recovery and immutability

Published tags, assets, manifests, and provenance are immutable. A defect in
0.1.1 must be corrected by a later release rather than replacing bytes under
the existing identity.

Recovery consists of checking out the signed release tag or exact source commit,
rebuilding or reacquiring the declared assets, and verifying their complete
identity and digests. Private validation, build, command, and publication evidence
under .local/ is intentionally excluded from the signed source tree and should
be retained according to operational policy.

ISRAS 0.1.0 — Solo Developer Baseline

Choose a tag to compare

@kb2vhn kb2vhn released this 17 Jul 09:00
isras-v0.1.0
96d0bba

ISRAS 0.1.0 Release Notes

Release date: 2026-07-17
Assurance status: SELF-VALIDATED
Release tag: isras-v0.1.0

Purpose

ISRAS 0.1.0 is the first practical release of the Iron Signal Repository
Assurance Standard Solo Developer Baseline. It provides a usable assurance
foundation for a single developer without discarding the broader long-term
ISRAS vision.

Included baseline

This release includes:

  • signed-commit and signed-release-tag requirements;
  • exact repository and commit identification;
  • repository-owned Go validation with formatting, vet, tests, builds, module
    consistency, module integrity, and reachable-vulnerability checks;
  • repository-owned secret detection with censored output, deterministic finding
    identifiers, redaction guidance, and bounded exceptions;
  • a local *.log for every validation failure;
  • context-specific remediation commands labeled by effect;
  • safe commit-signature diagnostics that do not automatically recommend history
    rewriting;
  • repository-owned clean-clone release validation of the exact pushed commit;
  • preservation of the earlier ISRAS v1 through v3 development history through
    archive references and local recovery artifacts.

Supported platforms

The default support profile is:

  • Arch Linux as the primary development platform;
  • Ubuntu Server LTS releases that remain within upstream support;
  • Fedora Server releases that remain within upstream support.

Projects adopting ISRAS may declare additional or narrower platform support.

Validation and release completion

Release completion requires all of the following against the exact release
commit:

  1. complete commit-mode validation;
  2. successful GitHub pull-request validation;
  3. successful clean-clone release-mode validation from canonical origin;
  4. a signed annotated isras-v0.1.0 tag;
  5. verification that the local and remote tag resolve to the exact tested commit.

The release tooling creates no tag automatically.

Recovery and rollback

This release does not perform database migrations, operating-system changes, or
automatic deployment actions. Recovery consists of checking out a previously
trusted signed tag or commit and rebuilding the repository-owned tooling from
that source.

Before replacing or removing a working copy, preserve any required private
validation evidence under .local/validation/. That directory is intentionally
ignored by Git and is not part of the signed source tree.

Known limitations

  • The release is self-authored and self-validated.
  • It does not claim independent human review, certification, regulatory
    compliance, or suitability for every production environment.
  • Vulnerability results reflect the Go toolchain, dependency graph, and
    vulnerability data available at validation time.
  • Platform declarations do not replace project-specific deployment,
    compatibility, backup, recovery, and operational testing.

ISRAS v1.0.1

Choose a tag to compare

@kb2vhn kb2vhn released this 16 Jul 00:47
isras-v1.0.1
c379417

ISRAS v1.0.1 formal acceptance

Decision status: ACCEPTED
Decision time: 2026-07-16T00:40:00Z

Repository:
Iron-Signal-Systems/engineering-standards

Accepted source commit:
c379417

Required source branch:
dev

Release branch:
main

Accepted predecessor:
isras-v1.0.0

Accepted predecessor source commit:
f9655dd

Validation gate:
tools/validation/phase-gates/validate_isras_v1_candidate.sh

Environment:
Native Arch Linux validation plus GitHub-hosted Ubuntu, macOS, and Windows validation

Runner identity:
John Wood kb2vhn@gmail.com; jwood on local Arch Linux validation workstation

Validation outcomes:

  • Historical checkpoint validation: PASS
  • Repository policy validation: PASS
  • Source-manifest verification: PASS
  • Portable validation: PASS
  • Integration-tool validation: PASS
  • Fresh-clone and remote-completeness validation: PASS
  • ISRAS v1 candidate gate: PASS
  • Hosted Ubuntu validation: PASS
  • Hosted macOS validation: PASS
  • Hosted Windows PowerShell validation: PASS
  • Correctness result: PASS
  • Resource observation: NOT_APPLICABLE
  • Performance budget: NOT_EVALUATED
  • Security findings: NOT_EVALUATED
  • Operational readiness: NOT_EVALUATED

Hosted validation:

  • Self-validation run: 29461113082
  • Native OS matrix run: 29461114090

Acceptance evidence:
SHA-256: f2dda939b8c401c9e96fc35402291e50ed9f774eb5783eb3a41aec117a301cab
Location: https://github.com/Iron-Signal-Systems/engineering-standards/releases/download/isras-v1.0.1/isras-v1.0.1-acceptance-evidence.tar.gz

Warnings:

  • Independent second-person human review was unavailable.
  • Security findings were not evaluated by this acceptance campaign.
  • Operational production readiness was not evaluated.

Non-claims:

  • Acceptance does not prove adopting products are production-ready.
  • Acceptance does not prove adopting repositories are vulnerability-free.
  • Acceptance does not replace product-specific operational, security, legal,
    accessibility, privacy, or regulatory acceptance.

Completion boundary:
Acceptance is complete only when the canonical remote confirms that this signed
annotated tag, refs/heads/main, and refs/heads/dev all resolve to the accepted
source commit; the evidence asset is published at the recorded location; and
the isras-* tag namespace remains protected.