Julien Pierre wrote:
Michael,
Michael Kaply wrote:
The profiles are 100% conmpatible except for the hardcoding of the DLL.
See:
http://bugzilla.mozilla.org/show_bug.cgi?id=176501
I'm not going to change the name of secmod because of a security bug.
You guys need to fix the security bug. Or make the DLLs somehow compatible at a binary level regardless of the compiler.
176501 is not the same as the OS/2 issue. You should file a different bug.
PKCS#11 DLLs on a given OS are supposed to be compatible at the binary level. Per the PKCS#11 specification, the functions in each PKCS#11 library, including nssckbi.dll should use the common C calling convention for each operating system. On OS/2, that should probably means _System .
This is similar to third-party Netscape plugins : in order to preserve binary compatibility, so that plug-ins can run in Mozilla and older versions of Netscape Navigator and Communicator, you have to use a common calling convention.
I believe you preserved the same calling convention for browser plug-ins on OS/2 between Navigator 2.x, Communicator 4.x, Mozilla VACPP, and Mozilla gcc, so that it is possible to create a single plug-in DLL that works with all of them.
The same should have been done for PKCS#11 libraries on OS/2 - with the exception that Navigator 2.x didn't support PKCS#11 - PKCS#11 support added in Communicator 4.x . That is not a security issue, that is an OS/2 porting issue.
All Netscape plug-ins use the same calling convention on Windows. And all PKCS#11 DLLs use the same calling convention also on Windows, including not just nssckbi.dll but also third-party smartcard PKCS#11 DLLs, which are binary compatible between all versions of Mozilla, and other PKCS#11 applications. You can even load Mozilla PKCS#11 libraries in Communicator if you like, since it also supports the PKCS#11 specification.
The problem on OS/2 is that somehow, you ended up building nssckbi.dll with different calling conventions for GCC and VACPP builds of NSS in Mozilla. Something was overlooked during the OS/2 port of NSS - the fact that PKCS#11 is an interface for third party code, and not only for Mozilla's own code. That is not a security bug, but a problem with the two OS/2 ports.
Luckily, that change of calling convention doesn't have a big impact on OS/2 except for the need to delete secmod.db, since to my knowledge, there are no third-party smartcard PKCS#11 drivers available for OS/2 . If there were, then they would work only with either VACPP or gcc builds, and that would be a much bigger problem than simply deleting secmod.db .
For example, on Mac OS X, there are several ways to build dynamic libraries - Mach-o and dylib . I believe you can't build a single library that work with both. At some point, Mozilla chose to switch from one to the other. That means that smartcard vendors have to provide several verions of their PKCS#11 libraries if they want to be compatible with the different versions of Mozilla and Netscape 7 browsers on Mac OS X, and so do plug-in vendors. That's a much bigger inconvenience to developers and users of smartcards than having to delete secmod.db. The developers have to build two versions, and the users have to select the right one to use. And of course the profiles can't be shared in the same way - though in that case I believe the different versions of libraries referenced in secmod.db or different versions of plug-ins just fail to load, rather than cause a crash, as is the case OS/2 with the versions of nssckbi built with different calling conventions.
Since there arre no existing third-party PKCS#11 libraries on OS/2, you don't have to worry about maintaining binary compatibility with them. You only need to worry about Mozilla's built-in root certs PKCS#11 library, nssckbi.dll .
The way to fix this OS/2 porting problem is to reconcile the VACPP and gcc builds of NSS to use a single calling convention for PKCS#11 libraries.
You could either standardize on the calling convention currently used by the VACPP build, by the gcc build, or choose to use yet another calling convention.
I would personally recommend using _System, since PKCS#11 is only an interface, it does not dictate the language the library is actually written in, so that you should use most common calling convention for each platform. The RSA PKCS#11 committee actually recommends the proper calling convention to use for PKCS#11 libraries on each operating system; but they haven't ruled on the recommended calling convention to use for OS/2 because I think no smartcard vendors support OS/2.
If you choose to standardize PKCS#11 on OS/2 on the VACPP calling convention, then only the gcc builds will have to be changed to use it. That will mean that newer gcc builds will be compatible with all existing VACPP profiles. But the new gcc build won't be compatible with profiles from existing gcc builds; secmod.db would have to be deleted in that case.
If you choose to standardize PKCS#11 on OS/2 on the gcc calling convention (I don't know which one it uses) it's the opposite . Only the newer VACPP builds will have to be changed to use it. That will mean that newer VACPP builds will be compatible with all existing gcc profiles. But the new VACPP builds won't be compatible with existing VACPP profiles; secmod.db would have to be deleted in that case.
You may also consider what calling convention was used for PKCS#11 libraries in the OS/2 port of Netscape Communicator 4.x. Even though you can't share profiles between it and Mozilla, Communicator can load PKCS#11 modules too. Try to load the nssckbi.dll from Mozilla's VACPP or gcc build in it and see if any of them loads. Hopefully, it is not yet a third calling convention that was chosen for it (my guess is that it is VACPP's calling convention). The reason for considering this despite not being able to share the profile between Communicator and Mozilla is that if some smartcard vendor decided to support OS/2 tomorrow; or more likely if somebody decided to port the existing open-source smartcard PKCS#11 drivers such as Muscle to OS/2 (I have considered doing this, but simply never had the time); they would want those new OS/2 PKCS#11 libraries to be loadable in as many OS/2 applications as possible, including both Mozilla and Communicator; and they might not want to produce several sets of libraries for different C calling conventions.
Ultimately, this OS/2 problem comes down to the following : somebody needs to make a decision on which is the standard calling convention to use for OS/2 PKCS#11 libraries. I think Netscape Communicator 4.x and Mozilla are currently the main, if not only, PKCS#11 applications for OS/2. So, it is probably up to us to make that call, and once we have done that, we should inform RSA of our decision, so that it can be added to the default PKCS#11 headers and documented in the PKCS#11 specification, which is available from ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v211/pkcs-11v2-11a1.pdf . You need to have a section 8.3.4 added for OS/2 . Currently, only Win16, Win32 and Unix have explicitly recommended calling conventions . Once the decision is made for OS/2, I can help you make the case for it with the PKCS#11 group to get it added.
If it was up to me, and there was no existing OS/2 PKCS#11 application, I would choose the _System calling convention.
Since there are three PKCS#11 OS/2 applications - Netscape Communicator 4.x, Mozilla VACPP and Mozilla gcc, I would examine the calling conventions used for PKCS#11 in each of them.
If all three are calling conventions different, pick any one of them. My preference would be _System if it's among the three. Your preference might be to standardize on the calling convention currently used in the gcc builds, so that Mozilla profiles would remain compatible between all gcc builds.
If two of the products have a PKCS#11 calling convention in common, pick that one, which will ensure that future PKCS#11 libraries work with the largest amount of OS/2 PKCS#11 applications.
If all three used the same calling convention , we wouldn't be talking about this, so we know that's not the case.
By the way, bug 176501 is about a totally different problem, the fact that different Mozilla builds on Windows automatically share their profiles, including secmod.db, and since secmod.db has a reference to a particular nssckbi.dll, sometimes an nssckbi.dll from a newer or older build is used. That may sound similar to the OS/2 problem, but it isn't. There is no calling convention issue there. The nssckbi.dll in different versions of Mozilla on Win32 all use the same calling convention, and that should be the case even if you built Mozilla with a different compiler on Windows. That means they always load. The problem is that those DLLs contain different sets of root CA certificates. For the most part, that's a non-problem, unless you rely on some of the newest CA certificates added to nssckbi.dll recently and in which case you always want to use the newest version (even if you are running with an older Mozilla build!). The problem is more common on Windows since Mozilla builds there use the registry to automatically locate the profile, and therefore they automatically share it. On OS/2, you have to explicitly add your profile from another version in order to share it.
Once you get the PKCS#11 calling convention standardized on OS/2, then 176501 will be the next problem to deal with.
176501 is something fundamentally wrong with the Mozilla browser's use of NSS security databases. NSS was not designed to allow sharing its security databases between different versions of applications. That is not a bug, it is by design. The security databases are supposed to belong to one application, running a particular version of NSS. They should not be shared by multiple applications with different NSS code.
If an application insists on doing that, it must take extra precautions, and the fix would belong in PSM. In that case, it could query the entry for nssckbi.dll in secmod.db, unload that nsskcbi.dll, delete it, and then add the nssckbi.dll from the current build and load that nssckbi.dl .
secmod.db isn't the only database that can't be shared in Mozilla
For example, it just so happens that the certificate database format didn't change for a long time. From NSS 2.6 (1999) until NSS 3.6, the same cert7 and key3 database format was used, so this problem did not surface.
Recently, in NSS 3.7 (releasd in late 2002), we rev'ed up the database format to cert8 . If you create a profile with current Mozilla code, you will have a cert8.db, with all your personal certificates in them.
If you then load a 2-year old version of Mozilla on the machine and share the same profile, that version will look for a cert7.db, won't find one, and will therefore create its own, new cert7.db .
Most people don't have personal certificates, so they won't notice this, and think everything is OK, but it isn't.
The fact is, we only support upgrading the profiles to the latest version. Current NSS code will first try to load a cert8.db . If it doesn't find one, it will look for a cert7.db, and upgrade it to cert8.db .
There is no migration path for rolling back from cert8.db to cert7.db . No code currently exists to do that automatically.
I'm sure the same is true for many other databases in Mozilla. There is upgrade code, but not downgrade code . And how could there be, since when you downgrade your code, by sharing your upgraded Mozilla profile with an older version of the code, by definition that code was written earlier, and doesn't know anything about the new format ?
Similarly, you don't expect to be able to read Word 2003 files in Word 1.0 for DOS. You would expect the opposite. Word 2003 can't export docments to Word 1.0 for DOS format. So, you can't share your documents between the two. It's the same thing with Mozilla profiles. You can upgrade to the latest version, but you can't downgrade. Sharing is a no-no .
What Mozilla is doing on Windows - saving profiles in the registry, and having any version of the code load the same profiles automatically - is a big no-no, in my opinion, because the format of files in the profiles is not static; it may change between any 2 Mozilla builds. They know that no downgrade code exists for the profile, for security databases or other databases. Often, even their upgrade code is broken, and files must be deleted ! In comparison, NSS has been very good about always being able to upgrade the security databases cleanly to the latest version.
At least on OS/2 you have to do a manual operation to share profile. You have to enter the pathname of the existing profile. You could add some code there in the profile manager to systematically delete the old secmod.db . That would solve 99% of the problem - the upgrade case.
For the downgrade case, there is no clean solution, but that's never been officially supported.
_______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
