I'm getting confused with version numbers. Because Mozilla now releases frequently, I can't remember which version of Mozilla uses which versions of NSPR/NSS. I would like to see a functionality in client applications that can report the library version numbers being used, somewhere in the about:buildconfig. This feature would also help for diagnostic purposes when people use system versions of the libraries. I understand that complete information would be quite complex, because we have multiple libraries, and in theory each one can have its own version number. While we could provide one function for each module, I understand it's more difficult for out libraries that implement the pkcs#11 interface. We probably cannot simply add another function to the .def file and export that new function. Given that I want to simplify life, and given that I want to get it done quickly, with little work, I want to use a compromise. - add a couple of functions to the main NSS library - for the functions that can get implemented quickly, let's do it - for the functions that need more work, return an empty string (meaning: unknown) This way, applications can start to query the version number information, and display the information that's available, and we can provide additional version number information later.

I propose to add the following functions: Implement now: - NSS_UTIL_GetVersion - NSS_GetVersion - NSS_SMIME_GetVersion - NSS_SSL_GetVersion Return empty string for now, implement later: - NSS_DBM_GetVersion - NSS_FREEBL_GetVersion - NSS_SOFTOKN_GetVersion - NSS_CKBI_GetVersion

Clarification: libnssutil3.so -> export NSS_UTIL_GetVersion libsmime3.so -> export NSS_SMIME_GetVersion libssl3.so -> export NSS_SSL_GetVersion libnss3.so -> exports: - NSS_GetVersion * NSS_DBM_GetVersion * NSS_FREEBL_GetVersion * NSS_SOFTOKN_GetVersion * NSS_CKBI_GetVersion For the 4 functions marked with *, I propose that libnss3.so exports the function to obtain the version numbers for the other modules. Given that obtaining those versions numbers is more difficult, I propose to hide that complexity inside libnss.

FYI, about:buildconfig is a static HTML file produced at build-time, so if you want to use the information there, a better approach would be grep'ing the version number out of a file somewhere.

Comment on attachment 547402 [details] [diff] [review] Patch v1 will attach a new patch

Let's start with the easy parts. This adds 4 functions for libs - nssutil - nss - smime - ssl We can add functions for the pkcs#12 modules later, (or we might find a way to query it from the pkcs#12 without requiring new functions).

