88280 - (JA) PSM: Messed up order and missing/english text in Device Manager dialog

Status: VERIFIED FIXED

(Core Graveyard :: Security: UI, defect, P2)

Description

[Andreas Becker]

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 [e-mail] 2001-06-14 15:10:34 ----

Created an attachment (id=1864)
Screenshot of JA Device Manager dialog




------- Additional Comments From [e-mail] 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 [e-mail] 2001-06-14 15:19:54 ----

Created an attachment (id=1865)
Screen shot of JA Device Manager (FIPS enabled)




------- Additional Comments From [e-mail] 2001-06-28 10:15:05 ----

reassigning to rchen



------- Additional Comments From [e-mail] 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 [e-mail] 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.

Comment 1

[Andreas Becker]

Attachment: Screen shot of JA Device Manager (FIPS enabled)

Comment 2

[Andreas Becker]

Attachment: Screenshot of JA Device Manager dialog

Comment 3

[Andreas Becker]

Adding nsbeta1 and l12y keyword.

Comment 4

[Stephane Saux]

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

Comment 5

[Andreas Becker]

We are awaiting a new Japanese build within the next few days.  Changing QA
contact to [e-mail].  Xianglan, can you retest this once we received the
new Japanese build?

Comment 6

[ji]

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

Comment 7

[ji]

Confirmed the bug.

Comment 8

[msanz]

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

Comment 9

[tao]

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.

Comment 10

[tao]

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.

Comment 11

[Ian McGreer]

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.

Comment 12

[tao]

> 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 ?

Comment 13

[Robert Relyea]

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

Comment 14

[tao]

> 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.

Comment 15

[Robert Relyea]

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

Comment 16

[Stephane Saux]

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

Comment 17

[Stephane Saux]

future

Comment 18

[Cindy Roberts]

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.

Comment 19

[elaineking]

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

Comment 20

[ji]

Nominating for nsbeta1.

Comment 21

[ji]

Attachment: A Japanese pipnss.properties file for debugging use.

Comment 22

[John Unruh]

nsbeta1+

Comment 23

[Stephane Saux]

The fix to bug 90956 should solve this problem.

Comment 24

[Kai Engert (:KaiE:)]

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

Comment 25

[ji]

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

Comment 26

[Guangyan Liu]

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