On Sun, Mar 11, 2012 at 11:46 PM, Jonas Sicking <jo...@sicking.cc> wrote: > On Sat, Mar 10, 2012 at 1:00 PM, Jim Straus <jstr...@mozilla.com> wrote: >> Jonas, Paul, etc. - >> For any app, but in particular, a third party hosted apps, we could require >> that the manifest contain a signed cryptographic hash of the core of the >> application (javascript, html, css?), along with the signature of the >> trusted store. This hash would be validated as signed by a trusted source >> (like or the same as SSL certs) and that the applications core matches the >> hash. This would require that the browser/device pre-load the given >> content, but hopefully apps will be using the local-cache mechanism, so this >> should not be burdensome. Using this, once a trusted store has validate an >> application, the application can't be changed, even if it is hosted by a >> third party. We would have to enforce that a signed application can't >> download untrusted javascript (eval becomes a sensitive API?). This would >> allow a third party to host the apps approved by a given store. It would >> also prevent a hacked store site from distributing hacked apps (well, things >> like images could still be hacked, but not functionally) as long as the >> hacker doesn't have access to the signing system (which should clearly not >> be on a public machine). This doesn't prevent a hacker from gaining access >> to information communicated bak to a server, but at least makes sure that it >> isn't re-directed somewhere else. > > It's not entirely clear what problem it is that you are trying to > solve?
the problem he's referring to is the one that the debian project has solved with its distribution infrastructure. > I'm not a big believer in code signing. It's much too easy to miss jonas. i'm a bit shocked and taken aback that you're saying this. do you understand why the debian project has the infrastructure that it has? this is *important*, jonas. if you do not understand what jim is referring to, and you are going to be the person in charge of implementing the security of B2G please for god's sake do some research into why debian digitally-signs all packages. you've come up with some absolutely fantastic ideas on the issue of B2G security but if you are, as you say, "not a big believer in code signing" this is a really big alarm bell. the simple version is: the reason why debian digitally signs each individual package is to ensure that malicious packages cannot be installed [on an uncompromised unmodified system]. if you do *not* have such a system in place it is incredibly easy for a malicious user to take any arbitrary package, wrap it with malicious code and release it under the exact same name. how do you prevent this from happening? jim has described the problem space, very very well. it turns out that there already exists a near-perfect solution to that problem (debian packaging). SSL is like... waayyyy down at the bottom of the infrastructure that is *used* by those solutions. l. _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
