Mailing List Archive

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 <URL-OF-CHECKSUM-FILE>
$ sha1sum -c <CHECKSUM-FILE> --ignore-missing

and for the public key I could do something like:

$ wget <URL-OF-PUBLIC-KEYS>
$ gpg --import <PUBLIC-KEYS-FILES>
$ 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
Re: Verifying and checksumming new release is somewhat cumbersom [ In reply to ]
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.

> and for the public key I could do something like:
>
> $ wget <URL-OF-PUBLIC-KEYS>
> $ gpg --import <PUBLIC-KEYS-FILES>
> $ 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.

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.

The release signing key as well as most commit signing keys are token
based and thus it is very unlikely that this key material will be
leaked. The worst what could happen is that the build machine is
compromised by dedicated malware which swaps the to be signed data
during the build process - so we would unnoticed sign them with the real
key. But well, that is quite advanced and enough people are building
from source and closely watch our repositories for signs of intrusion.

> 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

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.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: Verifying and checksumming new release is somewhat cumbersom [ In reply to ]
On Thu, Nov 26, 2020 at 9:18 PM Werner Koch via Gnupg-users
<gnupg-users@gnupg.org> 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
Re: Verifying and checksumming new release is somewhat cumbersom [ In reply to ]
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 <URL-OF-PUBLIC-KEYS>
>> $ gpg --import <PUBLIC-KEYS-FILES>
>> $ 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 [ In reply to ]
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.
Re: Verifying and checksumming new release is somewhat cumbersom [ In reply to ]
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 [ In reply to ]
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.