Questionmarks for chiper size, type, hash, and other values about cipherfox

[gavinhungry]

Seems to work fine here. Firefox 45.0.1, Arch Linux, CipherFox 3.13.0. What does your formatting string look like? I'm assuming it's been left on the default.

[Cai0407]

Also seems to work fine. Firefox 46.0b8, Win 7 Pro x64 Japanese.

[herczegzsolt]

Formatting string left on default:
Cipher: $CIPHERALG $CIPHERSIZE-bit
Certificate: $CERTORG ($CERTALG $CERTSIZE-bit: $CERTHASH)

Problem still persist, currently in firefox 46.0. The main difference is that I'm using hungarian language firefox, should that be the source of the problem?
(Problem exists on different installs - however I'm using the same firefox profile)
If it helps, I'm willing to provide full hungarian translation strings to this addon.

[gavinhungry]

Those strings are not localized, so that seems unlikely to be the root of the problem (however, I would love to have Hungarian strings in CipherFox - you can do a pull request or just open another issue).

Can you try a fresh Firefox profile? Since @Cai0407 and I both aren't seeing this, I'm wondering if it's something else in your existing profile.

[herczegzsolt]

I've just created a fresh and empty firefox profile, nothing but chipherfox installed. Sadly it's not profile related. I'll try it out on a complete fresh install of a hungarian and english ubuntu 16.04 and see what's the difference.

[herczegzsolt]

I'we done some testing, and I can confirm the error is related to the hungarian translation.

Try the following things:

1. Install hungarian language to firefox (apt-get install firefox-locale-hu)
2. set intl.locale.matchOS to false
3. set general.useragent.locale to hu-HU
4. restart firefox
   -> Cipherfox produces the "?" errors
5. set general.useragent.locale to en-US
6. restart firefox
   -> Cipherfox works perfect

The error is reproduceable in a fresh install of Ubuntu 16.04 in virtualbox. (I can provide vbox images)
I wasn't able to reproduce the error on Windows 7 + Hungarian Firefox.

(PS: Please find the pull request with translated strings)

[herczegzsolt]

After further investigation, it's clear that only $CERTALG, $CERTSIZE and $CERTHASH variables are affected.

For me, it seems to be a problem getDisplayData() on certDmp. Maybe, it has sligtly different return values based on locale? @gavinhungry Could you please point me towards the related documentation, so I could debug and maybe patch it?

https://github.com/gavinhungry/cipherfox/blob/master/content/cipherfox.js#L200

[gavinhungry]

@hzsolt94,

I think I've found the issue here. I compare the string from getDisplayData (which I assumed were localized, but they may not always be) to the strings in chrome://pipnss/locale/pipnss.properties (which are localized).

For example, getDisplayData(11) could return PKCS #1 RSA Encryption, which I compare to GetStringFromName('CertDumpRSAEncr'). But for hu-HU, the string there is PKCS #1 RSA titkosítás, so there's no match.

I'll see if these strings are never localized, or sometimes localized (the latter of which would cause more trouble). We can then always (or sometimes) compare the returned strings to the English locale, if I can find a way to access it.

[gavinhungry]

I found the English strings in:
jar:file:///usr/lib/firefox/omni.ja!/chrome/en-US/locale/en-US/pipnss/pipnss.properties

But that's obviously fragile and not portable at all. I'd like to find a programmatic way of getting that location.

[herczegzsolt]

Sadly, I don't have experience in developing firefox extensions, so I don't really know a way to get those english strings, i'm sorry. However PKCS #1 RSA titkosítás is a valid translation of PKCS #1 RSA Encryption, so you're perfectly correct.

I'll try to install your extension from github and report if it makes a difference.

[gavinhungry]

The alternative is to hard-code the English strings into CipherFox, but that's a last resort (or maybe it's a temporary fix, but my "temporary" fixes are usually permanent).

[herczegzsolt]

