Add an error type that detects mitm attacks. The error is handled like any other unknown issuer for now. We first want to see how this behaves.
Comment on attachment 8964551 [details] mitm detection v0.0.1 Johann Hofmann [:johannh] has approved the revision. https://phabricator.services.mozilla.com/D839
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/9f177350741f mitm detection v0.0.1, r=keeler,johannh
Comment on attachment 8964551 [details] mitm detection v0.0.1 David Keeler [:keeler] (use needinfo) has approved the revision. https://phabricator.services.mozilla.com/D839
I was going to open a needinfo about the hard coded Firefox, then decided to take a look at Phabricator. > I'm not really concerned about this right now as it's not displayed. Two considerations: * You might not display it anywhere, but you're asking about 100 languages to localize it nonetheless. I'm not saying you can't do it, but it's nice to be aware of it as part of the general picture. * When this string will change, you will need a new string ID. Given these string IDs are internal errors, will that be technically possible? i.e. map an error code to a different string ID for the message.
> When this string will change, you will need a new string ID. Given these string IDs are internal errors, will that be technically possible? Yes, the error code and the error string are independent.
Franziskus, it's important that localization strings not be hard-coded to say "Firefox". For one, shared code is also used by non-Firefox products (e.g. Thunderbird). Second, for different Firefox channels (Nightly, Dev Edition, Beta) we generally want to say specifically what channel it is. Since we can't actually put a placeholder in these specific strings for the product name, we typically phrase error messages in a way that is generic and not specific to Firefox. Please update the error message added in this bug to reflect this. Again, I realize that we're not exposing this string to the front end *right now*, but if we ever do, we don't want to have painted ourselves into a corner by having a string that says the wrong thing that is difficult to update. Note that the difficulty in updating these strings comes from how we translate from the error code to the localization identifier. For most errors we obtain the l10n identifier by passing the code to PR_ErrorToName, which conventionally turns SOME_ERROR_CODE_IDENTIFIER into "SOME_ERROR_CODE_IDENTIFIER". There is a way to override this (or we could break the convention), but it's rarely done and if we forget to do it, we'll end up with the wrong string. Let's make our future selves have an easier time by doing the right thing now.
a year ago
Comment on attachment 8966503 [details] Bug 1450967 - MITM error string update David Keeler [:keeler] (use needinfo) has approved the revision. https://phabricator.services.mozilla.com/D894
Attachment #8966503 - Flags: review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/433871449365 MITM error string update, r=keeler
You need to log in before you can comment on or make changes to this bug.