1
Follow up of https://lemmy.frozeninferno.xyz/post/60352426
A good use case to have: I want to ensure my OS is authentic. I want to run Ubuntu from the Ubuntu people, Qubes from the Qubes people, and so on. Once the OS is booted, it is assumed that native tools inside it can verify the authenticity of the software that is run. If this is not the case, leave a comment and I’ll reply or make a new post.
Comment:
I don’t think you understand how apt works. Anyone can roll out a mirror.
Also, again, the hashes need verification. Trusting the transport rather than a signature is obviously going to lead to compromise somewhere in the chain.
Look buddy, you do you. If you clearly already aren’t using the signatures provided …
1
Follow up of https://lemmy.frozeninferno.xyz/post/60352426
A good use case to have: I want to ensure my OS is authentic. I want to run Ubuntu from the Ubuntu people, Qubes from the Qubes people, and so on. Once the OS is booted, it is assumed that native tools inside it can verify the authenticity of the software that is run. If this is not the case, leave a comment and I’ll reply or make a new post.
Comment:
I don’t think you understand how apt works. Anyone can roll out a mirror.
Also, again, the hashes need verification. Trusting the transport rather than a signature is obviously going to lead to compromise somewhere in the chain.
Look buddy, you do you. If you clearly already aren’t using the signatures provided with hashes when you use hashes, so it’s no bother to you. Apt, and I, will continue doing so.
So what is the threat here?
Trusting the transport rather than a signature is obviously going to lead to compromise somewhere in the chain.
This makes no sense to me. The transport = the HTTPS chain? If so, that’s all encrypted. It’s like saying that my bank password is going to be slurped off public wifi (when the site is HTTPS).
My “plan C” and “plan D” remain viable threats against the “hash, don’t check signatures” strategy. Any OS worth hashing is worth signing, so plan D is the one to look at.
❌ plan D
- good guy creates software.org
- distributes legit software and public keys
- bad guy compromises software.org at a later date
- did not compromise the public key (created years prior by the true owner)
- bad guy cannot distribute software that matches the public key
- software is malware, served over valid https, and verifiable with malware hashes served by bad guy
- hashes would “validate” the malware, but key verification would fail
What good is a PGP key?
Something I did not think about in my OP, but realize now after reading up on PGP - the good guy’s PGP key would have to be available to me as an end user. There could(?) be two Ubuntu PGP keys fighting for authenticity. Such an attack would be very gutsy and obvious. But as someone new to this ecosystem, it seems you must first trust one party.
In the ideal case:
- I physically verify someone’s identity documents (passport, etc.)
- I get their key
- their key is connected via a short number of hops to the software I want. Let’s say 4 hops to an Ubuntu developer.
- now what?
The one person I verify could show me fake documents. Not very likely. But I feel like neither is compromising ubuntu.com ? Especially with nobody noticing? A lot of major software is mirrored on Github too. So PGP is better than hashing two files because? The examples here don’t help.
I think the commenter assumed I was arguing that the OS should not do verification in apt or other tools. What the OS does is none of my business. I just want to defend against (or even better, understand) threats. If you can install a 100% authentic Ubuntu ISO and have apt install curl lead to a version of curl other than what the maintainers of curl and/or Ubuntu intend for you to install, I would hope I know that by now.