On Wed, Mar 14, 2012 at 9:35 PM, Lucas Adamski <[email protected]> wrote: > My understanding is that there will be multiple app stores. But code signing > has another benefit: reducing systemic risk. > > This assume code signing and sane key management, but lets say there's a very > popular app with significant privileges. > To compromise a large number of people, you'd need to: > a) compromise the site hosting the app > b) compromise the key signing the app (assuming you require app updates to be > signed with the same key) > c) compromise or trigger the update mechanism for the app > d) wait for updates to trickle out > > This is a tedious process that slows down exploitation, and that's no fun.
yyyup. it's why debian's package management has never been compromised. it's actually worse than tedious: success actually requires physical compromise techniques that are normally only the reserve of mafia, cartels, military and intelligence agencies. ( ok that's assuming that the app source code isn't hostile, for whatever reason .... ) > If app authentication relies only on SSL, then you just need to pop a web > server (which isn't hard, really). Everyone > using the app gets owned simultaneously. there's another disadvantage of using SSL PKI authentication (on HTTPS), which is that each mirror now needs a *separate* key, or you need to distribute that key out across multiple sites. so you either have the disadvantage that you have to weaken the security of the SSL private key (oops) or you have the disadvantage that you get criticised for "becoming another apple" by "locking people out of the app system" or you have the disadvantage that if there are a large number of mirrors you have to spend vast amounts of time checking that the mirror admin is competent. no, the debian system of individually signing the apps (twice) is much easier. and then it doesn't matter how the app packages are distributed: you can use rsync, ftp, peer-to-peer networking, carrier pigeons or CD/DVDs it just doesn't matter. l. _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
