Packages have signatures on Linux. They're validated during install rather than execution, but validating them on execution wouldn't cause meaningful problems as long as the device owner can install additional signing keys.
How does an average computer user know how to verify a public key (does it belong to who it claims to belong to)? They won't. I know many long-time Linux users, and they will just copy and paste all installation commands, including apt-key add commands. If a server is compromised, they will just copy and paste an attacker's PGP key. There are many criticism I can make of a centralized certificate authority, such as Apple, but by default Apple's code signing provides far more security for third-party applications. It is far less likely that Apple's key is compromised than the key of some random 3rd party APT repository maintainer. Furthermore, if a Developer's key is compromised, Apple can easily revoke it.
A centralized authority has its problems (the authority becomes the gatekeeper). But for most users, it much more secure.
So, how do you suggest how to verify a public key for a third-party repository at scale? Most users will not be part of the PGP web of trust and we cannot all meet the author in real life to compare PGP key fingerprints.
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.
A 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.
It'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.
> 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.
The 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.
> 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.)
How does an average computer user know how to verify a public key (does it belong to who it claims to belong to)? They won't. I know many long-time Linux users, and they will just copy and paste all installation commands, including apt-key add commands. If a server is compromised, they will just copy and paste an attacker's PGP key. There are many criticism I can make of a centralized certificate authority, such as Apple, but by default Apple's code signing provides far more security for third-party applications. It is far less likely that Apple's key is compromised than the key of some random 3rd party APT repository maintainer. Furthermore, if a Developer's key is compromised, Apple can easily revoke it.
A centralized authority has its problems (the authority becomes the gatekeeper). But for most users, it much more secure.
So, how do you suggest how to verify a public key for a third-party repository at scale? Most users will not be part of the PGP web of trust and we cannot all meet the author in real life to compare PGP key fingerprints.