signing-tool 3.7.1

Laavat Signing Solution CLI Tool

Laavat Signing Solution CLI Tool

ℹ️ Example client — This is Laavat's reference signing client. It is provided as-is; you are responsible for evaluating its suitability and security for your own production environment before relying on it. Releases are published with verifiable provenance (see Verifying the download).

The signing-tool package provides the Laavat Signing Solution command-line client. It supports client registration, product management, image signing, secrets management, and more via the SaaS API.

Installation

Install from PyPI when released:

pip install signing-tool

Install from source during development:

cd clients/python3
python3 -m pip install .

Verifying the download

Releases on PyPI are published with PEP 740 digital attestations, signed via Sigstore. The attestation provides a publicly verifiable, transparency-logged link proving that a given signing-tool artifact was built and published by Laavat's official GitLab CI pipeline for this project — it lets you detect a tampered or substituted artifact before you run it.

You can see the attestation on the release's PyPI page (under the file's "Provenance" / "Verified details"). To verify a downloaded artifact yourself:

python3 -m pip install pypi-attestations
# Verify a published file directly against PyPI (downloads the file and its
# attestation for you); pass the exact released filename after "pypi:":
python3 -m pypi_attestations verify pypi \
    --repository https://gitlab.com/laavat/laavat-product/architecture/dist \
    pypi:signing_tool-<version>-py3-none-any.whl

A successful verification confirms the artifact's provenance (who built it, from which repository). What it does not do: it is not a guarantee about the contents of the code (it is provenance, not a security audit of the source).

The verify command above works against production PyPI. (Attestation verification of TestPyPI artifacts is not supported by the current pypi-attestations release.)

A CycloneDX Software Bill of Materials (SBOM) listing the package's dependencies is produced for each release: it is bundled inside the source distribution (.tar.gz) as sbom.json, and is also published as a per-version build artifact (signing-tool-sbom.json) by the release pipeline.

Quick Start

Display help:

signing-tool --help

Secure token input

Passing the token directly with -t "$TOKEN" exposes it in your shell history and in process listings (ps, /proc/<pid>/cmdline). To avoid this, the -t option accepts curl-style references that keep the secret out of the command line:

• -t @- — read the token from stdin:

  printf '%s' "$TOKEN" | signing-tool -c -t @- -a https://app.laavat.io/<CustomerName>/api/v1 product getall
  

• -t @/path/to/tokenfile — read the token from a file (the tool warns if the file is group/world-readable; use chmod 600):

  signing-tool -c -t @/run/secrets/jwt -a https://app.laavat.io/<CustomerName>/api/v1 product getall
  

In a configuration file, reference the token by file instead of inlining it (inlining is deprecated and warns on use):

[service]
url = https://app.laavat.io/<CustomerName>/api/v1
token_file = /run/secrets/jwt

These forms integrate cleanly with CI secret managers, which expose secrets as files or on stdin. TLS verification is on by default; --skipssl disables it and is intended for local development only.

A leading @ is interpreted as a stdin/file reference (the curl convention). OAuth2/JWT tokens never start with @, but if you ever need a literal token that does, escape it as \@token.

Recommended usage

Supply the token without exposing it on the command line (see Secure token input), and keep the rest of the settings in a configuration file referenced with -n.

A configuration file that references the token by file (the token itself is never stored in the config):

# test.ini
[service]
url = https://app.laavat.io/<CustomerName>/api/v1
token_file = /run/secrets/jwt

signing-tool -n test.ini product getall

Or pass everything on the command line, reading the token from stdin:

printf '%s' "$TOKEN" | signing-tool -c -t @- -a https://app.laavat.io/<CustomerName>/api/v1 product getall

TLS verification is on by default. --skipssl disables it and is for local development only.

Configuration file

The config file has a single [service] section:

Key	Description
url	API address, e.g. https://app.laavat.io/<CustomerName>/api/v1
token_file	Path to a file containing the token (preferred — keeps the secret out of the config)
token	The token. token = @/path/to/file reads it from a file; an inline literal token is deprecated and warns on use
skipssl	True disables TLS verification (local development only); defaults to False

A config-init helper exists to generate a config file, but it currently takes the token as a command-line argument; for production use, write the config file yourself with a token_file reference (or supply the token via stdin). Hardening of config-init is planned for a future release.

Quick test (less secure)

For a throwaway local test you can pass the token literally. Avoid this outside local experimentation — the token is visible in shell history and process listings:

signing-tool -c -t "$TOKEN" -a https://app.laavat.io/<CustomerName>/api/v1 product getall

Example Signing Commands

HAB image signing with a config file:

signing-tool -n test.ini imagesigning add SignHABIMG -P <product-id> --operid <operator-id> -p <payload>

OCI signing, reading the token from stdin:

printf '%s' "$TOKEN" | signing-tool -c -t @- -a https://app.laavat.io/<CustomerName>/api/v1 imagesigning add SignOCI -P <product-id> --operid <operator-id> -A <artifact>

Requirements

• Python 3.8 or newer
• SigningService — The signing-tool CLI depends on the SigningService API client library. This is automatically installed when you install signing-tool from PyPI

Packaging

This package is configured for PyPI distribution using pyproject.toml and setuptools. Read the pyproject.toml file for package metadata and published package configuration.