[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Need better release validation documentation/strategy.
From: |
ckeader |
Subject: |
Re: Need better release validation documentation/strategy. |
Date: |
Fri, 8 Apr 2022 23:42:05 +0100 |
> For some reason key servers are not very helpful these days with some
> of them offering distorted behavior or appearing to be severely
> overloaded. It may be that the key server used by default by Ubuntu
> Linux imposes additional limitations such as regarding exposing email
> addresses. The user might need to know how to specify a different
> server and know which ones to use.
The key server network as we knew it is dead and buried, and I would not
expect any of them to provide complete or indeed reliable information.
This article explains why:
https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f.
There was some discussion at the time over on gnupg-users also.
Providing the signer's pub keys on a (secured) web site seems to be the
best option for now.
The key to verifying the base64 encoded checksums is a conversion from
binary to hex and vice versa. od from coreutils and xxd from vim can be
used.
| Here are the SHA1 and SHA256 checksums:
|
| 91fa501ada319c4dc8f796208440d45a3f48ed13 gzip-1.12.tar.gz
| W0+xTTgxTgny/IocUQ581UCj6g4+ubBCAEa4LDv0EIU gzip-1.12.tar.gz
| 318107297587818c8f1e1fbb55962f4b2897bc0b gzip-1.12.tar.xz
| zl4D5Rn2N+H4FAEazjXE+HszwLur7sNbr1+9NHnpGVY gzip-1.12.tar.xz
$ echo "zl4D5Rn2N+H4FAEazjXE+HszwLur7sNbr1+9NHnpGVY" |base64 -d |xxd -p |tr -d
'\n'
base64: invalid input
ce5e03e519f637e1f814011ace35c4f87b33c0bbabeec35baf5fbd3479e91956$
$ echo "zl4D5Rn2N+H4FAEazjXE+HszwLur7sNbr1+9NHnpGVY" |base64 -d | od -A n -v -t
x1 |tr -d ' \n'
base64: invalid input
ce5e03e519f637e1f814011ace35c4f87b33c0bbabeec35baf5fbd3479e91956$
$ sha256sum gzip-1.12.tar.xz
ce5e03e519f637e1f814011ace35c4f87b33c0bbabeec35baf5fbd3479e91956
gzip-1.12.tar.xz
$
For the reverse operation, use xxd -r -p, or openssl sha256 -binary. The
"invalid input" message above is due to missing padding.
An important question has not been asked yet, IMHO - why are maintainers
using this relatively obscure method for hashing?