4 ms·
> So, how do you suggest how to verify a public key for a third-party repository at scale? We already have infrastructure for this. Here's that first line for
by zrm 7y ago
> So, how do you suggest how to verify a public key for a third-party repository at scale?
We already have infrastructure for this. Here's that first line for the Signal installer:
> curl -s https://updates.signal.org/desktop/apt/keys.asc | sudo apt-key add -
You're getting the key from signal.org over TLS. It's an authenticated channel, the TLS certificate is subject to revocation if compromised. Key distribution isn't the problem.
You also don't inherently need a central authority for revocation. There is already a line in sources.list where you're checking for package updates, it would be straightforward to have the package manager to check in the same location for key revocations, or specify another URL to check for that when the key is installed.
- PaulDavisThe1st 7y agoThat verifies that the download is as it should be. Apple's app signing verifies that the app is approved by them. Substantively different things (though related).
- zrm 7y agoA package signed with the Debian signing keys proves it is approved by them. A package signed with the Signal Foundation signing keys proves it is approved by them. It's substantively the same thing, you're just enabled to trust multiple independent parties, or yourself if you install something outside of the package manager.
- danieldk 7y agoThe point is that downloading a key from a website does not prove that the key belongs to that organization. If the server is compromised, the attacker could replace the public key and TLS would not barf at it. Your reactions perfectly underline my point: most users do not understand trust or if they understand trust at some level, they do not know how to verify trust.
- zrm 7y ago> If the server is compromised, the attacker could replace the public key and TLS would not barf at it. Equivalently, how do you know the public key that came with your iPhone wasn't compromised? It could have been if it was imaged in the factory from a compromised Apple server. It also could have been if Apple's signing server was compromised and used to sign an OS update your device installed, or their development servers that store the next version of the OS to be released. What makes you think that is any less likely than the Signal Foundation having their servers compromised? If the place you get the public key from is compromised then the public key is compromised. TLS can't save you from that, but what can? (Actually, some kind of web of trust might. If signal.org started telling you its package signing certificate is different from what all your friends say it said last week, that would be an obvious red flag.)
- PaulDavisThe1st 7y agoIt's not the same thing at all. Neither Debian nor Signal audit 3rd party applications in the way that Apple does, which is why neither Debian nor Signal play any runtime role in denying the ability to run a 3rd party application. Apple's app handling process is more than just attaching signing keys. Which is partly why they want you to pay for it.
- zrm 7y ago> Neither Debian nor Signal audit 3rd party applications in the way that Apple does How do you mean? Almost everything Debian packages is authored by third parties. Debian aren't to my knowledge the original authors of LibreOffice or GIMP or Firefox. And they certainly don't just sign anything without looking at it. They do also sign some packages they have authored themselves, as does Signal, as does Apple.