Jesse Ruderman Reporter
	Description • 21 years ago

Doug T suggested requiring XPIs to be signed.  I don't think this is a good
idea, but I've tried to present a balanced argument below.

Requiring XPIs to be signed...

* would *not* protect against installs by malicious sites.  Evidence: ActiveX
spyware is signed and very common.

* would protect against spoofed installs, slightly.  For example, suppose a
router between you and mozilla.org is compromised.  Without signing required,
the spoofer can make mozilla.org appear to point to an unsigned critical-update
XPI.  With signing required, the malicious XPI has to say "Signed by [someone
other than the Mozilla Foundation]", which might make users more suspicious than
seeing "Unsigned".  (Of course, the spoofer doesn't have to use XPI.  He could
make mozilla.org point to a .exe for download or make mozilla.org give the user
instructions that lead to a compromise instead.)

* would make life harder for theme and extension authors.

* would bring Mozilla in line with IE, for better or worse.

	Ben Bucksch (:BenB)
	Comment 1 • 21 years ago

- Most people think that "signed" means "secure", which is fatally wrong.
  (This notion of "signed" = "secure" is forwarded by the language of a lot of
  corporate propaganda, e.g. TPM.)
  So, I think that signing might actually make matters worse for the people we
  try to protect here (I assume this suggestion is because of bug 238684.)

> * would make life harder for theme and extension authors.

- It would make life unbearably hard for extension authors. Such a certificate
  is quite expensive (I think you need a special software author cert?). If
  all of mozdev shares one, it would lessen the security and force people to
  use mozdev. It would still be an annoyance, and a hidden pref would be
  demanded to disable it, and then other authors would ask users to do that,
  because they can't / don't want to sign, and we're back at square one or
  worse.

	Jesse Ruderman Reporter
	Comment 2 • 21 years ago

I don't think the problem with the ActiveX dialog is that it contains the word
"signed".  I think the problem is that it's dominated by security imagery (lock
and key) and phrases like "Publisher authenticity verified by VeriSign
[incomprehensible jargon]" rather than concentrating on the fact that a site is
asking for permission to install and run unsandboxed software on your computer.
 (It also has an extremely vague warning and labels the Install button "Yes".)

Btw, if users think "Signed by foo" implies "safe", I'd expect malicious sites
to sign XPIs even when it's optional.  Ben Bucksch, are you arguing for removing
the signing capability from XPI altogether?

	Ben Bucksch (:BenB)
	Comment 3 • 21 years ago

> Ben Bucksch, are you arguing for removing
> the signing capability from XPI altogether?

No. But as-is, I think it's only really useful for advanced users. Maybe we
could remove the newbie confusion, if we removed the word "signed" and just said
"Do you fully trust <source>?", where source is either the cert owner (if
correctly signed) or the hostname (if not signed).

(There are may be schemes thinkable where it's more useful for newbies, e.g.
Mozilla being CA and actually checking trustworthyness of signers, not just the
name, but I'm not sure that's feasible and I guess it's offtopic here.)

	Doug Turner (:dougt)
	Comment 4 • 21 years ago

On ben's points:

A) a signed install is much more secure in the sense that you proof of who the
author or distributor is.  I am not going to play any sementic games without
regarding the term "secure".  

B) mozilla.org, mozdev.org, or other organization can verify the claim that some
set of bits are a "trusted" extensions to the product and sign the install.

Our experiences with security dialogs is that the user just clicks through.  So,
assume that any scary dialog will just be viewed as cruft in the way of what the
user already had determined she/he wants to do.

Doug

	Daniel Veditz [:dveditz]
	Comment 5 • 21 years ago

One serious flaw of the current signed-XPI implementation is that there is no
way to view the certificate details. Even knowing what CA would be a help.

Signing is a good feature, but it was not an accident that when we reimplemented
Netscape 4.x's SmartUpdate as XPInstall we dropped the signing requirement.  How
many SmartUpdate .jar's did anyone ever see?  Granted, a large part of .xpi
popularity has to do with how much easier it is to create something useful and
interesting for Mozilla than Communicator, but that's not all of it.

	Daniel Veditz [:dveditz]
	Comment 6 • 21 years ago

I wouldn't mind changing the confirmation dialog to make unsigned packages look
scarier, but this one is WONTFIX

	Doug Turner (:dougt)
	Comment 7 • 21 years ago

I think the intention was that the cert info wasn't going to be looked at by the
typical user.  Also, it was a hope that we wouldn't just drop every wanna-to-ba
ca into mozilla's ca list.  

	Jean-Marc Desperrier
	Comment 8 • 20 years ago

