> According to this article [1], the compromised app was indeed signed – but with a different Developer ID than usual.
That's the terrible part about all of this. Having signed applications without any verification of the signer is pointless.
A simplistic, yet more secure approach, would be to have domain validated keys that could be used to sign applications. Browsers could then verify that the application downloaded from example.com was signed with a key for example.com. I think OSX already stores "This was downloaded from the scary internets!" in a separate resource fork so this info could go there as well. Maybe even cut out the middle mad and put them in DNS SRV records so you don't even need a central CA. If DNS gets compromised the client's have bigger problems already.
Unfortunately like all things like this, it'd be forever before it's widespread enough to be useful.
It's not completely pointless, as it allows Apple to (silently and quickly) release updates which distrust that Developer ID, however a stronger protection would be to pin apps to a particular Developer ID.
That's the terrible part about all of this. Having signed applications without any verification of the signer is pointless.
A simplistic, yet more secure approach, would be to have domain validated keys that could be used to sign applications. Browsers could then verify that the application downloaded from example.com was signed with a key for example.com. I think OSX already stores "This was downloaded from the scary internets!" in a separate resource fork so this info could go there as well. Maybe even cut out the middle mad and put them in DNS SRV records so you don't even need a central CA. If DNS gets compromised the client's have bigger problems already.
Unfortunately like all things like this, it'd be forever before it's widespread enough to be useful.