Release Overview ================ Shyft distributes binary packages to simplify installation and deployment. These packages are provided as a convenience for users who prefer not to build the software directly from source. Because Shyft is used in operational environments where correctness and software integrity are critical, official releases are cryptographically signed and accompanied by provenance information. Release artifacts therefore include: * Signed package files * A provenance document (``PROVENANCE.txt``) * A detached signature of the provenance document * The public signing key These components allow users to independently verify: * Package integrity * Package authenticity * The relationship between the package and the source repository Release artifacts are published through distribution channels such as the GitLab package registry and static repository hosting. Only artifacts that have been produced through the documented release procedure and explicitly signed are considered official Shyft releases. Example Quick verification: :: gpg --verify PROVENANCE.txt.asc PROVENANCE.txt rpm -Kv *.rpm The release process, signing model, and verification procedures are described in: * :doc:`release-process` * :doc:`signing-keys` * :doc:`package-verification` Trust Model Summary ------------------- Shyft establishes trust through a layered and verifiable process: :: Maintainer identity ↓ OpenPGP signing key ↓ Signed source commits and tags ↓ Controlled and reproducible build ↓ Signed release artifacts and provenance ↓ User verification before installation Each step in this chain can be independently verified. Scope and Limitations --------------------- The release procedure described here is designed to provide a transparent, reproducible, and verifiable software distribution model. Shyft release artifacts are built from signed source tags using controlled build environments and are signed using hardware-backed keys. This minimizes the trust boundary and ensures that the release process can be audited and reproduced. However, this release process **does not by itself satisfy the full security requirements of operational technology (OT) environments** such as those used in critical energy-market infrastructure. Additional Controls Required in High-Security Environments ---------------------------------------------------------- In such environments additional controls are typically required, for example: * Dedicated trusted build infrastructure * Strict separation between development and operational networks * Mandatory vulnerability scanning of source dependencies * Static and dynamic code analysis * Reproducible build verification * Controlled artifact promotion between security zones * Independent security review and auditing These topics are further discussed in: :doc:`governance-and-infrastructure-control` Future Hardening Considerations -------------------------------- The current Shyft release process is designed to minimize the trust boundary and provide strong guarantees through controlled build environments and hardware-backed signing. The current Shyft project structure and team size do not require these additional controls, but they are documented here to support future evolution and adoption in more strictly governed environments. For environments with higher assurance requirements, additional hardening measures may be introduced in future versions of the release process. Examples include: * Restricting release tag signing to a dedicated set of approved release keys * Maintaining an allowlist of approved release-signing keys governed within the trusted domain * Maintaining an allowlist of approved commit-signing keys for contributors * Enforcing that commits and tags are signed by approved keys before being accepted into protected branches * Signing and version-controlling the allowlist(s) of approved keys * Requiring multi-party approval ("two-person rule") for release authorization * Separation of roles between contributors, build operators, and release authorities These controls strengthen the integrity of the source repository by ensuring that only contributions from explicitly approved identities are accepted. These mechanisms further strengthen the trust model by introducing explicit governance and separation of duties. However, they also require additional operational procedures and coordination, and are therefore not part of the current baseline release process. Trusted Build and Release Architecture -------------------------------------- Shyft uses a controlled and reproducible build pipeline where both the build process and the signing process are executed within infrastructure that is logically and physically controlled by the organization. A typical secure build pipeline consists of: * Controlled build hosts or build clusters, provisioned from audited base images * Strict separation between development environments and release infrastructure * Verified source inputs (signed commits and tags) * Deterministic or reproducible build procedures * Isolated artifact storage within the trusted domain * Hardware-backed signing using offline or access-controlled keys * Controlled promotion of artifacts between security zones The following conceptual flow illustrates this model: .. mermaid:: :align: center flowchart TD A["Signed source tag"] --> B["Controlled build environment"] B --> C["Reproducible build artifacts"] C --> D["Isolated artifact storage"] D --> E["Trusted signing host
Nitrokey"] E --> F["Signed release artifacts"] F --> G["Controlled distribution"] In this architecture: * The build environment is part of the trusted domain * The release process does not depend on external CI/CD systems * The signing process remains the primary trust anchor, operating within a reduced and auditable trust boundary * The entire pipeline can be audited, reproduced, and verified end-to-end Transitioning to this model reduces dependency on third-party infrastructure and minimizes the overall attack surface of the software supply chain. The Shyft release tooling and documentation support this architecture through: * Version-controlled build environment definitions (e.g., container image recipes) * Reproducible packaging procedures across supported platforms * Tooling for verification of build inputs and outputs * Documentation and examples for operating secure build infrastructure Organizations adopting Shyft in high-security environments are encouraged to implement this model, adapting it to their internal governance and regulatory requirements. Release Artifact Contents ------------------------- A typical release contains the following files: :: shyft-runtime-.rpm shyft-development-.rpm shyft-python-.rpm PROVENANCE.txt PROVENANCE.txt.asc shyft-release-key.asc The provenance file records metadata about the signing event and links the signed artifacts to the source revision and build procedure from which they were derived.