Re: Verifying and checksumming new release is somewhat cumbersom
On Thu, 3 Dec 2020 07:50, john doe said: > Is the release workflow documented somewhere so a non-dev could look to > implement this ? https://wiki.gnupg.org/AgentForwarding feel free to extend this page if you have remarks. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Verifying and checksumming new release is somewhat cumbersom
On 11/29/2020 12:53 PM, Werner Koch wrote: On Sat, 28 Nov 2020 07:57, john doe said: If I look at Debian (1) for example, the checksum file is gpg signed. Assuming that I understand correctly, the Debian approach is not a safe way to make the checksums available?propagate? No, that is a safe way. Having a separate file with checksums is sometimes better for the signing workflow. It also allows to sign/verify a bunch of files with just one operation. It also avoids the need to download and upload all files to a dedicated signing box. Only since GnuPG 2.2 the latter could be handled using gpg-agent's remote feature. Interesting, just to be sure you are refering to the below option from (1)?: "--extra-socket name" Is the release workflow documented somewhere so a non-dev could look to implement this ? In other words, is it worth considering such a move. 1) https://www.gnupg.org/documentation/manuals/gnupg/Agent-Options.html#Agent-Options -- John Doe ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Verifying and checksumming new release is somewhat cumbersom
On Sat, 28 Nov 2020 07:57, john doe said: > If I look at Debian (1) for example, the checksum file is gpg signed. > Assuming that I understand correctly, the Debian approach is not a safe > way to make the checksums available?propagate? No, that is a safe way. Having a separate file with checksums is sometimes better for the signing workflow. It also allows to sign/verify a bunch of files with just one operation. It also avoids the need to download and upload all files to a dedicated signing box. Only since GnuPG 2.2 the latter could be handled using gpg-agent's remote feature. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Verifying and checksumming new release is somewhat cumbersom
On 11/26/2020 9:10 PM, Werner Koch wrote: Hi, and thanks for asking. Thanks for this. To be sure that I understand you correctly, I took the liberty of rewording your answers. On Thu, 26 Nov 2020 19:12, john doe said: Is there a URL to download those sha1sums and those public keyss as files? The problem with sha1sums is that a single publication would be easy to fake. The only known countermeasure is to widely distribute them. We do have them on the website as you noticed, they are send out by signed mail to several thousand subscribers, and our and other mail archives carry the release announcement with the checksums. If I look at Debian (1) for example, the checksum file is gpg signed. Assuming that I understand correctly, the Debian approach is not a safe way to make the checksums available?propagate? No, there is no single file with the checksums because that would be a too easy target for an attacker. Even if the file would be gpg signed? and for the public key I could do something like: $ wget $ gpg --import $ gpg --verify *.sig And please check the printed fingerprint against copies of the fingerprint distributed in the same way as the checksums. The keys are also quite well connected in the Web-of-Trust, which can also help to to validate them. You mean by checking if the fingerprint of the downloaded keys match the one listed on the web site? The advantage of the public keys and the fingerprints is that they do not change and thus you only need to validate them once once and sign the keys so that you can trust them in the future. Okay, if the fingerprints matches I should sign the keys with mine. I understand that for this last step I could also do: $ gpg --keyserver-options auto-key-retrieve veirfy *.sig Don't. For verification always use gpg --verify file.sig file Okay, won't do that anymore. and check the output well. If you need to automate this, use gpgv and put all the trusted signing keys into a dedicated keyring. For automating this with gpg, I would suggest to write a gpgme based tool. If I want to verify a new release,: - Manually: take advantage of gpgv - Unattended: use a wrapper around gpgme Your input is much appriciated. 1) https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/ -- John Doe ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Verifying and checksumming new release is somewhat cumbersom
On Thu, Nov 26, 2020 at 9:18 PM Werner Koch via Gnupg-users wrote: > > Hi, > > and thanks for asking. > > On Thu, 26 Nov 2020 19:12, john doe said: > > > Is there a URL to download those sha1sums and those public keyss as files? > > The problem with sha1sums is that a single publication would be easy to > fake. The only known countermeasure is to widely distribute them. We > do have them on the website as you noticed, they are send out by signed > mail to several thousand subscribers, and our and other mail archives > carry the release announcement with the checksums. > > No, there is no single file with the checksums because that would be a > too easy target for an attacker. Maybe not common among programmers, but you could easily clearsign the shasums text file and then use a public time stamping service additionally, thus first time users would know that the signed shasums file would have been actually signed at day x time y, if you would also provide the .ots file. https://opentimestamps.org Regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Verifying and checksumming new release is somewhat cumbersom
Hello all, I see that at (1) and (2) the public keys block and the sha1sums respectively are listed on their corresponding page. Is there a URL to download those sha1sums and those public keyss as files? That is for checksumming I could simply do: $ wget $ sha1sum -c --ignore-missing and for the public key I could do something like: $ wget $ gpg --import $ gpg --verify *.sig I understand that for this last step I could also do: $ gpg --keyserver-options auto-key-retrieve veirfy *.sig Any feedback is appreciated. P.S. If I can I'll be more than happy to help tweaking the release process in that regard. 1) https://gnupg.org/download/integrity_check.html 2) https://gnupg.org/signature_key.html -- John Doe ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
