673115 - Add function to obtain version of NSS at runtime.

Status: RESOLVED FIXED

(NSS :: Libraries, defect)

Description

[Kai Engert [:KaiE:]]

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.

Comment 1

[Kai Engert [:KaiE:]]

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

Comment 2

[Kai Engert [:KaiE:]]

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.

Comment 3

[(not currently active) Ted Mielczarek]

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 4

[Kai Engert [:KaiE:]]

Attachment: Patch v1

Comment 5

[Kai Engert [:KaiE:]]

Comment on attachment 547402 [details] [diff] [review]
Patch v1

will attach a new patch

Comment 6

[Kai Engert [:KaiE:]]

Attachment: Patch v2

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).

Comment 7

[Kai Engert [:KaiE:]]

(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

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

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 9

[Wan-Teh Chang]

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.

Comment 10

[Kai Engert [:KaiE:]]

(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

Comment 11

[Kai Engert [:KaiE:]]

Attachment: Patch v3

Comment 12

[Kai Engert [:KaiE:]]

(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 13

[Wan-Teh Chang]

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.

Comment 14

[Konstantin Andreev]

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 } ?

Comment 15

[Kai Engert [:KaiE:]]

(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 16

[Kai Engert [:KaiE:]]

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 17

[Robert Relyea]

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

Comment 18

[Kai Engert [:KaiE:]]

Attachment: Patch v3 with header declaration added

> 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.

Comment 19

[Kai Engert [:KaiE:]]

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

Comment 20

[Stephen Mc Gowan]

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.

Comment 21

[(not currently active) Ted Mielczarek]

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