On Wednesday 18 July 2007, Scott wrote: > > (not speaking from experience here) > > I think the problem is that Firefox does not enforce code signing > > certificates; it only checks them if they're presented. > > > > This means that the certificates only purpose is to verify that *this > > extension* came from *this person/group* - it doesn't verify that it was > > tampered with during the download, or that the file that was originally > > selected to be downloaded was the intended one. > > > > I don't think that this is correct. Looking at how the XPI get's signed > the file * META-INF/manifest.mf * holds all the checksums. [snip] > This clearly shows that the XPI and the files can not be altered without > having to re-sign the XPI all over again. > The file * META-INF/zigbert.sf * also holds the same information. > > I don't think it is possible to tamper with the XPI file without > completely breaking the update because on my tests here Firefox refused > to install the XPI because the checksums didn't match when it was signed.
You're correct; signing the extension prevents tampering within that file, but it doesn't prevent someone from completely replacing the XPI with something else. Without some external way to verify that the extension you downloaded is the same one you intended to download, the signing just verifies that it was tampered with (either on the server or mid-stream). -Doug
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Project_owners mailing list [email protected] http://mozdev.org/mailman/listinfo/project_owners
