Nelson B schrieb: > As I understand it, presently the downloads of mozilla addons are > validated not with code signatures but by the following method: > A hash of the file is stored on an https server operated by mozilla, > the actual file may be downloaded from anywhere, by any means including > ftp, but it must have the expected hash to be downloaded. (OK so far.)
Right. > This scheme is intended to make code signatures unnecessary. (Someone > at mozilla is allergic to code signing, evidently.) But at the cost that > mozilla must be given the new hashes for any new addons and any new updates > to addons. No, AMO will hash the XPI once uploaded. This is an automated process, the author does not have to hash himself when using AMO. Code singing isn't exactly free. The author has to spend money and effort in obtaining the certificate, maintaining it, and learning how to sign his XPI, what isn't easy at the moment either. Automated signing with a mozilla owned certificate isn't an option either. This would put a big fat "mozilla" tag on third party software. Not to mention the problem of maintaining that cert (store that cert somewhere without password, nor store that password somewhere too?) > The issue has to do with automated downloading of updates to addons. > Some makers of addons don't want to have to coordinate distribution of > addon updates with mozilla. They don't want to have to give new hashes > to mozilla for every update, as I understand it. So mozilla wants to > accommodate them, WITHOUT requiring them to sign their code. Right, some people don't want to use AMO for distribution of their extensions. But not because they would have to give hashes (s.a.). The reasons not to use AMO are various, like simply not liking AMO, lacking functionality of AMO in some areas like stats, extensions not suitable for AMO, bringing new extensions to testers, etc... Some post by Dave summarizes most reasons, and over at m.d.extensions authors discussed a lot of reasons not to use AMO. > So, the current idea being explored (as I understand it) is to allow others > to automatically download their addons (or rather, updates to their addons) > from their own servers, as long as their own servers are https servers. Not exactly true. What is currently discussed are ways to let authors host updates themselves in a secure manner. Installation is out of scope of this discussion for now. Proposals so far include https-only updates and signed updates, either by GPG-like public keys or self-signed certificates (with critical extensions) that are provided by the initial installation XPI. > I think all this aversion to code signing merely demonstrates a lack of > commitment to user security. (Frankly, Microsoft now seems to have the > stronger position with respect to requiring strongly authenticated code > for downloading of updates.) But I am merely an observer of all this > evolution. > The aversion to code signing lies more in the money, effort and required knowledge associated with it. These requirements would stall extension development a lot if code signing was mandatory. And IMO the risks and impact associated with such a MITM attack don't worth stalling extension development that much. So we (under the lead of Dave) are looking for ways to secure updates while not burden extension developers that much. Oh, and MS isn't that better actually. Downloads from microsoft.com/downloads are affected by the very same MITM attack that brought up this discussion in the first place. Nils _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
