[Project_owners] XPI install still vulnerable to MITM attacks on mozdev.org

Douglas E. Warner silfreed at silfreed.net
Wed Jul 18 06:56:50 PDT 2007

On Wednesday 18 July 2007, Michael Vincent van Rantwijk, MultiZilla wrote:
> Right, and keep praying that nobody takes your Open Source code from
> either the XPI/JAR, or the CVS repository, or just fork or otherwise
> build his own malicious copy of your hard work.

If some developer forks your code, any user who has already installed the 
extension will still get updates from the original developer.

If some developer forks your code and calls it by the same name to confuse or 
steal your users, you have a problem regardless of whether the developers 
intentions are to install a malicious or functional copy of your extension.

Code signing certificates just validate that *this file* is the one *this 
person* signed, not one that was interjected by a MITM attack.

> So let's another example; Philip Chee's hard work, who single handed
> converted over 60 extensions from Mozilla Firefox to SeaMonkey, now
> think again.  What will happen if you, the original owner of the
> extension signed your work?  Will that invalidate Phil's work or not?

Phil's work is not invalidated - assuming he contributed it back upstream.  
Code signing signs the resultant packages (XPIs, JARs, etc) - not the code in 
the repository.

> One thing is for sure, the original code signing should be removed, by
> Philip in this example, and replaced with his own one.  Does he have
> one?  Will he get one?  Can you still fork a project?  What will people
> think about two different certificates?

There wouldn't be any "original code signing" here; Phil's work would be 
merged back into the development branch for each extension and published as 
usual from the original developer.

If someone forks your code (regardless of intention), they can't sign it with 
*your* certificate.  It's up to the user at that point to figure out that 
*this extension* they downloaded came from the source they intended.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mozdev.org/pipermail/project_owners/attachments/20070718/55dad85c/attachment.bin 

More information about the Project_owners mailing list