I'll attach a patch that will update PSM to include the human readable strings for new NSS error codes. FYI, I used the code from bug 329017.

Axel: The patch contains changes to 2 files. The change to file nsNSSErrors.cpp is sufficient to have the error pages show the string identifiers for the new error codes. Without the changes to file nsserrors.properties, the error page will mention the error code, so the changes to nsserrors.properties could be left out, if necessary on stable branches. When including the changes to file nsserrors.properties, the error page will display both the error code and the human readable explanation. Axel, do you have a preference what should be done about branches, assuming we will add bug 535649 to (at least) Firefox 3.6 ? Is adding to en-us only acceptable? I believe localized builds will display the error code, but not the human readable explanation.

must wait for 537356 to get completed, because it will add yet another error code string.

Comment on attachment 422121 [details] [diff] [review] Patch v1 will create another patch once the new string is final

We need this patch for the renegotiation error page.

Comment on attachment 425335 [details] [diff] [review] Patch v2 r+

Kai, what does this mean please? Is there a typo? SEC_ERROR_INVALID_POLICY_MAPPING=Policy mapping contains anypolicy

Looking at other strings in nsserrors.properties, it seems like you forgot to add trailing dots to those messages, haven't you?

(In reply to comment #8) > Kai, what does this mean please? Is there a typo? > > SEC_ERROR_INVALID_POLICY_MAPPING=Policy mapping contains anypolicy I double that. This string and the next one (below) are totally impossible to understand, at least for me. Could anyone explain their meaning in human-understandable terms? SEC_ERROR_POLICY_VALIDATION_FAILED=Cert chain fails policy validation

Cedric, Rimas: The error messages are "technical", they have been written by the developers who produce our security library NSS. I agree those error messages are not understandable for end users, however, they are intended to be forwarded to technical staff. These error messages will be shown on an error page where there is additional information like "connection to secure site failed, please contact admin, exact reason is: (...)"

Kai: we're supposed to localize (translate) those messages. Hard to do that without understanding them. Could you help?

How exactly does that look?

I assume "anypolicy" is a fixed term that shouldn't get translated. A certificate can contain a policy listing, saying, this certificate was issued in accordance with policy abc123... I'm guessing, the error means, a policy listing that uses the "wildcard anypolicy" doesn't make a lot of sense and NSS might complain about it. Maybe Nelson can explain better. Regarding the second error message, it's not sufficient if a single certificate lists a policy. It must be allowed to list that policy. In order to be allowed, the trusted issuer certificate (root or CA certificate) must allow it. So, if you get the second error message, the policy is not effective, because NSS concluded it's not allowed to use the policy. Please note that those error messages were copied one-by-one from upstream NSS library. If we want to improve them, we should get upstream to change them. For "Policy mapping contains anypolicy" we might enhance it as "A certificate policy mapping contains the inappropriate value 'anypolicy.'" For "Cert chain fails policy validation" we might enhance it as "A certificate specified a policy that could not be validated using any certificate chain" But in general, my guess is, if you look at the existing list of error codes and their explanations, you'll probably find a lot of them which are difficult to understand for end users.

(In reply to comment #13) > How exactly does that look? The error page will say the following: =============== Secure Connection Failed An error occurred during a connection to <hostname>. <specific error message>. (Error code: <error code>) The page you are trying to view can not be shown because the authenticity of the received data could not be verified. Please contact the web site owners to inform them of this problem. Alternatively, use the command found in the help menu to report this broken site. =============== For example, error code will be displayed as SEC_ERROR_POLICY_VALIDATION_FAILED and error message will be displayed as Cert chain fails policy validation

I'm leaning towards having those messages not translatable, or to at least put a HUGE DONT_TRANSLATE sticker all over it. These strings are not really end-user facing, and the language the user uses might not have anything to do with the native or tech language of the webmaster in question.

In reply to comments 8-14, For SEC_ERROR_INVALID_POLICY_MAPPING, the user-facing message is: Whoever created this certificate Fsck'ed up. Make him stop using OpenSSL. Better yet, get a certificate from a competent Certificate Authority. The message "Policy mapping contains anypolicy" should be entirely sufficient for any competent CA to them them what was wrong. More verbosely, there is a wildcard policy identifier named "anypolicy". It is not allowed to appear in policy maps. If we find it in a policy map, we rightly complain. For SEC_ERROR_POLICY_VALIDATION_FAILED, the simplified user facing message could be: The certificate chain is not valid for the requested policy. The more complete message might be: No certificate chain could be constructed that was valid for the requested policy. IINM, today in the browser the "requested policy" is typically the "EV" policy, so we might say "valid for EV" instead of "valid for the requested policy", but if PSM ever starts handing any other policy that EV, then the message would be wrong if it specifically mentioned the EV policy.

One more thing: the meaning of "policy" is quite unclear so far. Could you please supply some synonyms to it? OTOH, if these strings are DONT_TRANSLATE, I could leave them as is. But I don't see why they're stored in a localizable file then...

(In reply to comment #16) > I'm leaning towards having those messages not translatable, or to at least put > a HUGE DONT_TRANSLATE sticker all over it. > > These strings are not really end-user facing, and the language the user uses > might not have anything to do with the native or tech language of the webmaster > in question. On the other hand, all the other existing strings have already been included in the localization process.

I didn't expect yet another error code addition last minute to 3.12.6, but no problem, let's include it. Will add an incremental patch.

(In reply to comment #19) Kai, I agree with you. If localizers don't want to localize these strings, this is up to them. But these kind of strings have always been localizable and should remain, imo. So, once and a while, some of us will bother you for very non-understandable strings for non-techies in the area of security :) . As far as I remember, this is the first time and you shouldn't be bothered too much on this in the future. These strings are very technical and even translated, non understandable for normal human beings :D . Some locales chose to not translate these, some, like the French locale, always did because this is unbearable for our fellow French speaking citizens to have something not translated in a French localized software. My guess is that they won't understand either the en-US nor the fr string, but they won't feel offended because the string is localized (this should be the same for other locales). Well, sorry for the noise, this comment will close this already RESOLVED FIXED bug. Thanks for your patience.

FYI, I've filed bug 545755 for a combined landing of all pieces that are required to implement RFC 5746, into stable branches. If you'd like to make a final decision for landing or not landing, please state your decision in bug 545755. Approval flags have been requested in that bug.

Comment on attachment 427011 [details] [diff] [review] incremental Patch v3 r=wtc.