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

VERIFIED FIXED in Future

Status

P2
normal
VERIFIED FIXED
17 years ago
2 years ago

People

(Reporter: andreasb, Assigned: ddrinan0264)

Tracking

({l12y})

1.0 Branch
Future
x86
Windows NT

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

17 years ago
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.

(Reporter)

Comment 1

17 years ago
Created attachment 40509 [details]
Screen shot of JA Device Manager (FIPS enabled)
(Reporter)

Comment 2

17 years ago
Created attachment 40510 [details]
Screenshot of JA Device Manager dialog
(Reporter)

Comment 3

17 years ago
Adding nsbeta1 and l12y keyword.
Keywords: l12y, nsbeta1

Comment 4

17 years ago
Many of the dialog have been tweaked since the last comment on this bug. Is the 
problem still showing up?
-> move to PSM
-> ddrinan
Assignee: javi → ddrinan
Status: NEW → UNCONFIRMED
Component: Browser-General → Client Library
Product: Browser → PSM
Target Milestone: --- → 2.1
Version: other → 2.0
(Reporter)

Comment 5

17 years ago
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?

QA Contact: ylong → ji

Comment 6

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

Comment 7

17 years ago
Confirmed the bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 8

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

Comment 9

17 years ago
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

17 years ago
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

17 years ago
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

17 years ago
> 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

17 years ago
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

17 years ago
> 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

17 years ago
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

17 years ago
adding nsenterprise to all P1, P2 PSM bugs with target milestone of 2.1
Keywords: nsenterprise

Updated

17 years ago
Keywords: intl, nsBranch

Updated

17 years ago
Keywords: intl

Updated

17 years ago
Keywords: nsenterprise → nsenterprise+

Comment 17

17 years ago
future
Target Milestone: 2.1 → Future

Updated

17 years ago
Keywords: nsenterprise+

Comment 18

17 years ago
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.
Keywords: nsbranch-

Comment 19

17 years ago
removed keyword nsbranch since bug now has nsbranch-, per pdt mtg.
Keywords: nsbranch

Updated

17 years ago
Blocks: 104166

Updated

17 years ago
Blocks: 107067

Updated

17 years ago
Keywords: nsbranch-

Comment 20

17 years ago
Nominating for nsbeta1.
Keywords: nsbeta1

Comment 21

17 years ago
Created attachment 58389 [details]
A Japanese pipnss.properties file for debugging use.

Updated

17 years ago
No longer blocks: 107067

Comment 22

17 years ago
nsbeta1+
Keywords: nsbeta1 → nsbeta1+

Comment 23

17 years ago
The fix to bug 90956 should solve this problem.

Comment 24

16 years ago
Marking fixed as per Stephane's comment. Please verify.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Updated

16 years ago
QA Contact: ji → gliu408

Comment 25

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

Comment 26

16 years ago
Verified in 2002-08-23 (RTM) JA build
Status: RESOLVED → VERIFIED

Updated

14 years ago
Component: Security: UI → Security: UI
Product: PSM → Core

Updated

10 years ago
Version: psm2.0 → 1.0 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.