I read the commenst against signing on this bug, and I think they are fighting a
strawman when they say signing is no good WRT what can be done to make signed
xpi work well.

- XPI *needs* security
- white-listing has a number of problems regarding scaling, and in order to both
really control the site in the list, but not close the xpi door to outside parties.
- Signing can be a solution to this problems, but it requires to implements a
number of things to avoid the problem current code signing implementation have.
Namely :
 = Strictly control the CA that can sign XPI archive. Maybe configure the
install so that only one Mozilla controlled CA can sign them. Not allow user to
add a CA to this list through ordinary preferences.
 = Offer certs for free. If the CA that can emit them is Mozilla controlled,
this is no problem. For free doesn't mean instantly, and a framework where the
requester must first say who he is, what the extension he develops is, and show
the extension at least partially exists could be a solution (specific bug entry
in Mozilla ?). Before that stage, developer would have a method to allow their
install to load unsigned XPI (Codebase Principals)
 = Have revocation and make sure revocation is disseminated. How ? Have the CRL
manager be preconfigured to update the Mozilla CA CRL. Make it available for
update through a single click on the main page of Mozilla-user popular sites
(mozilla.org, mozillazine, etc...). Block XPI install if there's not a
reasonnably up-to-date CRL available (with an 'explanation'/'link to crl' pop-up).

I'm not completely sure about that point, but a central place for XPI signing,
developer only owning a authentication that enables them to send their code for
automated signing, coud be worth the hassle. 
It would enable to insert a secure time-stamp in the signature (useful to allow
XPI to be still valid after cert expiration), and it would make sure that all
signed xpi can be reviewed, so that it's a lot harder to create an evil XPI that
is not noticed and whose signing cert is never revoked.

	Nelson Bolyard (seldom reads bugmail)
	Comment 9 • 20 years ago

I would add that the attitude of avoiding security measures because they 
make more work for the developer is what got IE into its present situation.

	Daniel Veditz [:dveditz]
	Comment 10 • 20 years ago

Reopening for further discussion.  If we did this it would have to be in such a
way that we don't kill off the explosion of creativity and goodwill in the
extension community. Perhaps a hidden setting, like codebase principals for
signed scripts, which would let developers create and share unsigned installs.

The cost of a cert is no roadblock to folks installing keyloggers and sending
your bank password off to Russia; it's an insurmountable barrier to many broke
college students who otherwise have the time and energy to create something cool.

	HJ
	Comment 11 • 20 years ago

XPI signing is a nice thing indeed. Hey, I even made a few hundred, if not a
thousand XPI's by now, but you need better documentation to start with.

Also, signing XPI's is just one thing, but what about all security patches that
go into the mozilla source code, but are left alone by most extension developers?

Note that I have to do a lot of hunting to get to this kind of information, and
that doesn't help people like me..

	Nelson Bolyard (seldom reads bugmail)
	Comment 12 • 20 years ago

Is there a specification for signed XPI files?  If so, please cite the URL.

It is often said that XPI files are JAR files, but with respect to signed
XPI files, as presently implemented in mozilla, there are a number of subtle
but (possibly) important differences from signed JAR files.  

If we were to seriously consider requiring signed XPI files, I think we
ought to explicitly address some of these issues/questions.  A mozilla
specification for signed XPI files might be the place to do it.  Alternatively,
we might want to reconsider the differences between signed XPI and JAR files.
Either way, I think this bug is the right place to raise these issues and
questions.

Various versions of Sun's Jar file specification may be found at 
http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Signed%20JAR%20File
http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#Signed%20JAR%20File

The JAR file specification allows multiple signatures.  It allows signatures
to sign mere subsets of the JAR file.  It allows parts of the JAR to be
separately signed.  Any given file in the JAR may be signed zero, one, or
more times in a JAR file.  

Multiple signatures were intended to allow a single JAR file to contain 
signed Java classes from multiple sources, each signed by their creator,
and a signed Java applet that uses those classes, signed by its creator,
without requiring the applet's creator to sign the other creators' classes.

Each signature is effectively represented by two files, the .sf file (which
specifies the subset of the manifest that is signed by a particular signature,
and hashes of those files), and the .rsa (or .dsa) file that contains the 
actual signature of the info (including the hashes) in the corresponding .sf file.  

IIRC, it is possible to combine the contents of two signed JAR files into a 
single JAR file containing two signatures, in which some files are signed 
with one signature, some files are signed with the other signature, some 
files are signed with both signatures, and some files are unsigned.  This 
can be done without re-signing any of the files, and without a special 
signature tool (ordinary text editor and zip tools suffice).

