Skip to content

pkg/*: publish checksums in both sha256sum and bare formats - #579

Open
thaJeztah wants to merge 2 commits into
docker:mainfrom
thaJeztah:shasums_both
Open

thaJeztah wants to merge 2 commits into
docker:mainfrom
thaJeztah:shasums_both

Conversation

@thaJeztah

Copy link
Copy Markdown
Member

pkg/*: use '.sha256sum' extension for checksums

commit 810d7bd introduced checksums for
static binaries. These checksums use the standard format produced by
sha256sum, which includes both the checksum and filename.

When adding checksum validation to the official docker:dind image repository,
there was discussion which format is most expected for a per-file checksum;
using the sha256sum format allows sha256sum -c <package>.sha256 to verify
the package, but there's also various situations where a bare checksum is
preferable.

Unfortunately, there are no strict conventions here; either option makes
sense. However, some further searching for precedents / conventions led
me to the containerd repository; containerd publishes checksums and also
uses the sha256sum format. However, those files use a .sha256sum file-
extension (see containerd@650a7e5).

Using .sha256sum as file-extension makes the format less ambiguous; it
also keeps a path open to publish both a bare checksum and a sha256sum
format. It also aligns with the conventions used by containerd, which gives
some consistency between related projects.

Given that we didn't ship a stable release yet with these checksums, we can
still make changes. This patch renames the checksumfiles to use .sha256sum
as file-extension.

updates 810d7bd
updates 7d994c2

pkg/*: add bare SHA256 checksum files

Publish bare hexadecimal digests in .sha256 files, alongside
.sha256sum files containing the standard sha256sum output.

This supports consumers expecting a bare checksum while preserving
compatibility with sha256sum --check.

commit 810d7bd introduced checksums for
static binaries. These checksums use the standard format produced by
sha256sum, which includes both the checksum and filename.

When adding checksum validation to the official docker:dind image repository,
there was discussion which format is most expected for a per-file checksum;
using the sha256sum format allows `sha256sum -c <package>.sha256` to verify
the package, but there's also various situations where a bare checksum is
preferable.

Unfortunately, there are no strict conventions here; either option makes
sense. However, some further searching for precedents / conventions led
me to the containerd repository; containerd publishes checksums and also
uses the `sha256sum` format. However, those files use a `.sha256sum` file-
extension (see [containerd@650a7e5]).

Using `.sha256sum` as file-extension makes the format less ambiguous; it
also keeps a path open to publish _both_ a bare checksum _and_ a sha256sum
format. It also aligns with the conventions used by containerd, which gives
some consistency between related projects.

Given that we didn't ship a stable release yet with these checksums, we can
still make changes. This patch renames the checksumfiles to use `.sha256sum`
as file-extension.

updates 810d7bd
updates 7d994c2

[containerd@650a7e5]: containerd/containerd@650a7e5

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Publish bare hexadecimal digests in `.sha256` files, alongside
`.sha256sum` files containing the standard sha256sum output.

This supports consumers expecting a bare checksum while preserving
compatibility with `sha256sum --check`.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
@tianon-sso

Copy link
Copy Markdown
Member

As I noted over in #578 (comment), IMO this is going too far -- at most we should trim the filename out of the .sha256 file, but I don't think it's really all that important (it's common enough either way that we're not too weird here and it's trivial to get the checksum alone).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants