“Only the paranoid survive.” – Qubes OS signature mismatch | Hacker News Reader

“Only the paranoid survive.” – Qubes OS signature mismatch

twitter.com

60 pointselux21 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 :)

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.

> 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.

Interesting. It's been a long time since I've created any of my own (a decade? geeze I feel old) so it's apparently a bit different.

Switch to HTTPS.

Debian supports using HTTPS mirrors.

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

How does corruption get past TLS?

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.

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.

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.

Seeking publicity instead of trying to redownload and verify.

News today, sigh :(

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

Twitter is not news.

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

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

Cosmic ray bit flip also a possibility.

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

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...

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]

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.

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

Probably just truncated.

Reply on news.ycombinator.com