IINM, mozilla's present implementation of signatures on XPI files requires
that a .rsa file (or .dsa file, the file containing an actual signature)
come first.  It seems to decide whether the JAR file is signed (or not) 
based on its processing of that first signature file.  This has some 
implications and raises some questions.  Here are some of the questions.

a) Does it require that ALL the JAR's files be signed by that one signature?
b) Does it permit (and verify) multiple signatures, with no one signature 
   signing all files?
c) Does it detect the presence of files that are not signed by any signature?
d) Does it install unsigned files from a JAR in which some files are signed?

I'd guess that the present implementation only verifies one signature.  
If that is so, then I'd *HOPE* that it checks that all files in the JAR
are indeed signed by that signature.

If mozilla some day requires signatures on XPI files, then I'd ask:
Does mozilla *intend* to require that all files in the JAR be signed with a
single signature? And if so, will this intent be enforced?

	alanjstr
	Comment 13 • 20 years ago

With UMO pumping out so many extensions each day, it would be good to know that
the mirror network that we use is trusted.  

We have about 1300 authors with accounts (500 extensions).  That's a lot of
certificates.  

I think we can all acknowledge that people tend to just click-through.  I do
like what Microsoft does in these situations, both for drivers and for installers.

This could be further restricted to "only trust MyCompany.com as a signer" which
would be good for corporations.

http://www.mozdevgroup.com/docs/pete/Signing-an-XPI.html

	Benjamin Smedberg
	Comment 14 • 19 years ago

*** Bug 265358 has been marked as a duplicate of this bug. ***

	Mike Kaply [:mkaply]
	Comment 15 • 13 years ago

If signing did something more than just verify identity, this might be worthwhile.

As it stands, if I sign an XPI, install it, modify the XPI, restart Firefox, the XPI still works fine.

So the core purpose of signing (avoiding tampering) doesn't work on Firefox.

	Dave Townsend [:mossop]
	Comment 16 • 13 years ago

(In reply to Michael Kaply (mkaply) from comment #15)
> If signing did something more than just verify identity, this might be
> worthwhile.
> 
> As it stands, if I sign an XPI, install it, modify the XPI, restart Firefox,
> the XPI still works fine.
> 
> So the core purpose of signing (avoiding tampering) doesn't work on Firefox.

The core purpose of signing is to verify the author of the XPI. The only way it could also avoid tampering is if we did exactly what this bug suggests and only installed add-ons signed by valid certs.

	Mike Kaply [:mkaply]
	Comment 17 • 13 years ago

But what about tampering after the install? Since in most case with Firefox 4 and beyond, the XPI is still intact, should Firefox recheck to make sure the XPI is still valid?

I thought tampering was one of the purposes of signing as well, otherwise why does the signing depend on the structure of the XPI?

	Ben Bucksch (:BenB)
	Comment 18 • 13 years ago

> But what about tampering after the install?

That was never the purpose. The purpose is to protect the user from malware and outright security attacks that modify binaries between their author and the time of installation.

You are trying to protect against users or programs running on the user's machine and who have the ability to modify the binaries. Such attempts are bound to fail, as they can always modify Firefox protection code (or cert database), too. In fact, exactly that is happening in practice. With current Windows/Mac/Linux, it is *impossible* to protect against other applications on the same machine. It's useless to even try, and we won't.

	Dave Townsend [:mossop]
	Comment 19 • 13 years ago

(In reply to Michael Kaply (mkaply) from comment #17)
> But what about tampering after the install? Since in most case with Firefox
> 4 and beyond, the XPI is still intact, should Firefox recheck to make sure
> the XPI is still valid?

We've talked about doing this, it's possible even if the XPI is unpacked. I'm not really sure of the point though. If something has managed to modify the files on your machine then you're in trouble that we can't do much about already.

> I thought tampering was one of the purposes of signing as well, otherwise
> why does the signing depend on the structure of the XPI?

The entire contents of the XPI is signed so that we can say for sure that it hasn't been modified since the author signed it and therefore the XPI was totally created by the author. But signing an XPI doesn't stop people from tampering with it since I can easily take a signed XPI, remove the signature and tamper with it to my hearts content. What I cannot do is make that XPI still appear to be signed by the original author.

	Mike Kaply [:mkaply]
	Comment 20 • 13 years ago

Yeah, I'm not even thinking.

 A malicious app could simply unzip the XPI, remove all the signing information and rezip and Firefox would be none the wiser.

Going back to the original subject of this bug, requiring signing and obtaining certs for all add-on developers would certainly be an undue hardship.

Google solves this problem by signing everything on the store end and by requiring developers to pay $5 to sign up to participate in the store, verifying the identity.

	Jonathan Watt [:jwatt]
	Comment 21 • 6 years ago

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)