Re: Need better release validation documentation/strategy.
On Fri, 8 Apr 2022, ckeader wrote: 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. This was facinating reading, and I was not aware of any of it before. Unfortunately, I have not figured out how to follow its advice yet. Everything related to OpenPGP is extremely obtuse with massive amounts of documentation. OpenSSH 8 and later offer a facility which allows validating a file's origin and integrity given a certificate (see https://www.agwa.name/blog/post/ssh_signatures). I gave this a try and it was remarkably simple. It is several orders of magnitude less complex than OpenPGP and many people use OpenSSH. Unfortunately, not all systems have OpenSSH 8 yet (or will ever have OpenSSH). Another issue is that users could be confused by ".sig" files and won't know if they should use OpenSSH or gpg to validate with them without looking at the content. Providing the signer's pub keys on a (secured) web site seems to be the best option for now. I have been using several mechanisms, including an insecure URL link as is shown in my email signature text. An important question has not been asked yet, IMHO - why are maintainers using this relatively obscure method for hashing? Yes, this is very obscure and it defeats the purpose, which should be to encourage verification. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
Re: Need better release validation documentation/strategy.
> 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?
