“Only the paranoid survive.” – Qubes OS signature mismatch (opens in new tab)

(twitter.com)

60 pointselux9y ago21 comments

21 comments

Redownload. Check again. I'm on satellite internet with the horrible latencies and frequent timeouts associated with that tech, I recently had the netinstall image for Debian fail integrity checking three times in a row, from the http mirrors. Guy from the link said it himself, download via torrent and all is well.

Generally, being on such terrible interwebs I get angry whenever I hear people claim torrents are only for piracy. We all know they're wrong, but my legal torrent use has really never been more intense. Rsync's ability for aggressive retrying is also blessed :)

simcop23879y ago

Yea that's one thing I really love about torrents. Because of the giant set of hashes they use, it makes it really great to verify integrity of the download. You've got a hash for each block (128k by default) and for the overall download, along with the complete size of the file.

masklinn9y ago

> each block (128k by default)

Depends on the seed creation software, Tixati defaults to 256k for instance, kind-of: it's the default value of the box, but a new default is recomputed based on the amount of data included in the torrent. If I try to seed my local install of Bastion (920MB) it picks 1MB, Atom Zombie Smasher (25MB) yields 64kB, and Shadowrun Hong Kong (9GB) picks 4MB.

1 more reply

snvzz9y ago

Switch to HTTPS.

Debian supports using HTTPS mirrors.

Gruselbauer9y ago

I did use HTTPS mirrors. Doesn't help my problem. Unlike torrents.

1 more reply

lwf9y ago

There are a bunch of reasons this could've happened -- corrupted downloads are not unheard of on poor connections. Maybe the file was truncated.

Or maybe it was the NSA. Without any further analysis, this isn't particularly noteworthy.

wolfgke9y ago

The first step is to detect the wrong signature. The next step is to compare the files to see whether truncation, bitswap etc. happened or whether the manipulation went deeper. Or for the more paranoid people: See what dangerous attack code can be introduced into the software by such an innocent-looking manipulation and whether the modification that happened did introduce such an exploit or not.

djsumdog9y ago

You can those questions in the reply thread (Is it the right file size? Can you mount it?)

This will only be interesting if it isn't just a corrupted image. If it isn't a corrupt image, I hope there a follow-up with a diff-tree between the two.

quickben9y ago

Seeking publicity instead of trying to redownload and verify.

News today, sigh :(

mfukar9y ago

Twitter is not news.

At best, it's unfiltered information, and usually just noise and venting.

0xCMP9y ago

He did redownload and verify via BT. He seems to also be rebuilding from source(?).

1 more reply

lillesvin9y ago

There's nothing yet to suggest that it's not just a corrupted download.

astrodust9y ago

Cosmic ray bit flip also a possibility.

trdtaylor19y ago

Best way to elevate your crypto project, get targeted. Doesn't matter if it actually happened.

daveio9y ago

Can't speak to targeted interference, but I can fetch the ISO and signature from the mirror he used, and verify it successfully.

output: https://gist.github.com/daveio/edac4aaee516cd6a408d5c8e763ce...

mocko9y ago

For reference, here's a check of the torrent with the .torrent file I snagged from https://www.qubes-os.org/downloads/ last night. Master signing key checked against the fingerprint published on the mailing list in 2013. Looks legit.

  Qubes-R3.2-x86_64 moi$ gpg --verify Qubes-R3.2-x86_64.iso.asc Qubes-R3.2-x86_64.iso
  gpg: Signature made Tue Sep 20 18:33:37 2016 BST using RSA key ID 03FA5082
  gpg: Good signature from "Qubes OS Release 3 Signing Key" [full]

mocko9y ago

For reference II - downloaded the .iso. Despite a usually robust connection the download was interrupted three times. I have no idea whether this signifies anything. Curl resumed where it left off and in the end...

  Qubes-R3.2-x86_64 moi$ gpg --verify Qubes-R3.2-x86_64.iso.asc Qubes-R3.2-x86_64.iso_WEBDL
  gpg: Signature made Tue Sep 20 18:33:37 2016 BST using RSA key ID 03FA5082
  gpg: Good signature from "Qubes OS Release 3 Signing Key" [full]

Of course (skipping merrily off into tinfoil-hat-land) that doesn't eliminate the possibility that the OP's download had been MITM-ed. However this would have to be by someone who:

1) Controls part of the network infrastructure between them and mirrors.kernel.org (i.e. routers, cables or DNS)

2) Can fake a TLS certificate for mirrors.kernel.org

So, corrupted download or a targeted MITM attack by a state-level actor? Who the hell knows anymore.

imjustsaying9y ago

when did download errors become newsworthy? are networks that robust now?

loeg9y ago

Probably just truncated.

j / k navigate · click thread line to collapse

21 comments

Gruselbauer9y ago

simcop23879y ago

masklinn9y ago

> each block (128k by default)

1 more reply

snvzz9y ago

Switch to HTTPS.

Debian supports using HTTPS mirrors.

Gruselbauer9y ago

I did use HTTPS mirrors. Doesn't help my problem. Unlike torrents.

1 more reply

lwf9y ago

There are a bunch of reasons this could've happened -- corrupted downloads are not unheard of on poor connections. Maybe the file was truncated.

Or maybe it was the NSA. Without any further analysis, this isn't particularly noteworthy.

wolfgke9y ago

djsumdog9y ago

You can those questions in the reply thread (Is it the right file size? Can you mount it?)

This will only be interesting if it isn't just a corrupted image. If it isn't a corrupt image, I hope there a follow-up with a diff-tree between the two.

quickben9y ago

Seeking publicity instead of trying to redownload and verify.

News today, sigh :(

mfukar9y ago

Twitter is not news.

At best, it's unfiltered information, and usually just noise and venting.

0xCMP9y ago

He did redownload and verify via BT. He seems to also be rebuilding from source(?).

1 more reply

lillesvin9y ago

There's nothing yet to suggest that it's not just a corrupted download.

astrodust9y ago

Cosmic ray bit flip also a possibility.

trdtaylor19y ago

Best way to elevate your crypto project, get targeted. Doesn't matter if it actually happened.

daveio9y ago

Can't speak to targeted interference, but I can fetch the ISO and signature from the mirror he used, and verify it successfully.

output: https://gist.github.com/daveio/edac4aaee516cd6a408d5c8e763ce...

mocko9y ago

  Qubes-R3.2-x86_64 moi$ gpg --verify Qubes-R3.2-x86_64.iso.asc Qubes-R3.2-x86_64.iso
  gpg: Signature made Tue Sep 20 18:33:37 2016 BST using RSA key ID 03FA5082
  gpg: Good signature from "Qubes OS Release 3 Signing Key" [full]

mocko9y ago

  Qubes-R3.2-x86_64 moi$ gpg --verify Qubes-R3.2-x86_64.iso.asc Qubes-R3.2-x86_64.iso_WEBDL
  gpg: Signature made Tue Sep 20 18:33:37 2016 BST using RSA key ID 03FA5082
  gpg: Good signature from "Qubes OS Release 3 Signing Key" [full]

Of course (skipping merrily off into tinfoil-hat-land) that doesn't eliminate the possibility that the OP's download had been MITM-ed. However this would have to be by someone who:

1) Controls part of the network infrastructure between them and mirrors.kernel.org (i.e. routers, cables or DNS)

2) Can fake a TLS certificate for mirrors.kernel.org

So, corrupted download or a targeted MITM attack by a state-level actor? Who the hell knows anymore.

imjustsaying9y ago

when did download errors become newsworthy? are networks that robust now?

loeg9y ago

Probably just truncated.

j / k navigate · click thread line to collapse