What about using a hard-coded regex for getDisplayData ? It sounds a bit quick&dirty but I think PKCS #1 RSA (and the other specifications) will hardly ever change in any localization. I think that's one of the most portable ways you could do it.

[gavinhungry]

@hzsolt94,

en-US:

CertDumpECPublicKey=Elliptic Curve Public Key

hu-HU:

CertDumpECPublicKey=Elliptikus görbéjű nyilvános kulcs

That's going to be hard to match with a regex.

[gavinhungry]

@hzsolt94,

Can you try this with Firefox set to the hu-HU locale?

• Set devtools.chrome.enabled in about:config to true.
• Open the Browser Console with Ctrl+Shift+J.
• Enter the following into the console:

var dirService = Components.classes['@mozilla.org/file/directory_service;1']
  .getService(Components.interfaces.nsIProperties);

var omniPath = dirService.get('GreD', Components.interfaces.nsIFile);
omniPath.appendRelativePath('omni.ja');
window.open('jar:file://' + omniPath.path.replace(/\\/g, '/') + '!/chrome/en-US/locale/en-US/pipnss/pipnss.properties');

That should open the strings from the en-US locale.

[herczegzsolt]

Tested on Ubuntu, it opens:
jar:file:///usr/lib/firefox/omni.ja!/chrome/en-US/locale/en-US/pipnss/pipnss.properties
Contents: https://gist.github.com/hzsolt94/65306d489300ebc10bf346c4ed879c8d

Tested on Windows 7, it wants to open:
jar:file:///C:/Program%20Files%20%28x86%29/Mozilla%20Firefox/omni.ja!/chrome/en-US/locale/en-US/pipnss/pipnss.properties
But the browser displays a file not found error.

Both Firefox 46.0.1 hu-HU

[gavinhungry]

@hzsolt94,

What version of Firefox are you running on Windows 7? That same URL that failed for you opened for me in Firefox 46 on Windows 10. Can you check the C:\Program Files (x86)\Mozilla Firefox directory for the existence of the file omni.ja? If it is there, then the English strings might not exist on your machine at all.

[gavinhungry]

@hzsolt94,

I installed the Hungarian build of Firefox, and the English strings are indeed not included at all. This is opposed to installing the English version of Firefox, then using the Hungarian language pack.

So, I think the only recourse is hard-coding strings into CipherFox.

[herczegzsolt]

@gavinhungry The missing translations makes sense: the missing file error for me was on a Firefox for Windows 7 which is native Hungarian. However Firefox on Ubuntu is always "English first, than localized", that's just the way they package it.

That could be important: I don't think you must hardcode english strings!

On my "native Hungarian" Firefox installations your current extension works like a charm, no bugs!
But, on my "English than localized" Firefox installations, your current extension gives the questionmark errors.

So, I assume that the API you are using could return the certificate type in the language Firefox is installed and not in the language Firefox is used. If that's the case, a good enough solution would be to:

1. check the current language's strings for match
2. if not matched, and there is English translations installed, check English strings.
   3, maybe if not matched, go through all the other installed languages for a match (?)

If my guess is true, you don't need the English strings if they're not installed, because Firefox does not allow removing the installers locale. (It's mostly English) Aside from some pretty extreme installations, that should work all the time. (By extreme I mean for example "installed Hungarian than localized to Chinese", etc. But in these cases, I don't think a hardcoded English string would work.)

Sorry, but I don't have the technological knowledge to test out my guesses. If you could provide me some testing code, I'm happy to run it on differently installed and localized Firefoxes to check how the API works.

[gavinhungry]

@hzsolt94,

I think that you're absolutely right. Hard-coding the English strings will not do any good for a "native Hungarian" install of Firefox, since the strings that come back from the certificate API will be in Hungarian.

So I think step 1 is correct:

1. check the current language's strings for match

This would be the file "chrome://pipnss/locale/pipnss.properties" that we know and love - for this file, you should always get the strings in the locale that Firefox is using, whether it was a "native Hungarian" install or a "English with Hungarian language pack" install.

