SOW v0.4.0

Mon, 24 Aug 2026 00:00:00 +0000

SOW 0.4.0 is an integrity and recovery release for Managed repositories. It makes the deep checker’s I/O contract explicit, prevents RPM trust from being assembled across unrelated keys, adds an audited way to correct mutable publication-target settings, and closes the remaining v0.3 migration and interrupted-publication gaps.

Plain repository behavior and the public pool/ + dists/ layout do not change.

Upgrade from 0.3

Migrate every v0.3 Repository explicitly

Stop all Workspace writers, back up the Workspace, install 0.4.0, and run sow repo migrate REPOSITORY once for each Repository before ordinary reads or writes. The migration is explicit and one-way; do not reopen a migrated database with SOW 0.3.

SOW v0.2.0

Sat, 08 Aug 2026 00:00:00 +0000

SOW 0.2.0 is a self-contained RPM and DEB repository manager from Pigsty. Release artifacts target Linux and macOS as single Go executables.

Two operating modes

Plain mode indexes RPM and DEB files already present at one directory’s top level:

sow create /srv/repo

It writes repodata/, Packages, and Packages.gz in place. Plain mode has no Workspace, state database, generations, or DEB Release signing.

Tutorials

Mon, 01 Jan 0001 00:00:00 +0000

Each tutorial starts from a new workspace. Commands are intended to be run in order; replace uppercase placeholders and package paths for your environment.

If you have not installed SOW yet, start with Installation and Quick Start. The tutorials below cover the managed repository path.

Build a YUM Repository

A managed RPM repository with per-architecture views, noarch projection, debuginfo filtering, version limits, and a working dnf client configuration.

Build an APT Repository

A managed DEB repository with a Debian-style pool, by-hash indexes, and a deb822 client configuration.

Features

Mon, 01 Jan 0001 00:00:00 +0000

SOW has two isolated execution paths. Plain mode is a stateless rebuild of one directory; Managed mode records package membership and immutable repository generations in a workspace. Neither path silently adopts state from the other.

Capability matrix

Capability	Plain	Managed
RPM and DEB metadata	yes	yes
Mixed RPM + DEB operation	one directory	one Repository, separate Dists
Persistent membership and generations	no	yes
Per-architecture views and neutral packages	no	yes
`exclude` and version `limit` policy	no	yes
Metadata signing	no	RPM and DEB
RPM package signing	`--sign-with`	`never`, `fill`, `always`
Transaction journal and recovery	rerun `create`	workspace, Repository, publication
Queryable operation log and JSONL export	no	yes
Publication targets	no	filesystem and R2

SOW parses packages and renders metadata in-process. It does not invoke createrepo_c, dpkg-scanpackages, reprepro, or modifyrepo_c. RPM package signing is the exception: it needs the host rpm command and GPG environment because it rewrites package payloads.

Sign Your Repository

Mon, 01 Jan 0001 00:00:00 +0000

SOW has two independent signing paths:

Path	Output	Client control
RPM metadata	`repodata/repomd.xml.asc`	`repo_gpgcheck=1`
APT metadata	`InRelease` and `Release.gpg`	`Signed-By`
RPM package body	embedded RPM signature	`gpgcheck=1`

APT trusts package hashes through the signed Release; SOW does not re-sign DEB package bodies. Start with metadata signing. Add RPM package signing only when you own the signing policy for those package bytes.

1. Create a dedicated key

The commands below create an unencrypted example key. Use a protected key and a passphrase reference for production; see the configuration reference.

Signing Model

Mon, 01 Jan 0001 00:00:00 +0000

There are two different questions a client can ask about a repository, and SOW answers them with two separate mechanisms. Confusing them is the most common source of “I signed it but dnf still complains”, so this page starts by pulling them apart.

Two independent trust chains

	Metadata signing	RPM package signing
Question answered	“Is this index really from you, and unmodified?”	“Is this `.rpm` file really from you?”
Configured by	`signing.rpm.metadata`, `signing.deb.metadata`	`signing.rpm.packages`
Produces	`repodata/repomd.xml.asc`, `InRelease`, `Release.gpg`	an OpenPGP signature embedded in the package
Changes package bytes	no	yes
Client setting	dnf `repo_gpgcheck=1`, apt `Signed-By`	dnf `gpgcheck=1`
Available in Plain mode	no	yes, via `create -S KEY`

They are configured separately and can be used separately. Metadata signing alone is usually the right starting point: it authenticates the whole index in one place and requires no change to the packages you received from upstream.

sow show

Mon, 01 Jan 0001 00:00:00 +0000

sow show resolves one package reference in the selected Repository and prints the complete Package Object. It is read-only and takes no write lock.

Synopsis

sow show PACKAGE [-C|--workdir DIR] [-r|--repo NAME] [-d|--dist NAME]... [--json]

Flag	Meaning	Default
`-C, --workdir DIR`	Workspace discovery start directory	current directory
`-r, --repo NAME`	Select a Repository	selection rules
`-d, --dist NAME`	Narrow candidates to these Dists; repeatable	Repository scope
`--json`	Wrap the result in the `sow.cli/v1` envelope	false

Package reference

PACKAGE accepts a sha256:<hex> content identity, canonical rpm:<NEVRA> or deb:<name>=<version>:<arch> coordinate, full package filename, or bare binary name. See Package References for the exact grammar.

sow check

Mon, 01 Jan 0001 00:00:00 +0000

sow check is the deep read-only gate for a managed Repository. It hashes bytes, validates state, reconstructs expected views, and verifies declared signatures. It never repairs, builds, recovers an Operation, or takes the write lock.

Synopsis

sow check [-j|--jobs N] [-C|--workdir DIR] [-r|--repo NAME] [-d|--dist NAME]... [--json]

Flag	Meaning	Default
`-j, --jobs N`	Parallel verification workers; at least `1`	logical CPU count
`-C, --workdir DIR`	Workspace discovery start directory	current directory
`-r, --repo NAME`	Select a Repository	selection rules
`-d, --dist NAME`	Verify named Dists; repeatable	all Dists
`--json`	Emit the `sow.cli/v1` envelope	false

Verification layers

In steady state, the checker reports nine ordered layers:

signing on SOW

SOW v0.4.0

Upgrade from 0.3

SOW v0.2.0

Two operating modes

Tutorials

Features

Capability matrix

Sign Your Repository

1. Create a dedicated key

Signing Model

Two independent trust chains

sow show

Synopsis

Package reference

sow check

Synopsis

Verification layers