(In reply to comment #3) > FYI, about:buildconfig is a static HTML file produced at build-time, so if > you want to use the information there, a better approach would be grep'ing > the version number out of a file somewhere. Ok, then about:buildconfig is not an appropriate place for this information. I would like to report the version numbers of the dynamically loaded libraries. Maybe about:memory is a better place for that, because khuey said, that page is dynamically generated at runtime. I might hack an experimental patch for that page, but if you prefered, we could maybe introduce about:libraries

Do any of the existing functions shown at the URL below satisfy the need? https://mxr.mozilla.org/security/search?string=VersionCheck&case=on&find=\.def%24

Comment on attachment 547496 [details] [diff] [review] Patch v2 I prefer the shorter XXX_GetVersion function names that you originally proposed. The "XXX" should match the existing XXX_VersionCheck functions, and the new XXX_GetVersion functions and be declared and defined right after the closely-related XXX_VersionCheck functions. The comment "Returns a const string." should include "version" somewhere.

(In reply to comment #9) > > I prefer the shorter XXX_GetVersion function names > that you originally proposed. Ok, will change the names back. UTIL doesn't have a library name yet, so I've chosen NSSUTIL_GetVersion, to make it similar to the NSSSMIME_ and NSSSSL_ names. > The "XXX" should match the existing XXX_VersionCheck > functions, ok > and the new XXX_GetVersion functions and > be declared and defined right after the closely-related > XXX_VersionCheck functions. Ok. SMIME and SSL don't declare the _VersionCheck functions in the headers. Should I add that? > The comment "Returns a const string." should include > "version" somewhere. Ok

(In reply to comment #8) > Do any of the existing functions shown at the URL below satisfy the need? > > https://mxr.mozilla.org/security/search?string=VersionCheck&case=on&find=\. > def%24 No, I don't want to check versions, I rather would like to display the library's version number strings in the application's user interface. (Not build-time versions, but run-time versions.)

Comment on attachment 547654 [details] [diff] [review] Patch v3 r=wtc. Please consider removing NSSSMIME_GetVersion and NSSSSL_GetVersion. I found that NSSSMIME_VersionCheck and NSSSSL_VersionCheck are not declared in any header file, so perhaps nobody is using those functions. Also, since all Linux distributions put libsmime3.so and libssl3.so in the same package as libnss3.so, it doesn't seem necessary for libsmime3.so and libssl3.so to have their own version functions. NSPR also has three .so's, but only libnspr4.so has a version function. Alternatively, we should add the declarations of NSSSMIME_VersionCheck and NSSSSL_VersionCheck. Please also get Bob's approval for this patch.

This proposal introduces one _GetVersion per NSS component. Given that - there are at least 8 ones (in comment #1 : nss, util, ..., ckbi) - the number of components the NSS is composed from may change with time would it be more efficiently to have a single GetVersion, that returns a list of tuples { component: version } ?

(In reply to comment #14) > > would it be more efficiently to have a single GetVersion, that returns a > list of tuples { component: version } ? I seems to much hassle to require parsing of a nested structure for a task as simple as obtaining a version number.

Comment on attachment 547654 [details] [diff] [review] Patch v3 > Please also get Bob's approval for this patch. Ok. Bob, do you have an opinion regarding "just one NSS_GetVersion function" vs. "in addition have NSSSMIME_GetVersion and NSSSSL_GetVersion" ? > Please consider removing NSSSMIME_GetVersion and NSSSSL_GetVersion. In the past, with a "Flash" bug, libraries from different directories ended up to be combined. We might be able to construct a scenario, where Firefox uses plugin code that links to libssl, but no other parts of NSS, the plugin is loaded first, using the plugin's local copy of libssl, and when Firefox attempts to init, it will pull in the not-yet-loaded NSS libraries from the global system path. This is a very unusual scenario, but if we had the independent version numbers, they could help to diagnose bugs because of such an environment more easily. > Alternatively, we should add the declarations of NSSSMIME_VersionCheck > and NSSSSL_VersionCheck. Ok. If we decide to keep the functions, I'll add the declarations.

Comment on attachment 547654 [details] [diff] [review] Patch v3 r+ rrelyea. I'm also OK with WTc's suggestion of exporting the Versioncheck for SSL and SMIME. bob

> I'm also OK with WTc's suggestion of > exporting the Versioncheck for SSL and SMIME. They are already exported, it's the header declaration that is missing. This is an updated patch that adds the declarations. It uses the function signature as defined in .c and it matches the function signature of the already declared NSS function. I've copied the function comment from the existing declaration, and fixed a typo.

fixed on trunk for 3.13 Checking in nss/nss.def; /cvsroot/mozilla/security/nss/lib/nss/nss.def,v <-- nss.def new revision: 1.215; previous revision: 1.214 done Checking in nss/nss.h; /cvsroot/mozilla/security/nss/lib/nss/nss.h,v <-- nss.h new revision: 1.83; previous revision: 1.82 done Checking in nss/nssinit.c; /cvsroot/mozilla/security/nss/lib/nss/nssinit.c,v <-- nssinit.c new revision: 1.107; previous revision: 1.106 done Checking in smime/smime.def; /cvsroot/mozilla/security/nss/lib/smime/smime.def,v <-- smime.def new revision: 1.38; previous revision: 1.37 done Checking in smime/smime.h; /cvsroot/mozilla/security/nss/lib/smime/smime.h,v <-- smime.h new revision: 1.10; previous revision: 1.9 done Checking in smime/smimeutil.c; /cvsroot/mozilla/security/nss/lib/smime/smimeutil.c,v <-- smimeutil.c new revision: 1.21; previous revision: 1.20 done Checking in ssl/ssl.def; /cvsroot/mozilla/security/nss/lib/ssl/ssl.def,v <-- ssl.def new revision: 1.26; previous revision: 1.25 done Checking in ssl/ssl.h; /cvsroot/mozilla/security/nss/lib/ssl/ssl.h,v <-- ssl.h new revision: 1.42; previous revision: 1.41 done Checking in ssl/sslcon.c; /cvsroot/mozilla/security/nss/lib/ssl/sslcon.c,v <-- sslcon.c new revision: 1.42; previous revision: 1.41 done Checking in util/nssutil.def; /cvsroot/mozilla/security/nss/lib/util/nssutil.def,v <-- nssutil.def new revision: 1.14; previous revision: 1.13 done Checking in util/nssutil.h; /cvsroot/mozilla/security/nss/lib/util/nssutil.h,v <-- nssutil.h new revision: 1.18; previous revision: 1.17 done Checking in util/secoid.c; /cvsroot/mozilla/security/nss/lib/util/secoid.c,v <-- secoid.c new revision: 1.62; previous revision: 1.61 done

Is this just an API change or is there a way to access this information in Firefox now? I had a look through the patch and didn't see anything obviously jumping out at me, but I'm not too familiar with the mozilla source code so I could have overlooked something.

This just adds the API. bug 673381 covers adding that information to about:support.