What an attestation publishes

An attestation exists to be shared. Its value is that someone else — a customer, an auditor, a downstream consumer — can inspect it and decide whether to trust your artifact. That usefulness and its privacy cost are the same property: the more an attestation says about how a build ran, the more it says about the machine it ran on.

This page describes exactly what SALT records, who can read it, and how to control both.

The attestations registry is readable by anyone

When SALT uploads a signed attestation to the Xygeni attestations registry, reads are anonymous. This is deliberate: a third party verifying your artifact is not necessarily a Xygeni subscriber, and requiring them to authenticate would defeat the purpose of publishing provenance at all. Uploads are authenticated; retrieval and search are not.

Two consequences worth planning around:

• Anyone who has an entry's digest can download the full attestation, and search by artifact digest is open as well.

• There is no delete operation. An uploaded attestation cannot be retracted by you or by us. Treat every upload as permanent and public.

If that is not what you want for a particular build, do not upload it — see Choosing what to publish below.

What the predicates contain

Beyond the artifact digests in the statement's subject, two SALT predicates describe the build machine and the source revision.

Environment predicate (xygeni.io/attestations/environment/v1)

Field	Contains
hostname	The build machine's host name
username	The account the build ran as
shell	The SHELL value
os	Kind, architecture and version
variables	Environment variables, filtered as described below
timestamp	When the predicate was generated

On a hosted CI runner these are generic (runner, an ephemeral host name). On a developer workstation they identify a person's machine. If you generate attestations locally, that is worth knowing before you upload.

Git predicate (xygeni.io/attestations/git/v1)

Field	Contains
repositoryURL	The remote the working copy came from, credentials removed
commitHash, treeHash, parentHashes	The revision and its ancestry
refs	Branches and tags pointing at the commit
commitMessage	Subject and body, on one line, credentials masked
author, authorEmail, commitDate	Commit authorship
committer, committerEmail, committerDate	Committer, when it differs from the author
signature	Commit signature status, signer and key ids, when signed

Commit identity is published as-is. It is not treated as a leak: authorship is the substance of source provenance, and it is already visible to anyone who can read the repository.

What is filtered, and what is not

SALT removes credentials from the places they are most likely to appear:

• Environment variables. Variables are dropped when their name appears in a shipped list of known credential variables, or when the name contains TOKEN, PASSWORD, SECRET, CRED or KEY. Values that survive have any user:password@ credentials in URLs masked, and are truncated. If the list of known credential variables cannot be read, no variables are recorded at all rather than recording them unfiltered.

• The repository URL. A checkout token embedded in the remote — as CI systems routinely leave behind — is removed. A remote that cannot be parsed is masked rather than published.

• The commit message. Recognisable credentials are masked, keeping the rest of the message intact.

Filtering is best effort, and you should not rely on it alone. It recognises credentials by well-known formats and by the words around them, which means:

• A variable holding a secret under a name none of the rules match is recorded.

• An opaque token with no distinctive format and no adjacent keyword is not recognised.

• A secret pasted into a commit message in an unusual form may survive.

The reliable control is not to expose the secret to the build in the first place, and to review what a predicate contains before publishing from an environment that holds credentials.

Choosing what to publish

Attestation generation and publication are separate steps, so you can keep one without the other.

• --no-upload generates and signs the attestation but does not send it to the registry. You keep the signed file and can publish it wherever you choose, or not at all.

• --no-result-upload suppresses the upload of build and provenance results to the Xygeni platform.

To inspect an attestation before deciding, generate it with --no-upload and read the predicate; the payload is base64-encoded JSON inside the envelope. salt registry get retrieves an entry already in the registry.

Presence in the registry is not proof of authenticity

An attestation is trustworthy because its signature verifies against a key or certificate chain you accept — never because it was found in a registry. The registry stores and indexes what it is given; it does not vouch for it.

When you verify, verify the signature:

• Check the DSSE signature against keys you supply, or against a certificate chain you have validated.

• Confirm the subject digests match the artifact you actually hold.

• Confirm the predicateType is the claim you intended to check.

salt verify performs these checks. Do not substitute "the attestation is in the registry" for any of them.