On Sun, Aug 04, 2019 at 10:05:32PM +0100, Chris Boot wrote:
> On 04/08/2019 17:29, Bastian Blank wrote:
> > 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.
Okay, let's stay with sha-512 for now. Turns out it is also faster.
> >> 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.
We have one upload manifest per image file. I'm not sure yet why we
would want to have different checksums.
> > 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.
Everything current switches to base64. It's shorter and easier to see
changes. Hex only survives where people tend to read it.
Regards,
Bastian
--
You can't evaluate a man by logic alone.
-- McCoy, "I, Mudd", stardate 4513.3
