Signing Keys
============

Shyft release packages are signed using an OpenPGP signing key.

The private signing key is stored on a Nitrokey hardware token,
ensuring that the private key material cannot be extracted from the
signing device.

Key generation, storage, and operational procedures are defined in:

:doc:`../security/identity/gpg-ssh-keys`

The Shyft release signing key was rotated on 2026-04-02.
Releases before this date are signed with the previous key.
Both keys are published for verification purposes.

Release Signing Key
-------------------

File: `tools/release/shyft-release.pub`

Fingerprint:

::

    CFFE BAE1 B25B AD34 C72A  2565 4A12 4000 37DA B695

User ID:

::

    Sigbjørn Helset <sigbjorn.helset@gmail.com>


Previous Release Signing Keys
-----------------------------

Fingerprint:

::

    CBBC EF9B 3866 DFB1 883F 92EF CA6E CA12 FA40 8123

User ID:

::

    Sigbjørn Helset <sigbjorn.helset@gmail.com>

Used until: 2026-04-02

Status: Deprecated (no longer in use for new releases)


Public Key Distribution
-----------------------

The public key is distributed with each Shyft release and is also available
in the repository.

Users should verify the key fingerprint before trusting the key.

Key Usage
---------

In the current open-source Shyft governance model, release artifacts
are signed by a maintainer-controlled OpenPGP key that is also
used to sign repository commits and tags.

This establishes a verifiable trust chain:

::

    Maintainer identity
        ↓
    OpenPGP key (published fingerprint)
        ↓
    Signed commits and tags
        ↓
    Signed release artifacts

In hardened or higher-assurance environments, a dedicated release-signing key is recommended,
separated from personal development keys and operated under stricter governance.

Key Rotation
------------

If the release signing key changes in the future, the new key will be
documented in the repository and announced in the release notes.

Security Model
--------------

The current Shyft open-source release model assumes that trusted maintainers
control both the signed repository history and the release signing process.

Organizations requiring stricter separation of duties are encouraged to:

- Use dedicated release-signing keys
- Enforce hardware-backed key storage
- Apply dual control for signing operations
- Maintain independent verification pipelines

See:

:doc:`../security/index`