Build: JA Win Beta1 build 20010607 Steps: 1. In Preferences select category "Privacy and Security/Certificates" 2. Click on "Manage Security Devices" 3. See "Device Manager" dialog shows the following problems for the Security Modules and Devices sections: JA Beta1: NSS Internal PKCS #11 Module Generic Crypto Services - - - - - - Builtin Object Token EN Beta1: Builtin Roots Module Builtin Object Token NSS Internal PKCS #11 Module Generic Crypto Services Software Security Device Note the following: 1) missing text in the JA version displayed by a dash instead 2) Order is different 3) English text ------- Additional Comments From andreasb@netscape.com 2001-06-14 15:10:34 ---- Created an attachment (id=1864) Screenshot of JA Device Manager dialog ------- Additional Comments From andreasb@netscape.com 2001-06-14 15:19:08 ---- After clicking on "Enable FIPS" the order changes, however also the FIPS dialog is messed up (see issues above). Adding screenshot how dialog looks after FIPS is enabled. ------- Additional Comments From andreasb@netscape.com 2001-06-14 15:19:54 ---- Created an attachment (id=1865) Screen shot of JA Device Manager (FIPS enabled) ------- Additional Comments From mcarlson@netscape.com 2001-06-28 10:15:05 ---- reassigning to rchen ------- Additional Comments From rchen@netscape.com 2001-06-28 11:04:58 ---- Reassigned to javi. Andreas, you probably need to move the bug to bugzilla. ------- Bug moved to this database by andreasb@netscape.com 2001-06-28 13:52 ------- This bug previously known as bug 6473 at http://bugscape.netscape.com/ http://bugscape.netscape.com/show_bug.cgi?id=6473 Originally filed under the Browser product and Localization-JA component. --- Unknown bug field "attachment" encountered while moving bug <attachment> <attachid> 1864 </attachid> <date> 06/14/01 15:10 </date> <desc> Screenshot of JA Device Manager dialog </desc> </attachment> --- Unknown bug field "attachment" encountered while moving bug <attachment> <attachid> 1865 </attachid> <date> 06/14/01 15:19 </date> <desc> Screen shot of JA Device Manager (FIPS enabled) </desc> </attachment> Skipping unknown keyword: jaRTM.

Adding nsbeta1 and l12y keyword.

Many of the dialog have been tweaked since the last comment on this bug. Is the problem still showing up? -> move to PSM -> ddrinan

We are awaiting a new Japanese build within the next few days. Changing QA contact to ji@netscape.com. Xianglan, can you retest this once we received the new Japanese build?

Checked the Japanese build based on 07/05 branch build. The problems are still there.

Confirmed the bug.

David, can you take a look and see if you can work on it for this releas? 2.1 seems really late.

It seems to me that "NSS Internal PKCS #11 Module" is hard-wired @ http://lxr.mozilla.org/mozilla/source/security/nss/lib/pk11wrap/pk11db.c#131 I'll investigate more.

I played with the pippki files a bit and couldn't find other strings posted in the bug description field. I suspect this is because they are from external files that not part of the client installation or at least not in the client isntallation directory. Would you please verify that the Chrome part of the Device Manager are from pip*.jar while the text in the tree cells are from external data store? If this is ture we might want to investigate how to make them localizable.

The chrome part is from pippki. The strings are hardwired into the PKCS#11 modules they represent. Bob, is there any way to reset those strings in PKCS#11? I know that you can change the description field in the slot info structure for the internal module and the FIPS module (those strings are localized in pipnss.properties), but can "Builtin Object Token" be modified? Or do we just have to work around that? The problem with a workaround is that it would only be good for tokens we know of. If someone installs a new token, its description string is most likely going to be in english, and we will have no way of localizing it.

> but can "Builtin Object Token" be modified? Or do we just have to work >around that? If the internal string are fixed, we can use the English string as the key to retrieve the localized value from *.property files. If the string retrieval fails, fallover to the English String (which is used as the key). How does this sound? BTW, did you CC Bob ?

Hmmm. Well the internal module strings are setable by the application because the internal module is statically bound in NSS. Vendor supplied PKCS #11 modules will provide strings that are dependent on the vendor. The presumption is the vendor will ship their own internationalized versions of their modules that have the appropriate localized strings. That just leaves the issue with the built-in root token. It's a 'vendor supplied' PKCS #11 module where the vendor is netscape. The string is built into the nssckbi.so file, of which we can have any number of, but currently only have an english version. The PKCS #11 module has to be a stand-alone independent module, so it can't to any properties lookup. PSM could do the properties lookup, and that might get us over this initial step. If we do something like that, it would be nice to have the lookup generic so that PSM would to automatic translation of other vendors names as well (the just have to supply the appropriate national language string). Would it be a problem that the token has embedded spaces. Another issue is when PSM goes to do a lookup on a token or cert it will have to convert the name back to the English string... Another note: Certificates also have English strings in them. I don't think there is much we can do about that. bob

> Hmmm. Well the internal module strings are setable by the application because > the internal module is statically bound in NSS. good >Vendor supplied PKCS #11 modules will provide strings that are dependent on the >vendor. The presumption is the vendor will ship their own internationalized >versions of their modules that have the appropriate localized strings. good. >[snip]... >The PKCS #11 module has to be a stand-alone independent >module, so it can't to any properties lookup. PSM could do the properties >lookup, and that might get us over this initial step. If we do something like >that, it would be nice to have the lookup generic so that PSM would to automatic >translation of other vendors names as well (the just have to supply the >appropriate national language string). Would it be a problem that the token >has embedded spaces. Not at all. StringBundle module allows embedded spaces in the resource key. I verified it on branch build. > Another issue is when PSM goes to do a lookup on a token or >cert it will have to convert the name back to the English string... IMO, we can separate data from display names: we internally work with English strings from the data but pass the localized strings to display name. When selection was made, the corresponding data name is passed back to the app. In fact, this is how theme/locale selector is implemented. >Another note: Certificates also have English strings in them. I don't think >there is much we can do about that. > >bob Agree. However, Certificate providers will eventually, if not already, support localized version of issued certs.Overseas market are growing daily. What we can do now is to at least make ours localizable.

RE: Certs: Up to a point... The problem is those strings are also part of the infrastructure. Verisign could reissue a chineese version of their root cert, but it would not verify a cert issued from their english CA. Typically CA's don't change their root certs, but issue language localized certs to their customers. That way those certs carry local names, but can still be verified by other users. Part of the point, though is the built-in module is full of these english named certs because we need them to interoperate. bob

adding nsenterprise to all P1, P2 PSM bugs with target milestone of 2.1

future

Marking nsbranch- as it was decided in the August bug triage that we wouldn't have enough time in eMojo to fix this. Let's revisit for MachV.

removed keyword nsbranch since bug now has nsbranch-, per pdt mtg.

Nominating for nsbeta1.

nsbeta1+

The fix to bug 90956 should solve this problem.

Marking fixed as per Stephane's comment. Please verify.

QA Contact to Gary. Gary, could your verify this once we get a Ja build with the UI translated? thanks.

Verified in 2002-08-23 (RTM) JA build