Nils Maier wrote: > Link-Fingerprints cannot solve the problem of update.rdf-over-HTTP as > update.rdf is likely to update often and you cannot compute hash(es) for > it in advance.
I didn't suggest that it could. > If you're proposing that all extensions or at least their update.rdf > must be served via AMO, then no thanks. What's the problem with centralising updates.rdf on a.m.o., for those people who can't or won't host their own SSL site? > Link-Fingerprints in general fail the requirements that Dave defined: >> What I want is to be able to be able to establish some trust that the update >> file retrieved is correct, and has not been tampered with, intercepted and >> is as it was originally written by the add-on author. > * correct? I misunderstood "update file" as the actual update data, rather than updates.rdf. Hence my suggestion. Thanks for setting me straight so politely. > PS: the Link-Fingerprints "standard" says: >> Clients are encouraged not to implement any hash algorithms other than MD5 >> and SHA-256, until and unless SHA-256 is found to have flaws. > MD5 is broken, you can find collisions in just hours. OK, then. I have a file with the following MD5: 6dfabd7a681569ac0b9d6b010bec88d6 /home/gerv/docs/hacking/doorbell.png Please find any other file (I'll make it easy, and won't require it to be a valid XPI with a trojan payload) with the same MD5 in "just hours", and send me a copy as an attachment. Gerv _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
