A static artifact is a directory, not one executable. Recording only the source commit or only the homepage checksum leaves gaps: a missing image, stale alias, or changed download can survive unnoticed. A release manifest should enumerate every regular file.

Generate a stable list

Run the command from the artifact root so paths remain relative. Sort by path under a fixed locale:

cd public
find . -type f -exec sha256sum {} + | LC_ALL=C sort -k2 > ../release.sha256

The manifest is evidence about the artifact, so keep it outside the directory being measured unless the manifest itself is intentionally part of the release.

Verify after transport

On the destination, verify individual files:

cd /srv/www/site.new
sha256sum -c /path/to/release.sha256

This catches changed bytes and missing paths. It does not report unexpected extra files, so compare the destination file list too:

find . -type f | LC_ALL=C sort > destination.files
awk '{print $2}' /path/to/release.sha256 | LC_ALL=C sort > expected.files
diff -u expected.files destination.files

Add an aggregate digest for release records

Hash the manifest itself to produce a short identifier for logs and deployment records:

sha256sum release.sha256

The aggregate digest is only meaningful when the manifest generation rules are fixed: relative path form, sorting locale, hash algorithm, and whether generated metadata is included all belong in the procedure.

Do not confuse integrity with authenticity

SHA-256 proves that two byte sequences match. If an attacker can replace both the artifact and the manifest, the check does not establish who produced them. Artifact signing and trusted distribution are separate controls.

Sources