The strings that come back from the certificate API will be in Hungarian only on a "native Hungarian" install. On the English with language pack install, the strings will be still be in English. So we check for the English strings.

But what about "Native Hungarian with Spanish language pack"? Step 1 would fail there, since the API strings would be in Hungarian, but the string bundle would be in Spanish. So we don't care about the English strings there - just the Hungarian strings.

In both of your installs, what does intl.accept_languages contain? We may be able to use that to find the appropriate string bundle.

[gavinhungry]

@hzsolt94,

Looks like intl.accept_languages won't work - it matches the language pack. If you have the "native English" Firefox installed, and have the Hungarian language pack installed, I need to a way to know that you originally installed Firefox in English.

[herczegzsolt]

@gavinhungry Just checked: intl.accept_languages are the same regardless of installers languge: hu-hu, hu, en-US, en

I will make a testbed for "Hungarian install with Spanish locale" though, and look through the about:config on all my installs for something like this.

Just rethinking the language selection approach: what if you make your own key in about:config and use that to get the right locale. That way if this kinda "auto-detection" approach fails, the user at least can set it up and get it work.

[gavinhungry]

@hzsolt94,

That's right, but once you activate the language pack, intl.accept_languages will change, and we won't see hu or hu-HU in there any more, which is bad.

Please try this from your Browser Console. You should always get back the locale that you used to install Firefox, ignoring whatever language packs you may have installed or are using.

Try it with:

• Installed Hungarian (should get back hu)
• Installed Hungarian with English language pack in use (should get back hu)
• Installed English (US) with Hungarian language pack in use (should back en-US)

var dirService = Components.classes['@mozilla.org/file/directory_service;1']
  .getService(Components.interfaces.nsIProperties);

var omniPath = dirService.get('GreD', Components.interfaces.nsIFile);
omniPath.appendRelativePath('omni.ja');
var defaultLocalePath = 'jar:file://' + omniPath.path.replace(/\\/g, '/') + '!/update.locale';

Components.utils.import('resource://gre/modules/NetUtil.jsm');
NetUtil.asyncFetch(defaultLocalePath, function(stream, result) {
  if (!Components.isSuccessCode(result)) {
    return console.error('Could not read file');
  }

  var locale = NetUtil.readInputStreamToString(stream, stream.available());
  console.log(locale);
});

[herczegzsolt]

Gives exception for Firefox 46.0.1 on Ubuntu 16.04 (packaged: en, currently: hu)
[Exception... "Failed to open input source 'jar:file:///usr/lib/firefox/omni.ja!/update.locale'" nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)" location: "JS frame :: debugger eval code :: <TOP_LEVEL> :: line 9" data: no]

[gavinhungry]

Hmm, it worked for me on Firefox 46 (Windows) and Firefox 48 (Linux).

[herczegzsolt]

OK, For Windows 7 (FF 46.0.1) it seems working:
HU install, HU locale: outputs hu
HU install, EN locale: outputs hu
Only linux gives the exception (hu locale).
Chipherfox also produces the "? error" on HU install EN locale, which is expected.

I'll test it on more configs soon, I just need to set up some VM's for it.

Ps: Maybe, I was wrong on linux packaging? Looking at about:addons, Firefox (on Ubuntu from the repos) shows English as "installed language" even though Firefox for Windows does not show the installer's language (neither HU or EN) as "installed language".

[gavinhungry]

@hzsolt94,

Try opening /usr/lib/firefox/omni.ja on your Linux machine as a zip file, see if there is an update.locale file present within.

[herczegzsolt]

@gavinhungry No such file. Attaching my omni.ja file list.
omni.ja.files.txt

[herczegzsolt]

@gavinhungry More said news:
The Firefox "Certificate Viewer" GUI window shows the certificate's details in the installers language, not in the current locale. Hovewer buttons and some titles are localised. Knowing that, I think that the API's behaviour which we're currently trying to workaround, is actually a Firefox bug. Maybe, we should open a Firefox bugticket?

