[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#932943: Missing SHA512 and gpg signature



On 04/08/2019 17:29, Bastian Blank wrote:
> On Sat, Aug 03, 2019 at 03:06:39PM +0100, Chris Boot wrote:
>> - Which checksums should we include? Our Apt repos use MD5 and SHA-256,
>> and our ISOs use MD5, SHA-1, SHA-256 and SHA-512. I'd be inclined to
>> suggest SHA-256 and SHA-512 only, personally.
> 
> Only one of them.  And I would go directly to SHA3 for new stuff.

Buster doesn't have any SHA3 tools in coreutils. While I don't have
anything against calculating such checksums in addition to the usual
suspects, I want to make sure people with current distros can easily
check them.

>> 1. Add labels of the form "checksum.cloud.debian.org/${ALGO}" under
>> metadata.labels, for example "checksum.cloud.debian.org/sha256".
> 
> Labels are to search for stuff, not describe the content.

That seems like a good enough reason.

>> 3. Add a new mapping within the "data" mapping called "checksums" with
>> keys for each algorithm, e.g. "data.checksums.sha256".
> 
> The usual way would be something like this:
> 
> | data:
> |   verify:
> |   - name: sha3_256
> |     content: ABC=
> |   - name: gpg
> |     content: AAA=

That kind of structure works for me. That way we *can*[1] have checksums
for multiple image formats and multiple algorithms, e.g. the raw image,
qcow2, compressed tarball, or whatever.

1. I carefully chose that word. I don't wish to imply that we should,
necessarily, I would just like to keep the options open.

>> In each case I expect the values to be hex strings, effectively the same
>> as the first column of the output from sha1sum, sha256sum, sha512sum,
>> etc... from coreutils.
> 
> No, don't.  Use base64 like everyone else.

I strongly disagree with this. Practically everyone else uses
hexadecimal for plain checksums. A GPG signature is its own thing but is
(generally) plaintext (I'm assuming clearsign). This is what we (as in
the project) use for the archive and for ISOs.

Kubernetes does usually Base64 encode data in Secret resources (though
stringData seems to be a well-kept, um, secret) and I don't really
understand where that came from. I'm not convinced that by itself is a
good example to follow.

Cheers,
Chris

-- 
Chris Boot
bootc@debian.org

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: