On Fri 2019-03-15 10:56:58 -0300, David Bremner wrote:
> Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:
>
>> sure, though i'd change the .sha256.asc to be a clearsigned file instead
>> of the current ASCII-armored OpenPGP message that it currently is (as
>> Adam suggested elsewhere in this thread).  And we can ditch the .sha256
>> itself, which doesn't seem to be doing any useful work.
>
> Err, wouldn't we be relying on the .sha256 file to be byte reproducible in
> perpetuity then? That seems to tie us to coreutils and reduce the
> options of users for verification, no?

i'm not sure i understand the question.  the .sha256 file is literally
the same output emitted to stdout by "gpgv --output - *.sha256.asc"
currently, right?

we certainly expect the sha256 digest of the tarball itself to be
reproducible in perpetuity.  So i think you're asking about the format
of the sha256sum listing…

AIUI, the output/input format of sha256sum is well-known, documented
[0], and stable.  The only weirdness is how it handles filenames with
newlines in them [1], but neither we nor the verifiers have to worry
about that for the types of files we're actually signing and verifying.

I'm sure several people on this list could cobble together a few lines
of "openssl dgst" and awk to perform the same effect as sha256sum in the
verification pipeline i sketched upthread.

      --dkg

[0] https://www.gnu.org/software/coreutils/manual/html_node/md5sum-invocation.html#md5sum-invocation
[1] https://github.com/openssl/openssl/issues/8493