Nelson B Bolyard wrote:
Does your software become part of the browser itself, and run in the browser
as a browser extension or plug-in? Or are you merely trying to use the
browser to download a file that will then be installed as a free-standing
Windows application?
It's not part of the browser, and it's not an extension or a plug-in.
All it does is path to the MSI and CAB files stored on the server. These
are downloaded and the installer runs and installs our software. Again,
it's a standalone Windows application.
This is important because the XPI download feature for which NSS's signtool
makes signed JAR/XPI files is intended only for installing files that become
part of the browser itself. It is not intended to be used as a
general purpose installer for Windows software that does not run as part
of the browser.
If you're trying to download a program that does not run as part of the
browser, but runs independently as a separate Windows program, then you
really don't want to use XPI files for that purpose, IMO. In that case,
you just want to download whatever kind of installer package is used by
windows to install the package into windows. You just want to use the
browser as a file downloader, which does not require that they be XPI
files.
As I recall, one of the really important features of InstallShield is its
ability to make packages that will uninstall cleanly after they've been
installed, and can be uninstalled using Windows' "add/remove software"
control panel. Things that are installed as XPIs are managed by Firefox's
addon manager.
This is correct. XPIs are not involved in this process. The browser is
only used as a file downloader, as you said.
So in InstallShield, I set "Browsers to Support" to include Netscape, on
which Firefox was built. As noted, "If you want the installation to
support Netscape Communicator, you must supply certificate information."
So, apparently, InstallShield has a feature to make installers that are
compatible with Netscape Communicator (NC). Firefox (FF) is not built on
top of NC, although it does support many old features of NC. FF is
actively being developed, but AFAIK, Netscape browsers are no longer
being developed and have not been for years now. So, today, you should
be targeting FF, not NC.
I wish it was that simple. The only options in the newest version of
InstallShield are "IE Only" and "IE and Netscape". It does not mention
Firefox explicitly. I could be completely wrong, as I'm not a developer,
but since Firefox was built on Netscape technology and this is the
latest version of InstallShield, this would be the correct option if
it's supported in Firefox at all. Or is that just wishful thinking?
FF has different requirements for installable downloads than NC had.
FF requires XPI files, which are special JAR files. NC required ordinary
JAR files. All XPI files are JAR files, but not all JAR files are XPI
files. NC required JAR files to be signed, IIRC, but FF does not require
XPI files to be signed.
Based on what I've read here, I gather that InstallShield is using a 6+
year old version of NSS to build JAR files for installation by a 6+ year
old NC browser that is no longer made. I was surprised to find that the
documentation to which Kyle pointed me is dated in 2009, yet it still
refers to Netscape and not to Mozilla or Firefox. I gather that
InstallShield is insisting on generating signed JARs because that is what
NC wanted, even though FF does not require them. Perhaps the customers
who are paying for that software should request that it be brought up to
date.
This request is officially in!
Unfortunately, the process is hardly automatic. InstallShield Support
tells me to download NSS, NSPR and extract the packages to the working
directory (Netscape Certificate Path in the last screenshot) and
certutil and signtool will build the certificate in the same directory.
I'm pretty amazed that they didn't at least supply a set of those files
that they have tested and know to work with their own product.
Because of legal issues, InstallShield cannot redistribute third party
software. This is very common (it affects my company as well). However,
that should not stop them from providing solid documentation on the
process, as well as suggesting exactly which versions of the NSS and
NSPR packages to download from Mozilla. My company is very small and we
do this for our customers. I really expected better from a company that
is its industry's leader.
In related news, as of last month, Firefox has become the most common
web browser, beating out IE in market share, 45.5% to 44.8%, according
to http://www.w3schools.com/browsers/browsers_stats.asp
While this is cause for celebration, we all hope that software vendors
will catch up to reality and do their best to add full support for the
best products on the market.
There are (at least) 3 directories involved:
- the directory where the executables and DLLs should be placed,
- the directory where the .db files (e.g. cert and key DBs) should go, and
- the directory which is the "root" of the JAR/XPI file being built.
These should generally all be separate directories. The executables should
go in "Program files", probably in the same directory as InstallShield's
own executables and DLLs. The .DB files should probably go into a directory
somewhere under "My Documents", and the root of the JAR file
should probably go in some "temp" directory. In your case, it's probably
important that the files go wherever InstallShield expects to find them,
but do take care that the DB files don't end up in the root JAR directory
or any subdirectory thereof.
The installer builds a Release Folder, where all of the files go after a
build, whether the process was successful or not. I'm not sure where
the JAR would actually go. It would be created by InstallShield, but it
stops at the point of failure and does not continue the build.
All I should have to do is specify basic info in these 3 Netscape fields
in InstallShield. InstallShield should take care of the rest.
Once you have your code signing certificate and private key properly
installed in the DB files, then it might.
One thing I remember distinctly is that InstallShield was looking
for cert7.db instead of the cert8.db that I had created with a newer
version of NSS, thus prompting the downgrade.
:( That's most unfortunate, IMO. If there was a problem with signtool,
you can be sure that any new "fixed" version would not work with cert7,
but would work with cert8 or cert9.
InstallShield came packaged with a Microsoft version of signtool, so I
made sure to get the Netscape version, shown here:
:(
InstallShield Support doesn't feel like working with me again until I've
verified that the process is working manually.
:( IMO, it is reasonable that you would supply your own code signing cert
and private key, but beyond that...
A couple of days ago, I got to the point where I successfully created a
test certificate using the syntax previously mentioned, but signtool
failed to sign it. I specified the working directory using -d .
-d specifies the directory where the DBs live, but after that you must
also supply the name of the directory that is the root of the files to
be placed into the generated JAR.
I've tried a temporary folder, something like -d c:\buildhereplease but
signtool gave me the same old usage directions.
Thanks again!
David
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