To sum it up:

• cipherfox works if the API's language is the currently used language
• the API's language is as-of-now the install language. But it's undocumented and seems buggy, so it may change unexpectedly in the future.
• determining the install language seems to be hard and unreliable

I'm sorry to say so, but I would go the easy way:

1. check the API against the current language
2. if it fails, check the API against all the installed languages in a loop - just accept the first match happening.

This solution is a bit dirty but universal and future-proof. I don't think there could ever be 2 languages where one's RSA string exactly match another's ECC string. And even if those 2 would ever exists, both has to be installed to cause problems...

If the loop is too resource-consuming, maybe cache the language after first found.

[gavinhungry]

if it fails, check the API against all the installed languages in a loop - just accept the first match happening.

That assumes I know all of the installed languages - which I don't, at least not yet.

[gavinhungry]

Try this instead - a little hackier this time:

var dirService = Components.classes['@mozilla.org/file/directory_service;1']
  .getService(Components.interfaces.nsIProperties);

var omniPath = dirService.get('GreD', Components.interfaces.nsIFile);
omniPath.appendRelativePath('omni.ja');
var manifestPath = 'jar:file://' + omniPath.path.replace(/\\/g, '/') + '!/chrome/chrome.manifest';

Components.utils.import('resource://gre/modules/NetUtil.jsm');
NetUtil.asyncFetch(manifestPath, function(stream, result) {
  if (!Components.isSuccessCode(result)) {
    return console.error('Could not read file');
  }

  var manifest = NetUtil.readInputStreamToString(stream, stream.available());
  var pipnssLine = manifest.split('\n').find(function(str) {
    return str.indexOf('locale pipnss ') === 0;
  });

  console.log(pipnssLine.split(' ')[2]);
});

[herczegzsolt]

@gavinhungry This works on Ubuntu too.
en-US for FF on Ubuntu
hu for FF en on Windows 7, originally hu
hu for FF hu on Windows 7, originally hu
Still to test on originally en versions...

[herczegzsolt]

en-US for FF en on Windows 7, originally en
en-US for FF hu on Windows 7, originally en
Seems to work all the time. 👍

[gavinhungry]

Hmm, that last one:

en-US for FF hu on Windows 7, originally hu

Is bad news.

[herczegzsolt]

That's my fault, I just mistyped it. Sorry, fixed.

[gavinhungry]

OK, I can use that, then. Thanks for testing all of these!

I'll still use the localized strings as a fallback, so it shouldn't hurt anything, just help those who have a "native language" installed version of Firefox (like you :)).

[herczegzsolt]

Thank you very much for investigating in my issue! Looking forward to test the updated cipherfox.

[gavinhungry]

I'll probably have a build that you can test sometime in the next hour or so, if you're interested.

[gavinhungry]

@hzsolt94,

Please try:
https://github.com/gavinhungry/cipherfox/releases/tag/4.0.0-beta2

You can install it with the xpi file provided there. You may have to set xpinstall.signatures.required to false first.

[gavinhungry]

One thing I noticed while working with a "native Hungarian" install of Firefox, is that the CipherFox preferences are not localized. Are you seeing that as well?

If not, then perhaps it is just because my system locale is en-US.

[herczegzsolt]

@gavinhungry This "?" issue is solved by the beta build on all my configs. The Hungarian translation does not work for me neither, but it could be a separate issue. (As a reference, Spanish translations do work on the same installs.)

[gavinhungry]

I just realized that I forgot to add hu-HU to chrome.manifest. Closing.

[herczegzsolt]

Thanks. Are there any plans for v4.0?

[gavinhungry]

It should be published to AMO soon, but you can get it now here:
https://github.com/gavinhungry/cipherfox/releases/tag/4.0.0

[gavinhungry]

@hzsolt94,

CipherFox 4.0.0 is now live on AMO:
https://addons.mozilla.org/en-US/firefox/addon/cipherfox/