signing-tool 3.8.0

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

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

Do not pass the token literally (-t "$TOKEN") and do not store it inline in a config file — in both cases the secret is exposed (shell history, process listings such as ps / /proc/<pid>/cmdline, or plaintext on disk). The tool accepts curl-style references that keep the secret out of the command line; in order of preference:

• -t @/path/to/tokenfile (recommended) — 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
  

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

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

In a configuration file, reference the token by file instead of inlining it (an inline token = still works but 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

You can generate a config file with the config-init helper. Prefer -t @/path/to/tokenfile so it writes a token_file = reference (the secret stays out of the config); -t @- reads the token from stdin; a literal -t <token> is written inline and warns. The file is created owner-only (0600) on POSIX.

config-init -n test.ini -t @/run/secrets/jwt -a https://app.laavat.io/<CustomerName>/api/v1
signing-tool -n test.ini product getall

Quick test

For a quick one-off command without setting up a config file, pipe the token in via stdin (-t @-) so it stays out of your shell history and process listings:

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

Note: Some commands (escrow add, group add) are interactive and prompt for input. They cannot read the token from stdin — do not use -t @- / token = @- with them; supply the token via -t @/path/to/file or a token/token_file entry in a -n config file instead.

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.