Bad GPG Signature is Good on 2nd Try?

[entr0py]

After downloading Qubes 3.1 iso, I attempted to verify with Release 3 Signing Key:

user@host:~/Downloads$ gpg --verify Qubes-R3.1-x86_64.iso.asc
gpg: assuming signed data in `Qubes-R3.1-x86_64.iso'
gpg: Signature made Wed 09 Mar 2016 03:40:56 AM UTC
gpg: using RSA key 0xCB11CA1D03FA5082
gpg: BAD signature from "Qubes OS Release 3 Signing Key" [unknown]


I verified the hash .DIGESTS:

user@host:~/Downloads$ gpg --verify Qubes-R3.1-x86_64.iso.DIGESTS
gpg: Signature made Wed 09 Mar 2016 11:35:48 AM UTC
gpg: using RSA key 0xCB11CA1D03FA5082
gpg: Good signature from "Qubes OS Release 3 Signing Key" [unknown]


I compared checksums:

user@host:~/Downloads$ sha1sum Qubes-R3.1-x86_64.iso
990b7765ee209b42b3cad78673463daae769c729 Qubes-R3.1-x86_64.iso

user@host:~/Downloads$ cat Qubes-R3.1-x86_64.iso.DIGESTS | grep 990b7765ee209b42b3cad78673463daae769c729
990b7765ee209b42b3cad78673463daae769c729 *Qubes-R3.1-x86_64.iso


So tried verifying the .iso again:

user@host:~/Downloads$ gpg --verify Qubes-R3.1-x86_64.iso.asc Qubes-R3.1-x86_64.iso
gpg: Signature made Wed 09 Mar 2016 03:40:56 AM UTC
gpg: using RSA key 0xCB11CA1D03FA5082
gpg: Good signature from "Qubes OS Release 3 Signing Key" [unknown]


What am I missing? Is the 2nd argument necessary even though gpg found the signed data properly the first time?

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Is it possible that the ISO hadn't completely finished downloading when you
tried to verify it the first time?

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXpSKqAAoJENtN07w5UDAwED4P/11/2xzx0JFn8FtLz6gPIomS
kigEHRdYr8OHCVG+tJde9BviRdfofadHYoDY0hOI0z+clxxRvGXqycPVKF5B4Ao+
HQ0obd3Fgv6ztoZaFFs4ttu0EyQrpP1E16K+/grkYoh20ceIIMHP0QB3j74E0m30
nkMgEZiBjMu7driTGGfNLTrSj5e1KGgyWjdAoF1oV2BK1dnWOlGolKwUiD+p4pOf
HS+40s5qCt4tNZO/J+P/yXlK8LS3CBqXof4rkheT7xpUvRUkj16oB+sswdMYPdqj
gALAJ7NAUcV13fmZx2XAcHCfRhKF4/3moVZqj8LQKa9R21UpW3Oxg2BMfW1sJBeK
+ueRUONcA2aq+5Vwlxh4PPhZ/gBDr/3whMI45pjR7u7NmaB8cq4i5lWnPY9TRTgL
wyO4uj//a3ySknyOL9lt4TqbQddGCNEf7YA5DvzdPVh0iKWG3UOEl2BztYuLe7F9
3MKJMMNbiXbL588vTht0RhgFUZZWN5tNsdwpLMkCEZuJj0MDQiO0VcSl9ZxJbiUL
iMzAlYRt/22CBa5Qqwm7iKWbwAHDh3FBMut/9YJmgwVcBQLuT3HUkgA4DecQ85LU
aMtg9jQyUgTw3UKQ3cfV8pU4woy+rSv4wK9jDm/20oqm+s4JH+pMj1kUObAjHTwl
56zGqx78mS0du2J7AVs6
=o/Ul
-----END PGP SIGNATURE-----

[entr0py]

Andrew David Wong:

I don't think so, because then it would have had the .part extension. Is there a long write after the download completes?

RAM / HD limitations? 4.7 GB iso vs 1.0 GB RAM, 10 GB Private storage.

Not sure it's important but kinda unnerving to be producing different results :/

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

That probably depends on things like your hardware and which filesystem you're
using.

> RAM / HD limitations? 4.7 GB iso vs 1.0 GB RAM, 10 GB Private storage.
>
> Not sure it's important but kinda unnerving to be producing different
> results :/
>

Well, it should only be unnerving if you know with certainty that GnuPG is
returning different results on the *exact same* sequence of bits. Since you
didn't hash the ISO before the first (failed) verification attempt, we don't
have any evidence that that's the case. It's much more likely that the bits
changed (e.g., due to write caching, as you suggested).

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXpU/DAAoJENtN07w5UDAwleAP/RHsRdSvgeDMsH/PMmzHuWK2
BNH8vTD2kTb/ojO1XSgJu7jPTs9LJmmTf7+LuO4PqDpnWyssZYXcNDMtEnoojFvi
MIdBuRwdUS0ayYX8aUVWG5NF6XhqMhrojGdWiJ1RhvE3had7BbYmTOwNi+JAZF9Y
nuQTQYt4mBzOR/z9JfPmd+acfHBXc7TyAB0APKNU42r+wVTJ70vVuWIioXdhtqup
F6CgmpspJGxXKkogAtbekIpigRTFOqC9ShADTAY3gKDtSXmHD8jpEQBAJtFvpyNW
9DtkesEjMbbDc7wOutKMk1pT7feb7Zpks7WSnyads6OL+ilWoqdn0NoD43X+K97A
95OwSBnZY3d5uFZcXLY59OdCEOQdeS8jzn8C7rk7Z/3s+P+Cq17mfKD53WHPIglI
M9s3ahsI8D+iukNo/KsU+gZJfKWc8rAWi0I7vd4geSd0pGC3sWAPkWsY7IZhRpS+
cOLn7/3qzHoyOr2vU/5rc6LGEMF2sCCicy9Y/EI6HsZKZZYdI6mdaBfqyvrOTpMF
XWFE2uOO/+UoHZ6t+ZDkzDOlBZdbhvZmb/UaoGfjHqIjiuYwL5nKdRk4LHP6U0ZK
2je5DW6lOE22M752MtV/Xv/kQtaQM/nxyIJxMI6Etu6vKZIFMMYGpvGzQaPOWrGN
ZbL/7LFKvJt/UsMBC2VO
=P+iK
-----END PGP SIGNATURE-----

[Robin Schneider]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 06.08.2016 04:47, Andrew David Wong wrote:

> Well, it should only be unnerving if you know with certainty that GnuPG is
> returning different results on the *exact same* sequence of bits. Since
> you didn't hash the ISO before the first (failed) verification attempt, we
> don't have any evidence that that's the case. It's much more likely that
> the bits changed (e.g., due to write caching, as you suggested).

Bad memory or bit flips in memory might be a second plausible cause to look
at. Maybe you can check that (bad memory) with memtest86+?

- --
Live long and prosper
Robin `ypid` Schneider
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXpZ+eAAoJEIb9mAu/GkD4X8oQANZ9cGCScw2W8JSsI2yvSmWD
H0SIrIz4QtamITtQhwpOVJT40hnMnoiilTfiR2OeOW9iKE7MbABYV3diyiYJh5Yg
XhkiEi3d4LoK0Kxn1Zn/9MI+DHTN+yKlWj5V0GH9V7x8mdSewksUD5P63Zsses+f
7s2Ant5cfUdnV12ysayXmzq5YlYG4C0vJptP8aMqbVW8wFytKZFczzM31sGPaRWw
7DJShhP4jILLbqtqL+v0Lmgkl4fjW8Z2wTUqeJJ9F0EmQdHm5ANDyVXb1m+od0vT
jK+wdoPDlgljHz4bkFiXHjMvrLggFXjboR54/2UcglhYgDcwggrAmmOKEzC1c7mK
wV0BtdIrv1+PWPOqxv5Xb3rOKZb3lbiNcHp3Upz/NaMTGmqn+vT50rg8f0kLxara
QUW1YlArN0Lp7csO22Gpnj7rQfIubjzwhNpdAh26gSUXkfKbGvkjOTr5MctR73sE
JG50NXGWCQpBj1Q0cAzuXhCGDW3YhGMl9OgPOos6ZG+BMVPw+Qxf85VgIxUcCfJb
2pBSWfShcPmBsZ1FzrFvVWE2O9StwpaKheezVYbLNxjcta2QL32AY0Wp3cXsYxGU
W7kisX0+HTH2xijdY4R60W2uXtNlXZCXPiqwu58Uleo7h5/qXaDWx06r0s5mf9QW
lnskN719dtd4jFwi3Rv3
=udik
-----END PGP SIGNATURE-----

[entr0py]

Robin Schneider:

> On 06.08.2016 04:47, Andrew David Wong wrote:
>
>> Well, it should only be unnerving if you know with certainty that GnuPG is
>> returning different results on the *exact same* sequence of bits. Since
>> you didn't hash the ISO before the first (failed) verification attempt, we
>> don't have any evidence that that's the case. It's much more likely that
>> the bits changed (e.g., due to write caching, as you suggested).
>
> Bad memory or bit flips in memory might be a second plausible cause to look
> at. Maybe you can check that (bad memory) with memtest86+?
>
>

Good hypotheses - thanks! With underutilized RAM, might take a while to notice bad chip.

Of course, could also be them damn cosmic rays! Need to find an underwater habitat (or get some ECC RAM).