1018536 - Provide information about the VMINOR and VPATCH version of softoken/freebl in the token/slot info

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P1)

Description

[Ryan Sleevi]

Applications that wish to know the exact version of freebl that is being used by softoken/NSS have no way of obtaining the VPATCH/VBUILD values. As a result, the most information they have is 3.16, exposed via the hardwareVersion.major and .minor, respectively.

We should use the firmwareVersion of CK_TOKEN_INFO / CK_SLOT_INFO to provide additional details, using VPATCH as the firmwareVersion.major and VBUILD as firmwareVersion.minor

Comment 1

[Ryan Sleevi]

Attachment: Expose it for CK_SLOT_INFO

I left CK_TOKEN_INFO, as it looks like it was planned that the token info would return the keydb version.

Comment 2

[Robert Relyea]

Comment on attachment 8432039 [details] [diff] [review]
Expose it for CK_SLOT_INFO

Review of attachment 8432039 [details] [diff] [review]:
-----------------------------------------------------------------

r+ Yes, just updating the token is fine (though if we had it to do over again, I'd put the keydb in the token and the patch version in the slot, since techinally the slot can be unloaded and a new database loaded in it's place.

Comment 3

[Ryan Sleevi]

Checked in as https://hg.mozilla.org/projects/nss/rev/dd794c4395e5

Comment 4

[Wan-Teh Chang]

Comment on attachment 8432039 [details] [diff] [review]
Expose it for CK_SLOT_INFO

Review of attachment 8432039 [details] [diff] [review]:
-----------------------------------------------------------------

::: lib/softoken/pkcs11.c
@@ +3193,5 @@
>      /* pInfo->hardwareVersion.major = NSSLOWKEY_DB_FILE_VERSION; */
>      pInfo->hardwareVersion.major = SOFTOKEN_VMAJOR;
>      pInfo->hardwareVersion.minor = SOFTOKEN_VMINOR;
> +    pInfo->firmwareVersion.major = SOFTOKEN_VPATCH;
> +    pInfo->firmwareVersion.minor = SOFTOKEN_VBUILD;

This is the easiest solution, but is an abuse of firmwareVersion.
Perhaps in time I'll consider this a clever trick.

I would add a SOFTOKEN_VersionCheck() or SOFTOKEN_GetVersion()
function to libsoftokn3.so similar to NSS_VersionCheck() or
NSS_GetVersion:
http://mxr.mozilla.org/nss/ident?i=NSS_VersionCheck
http://mxr.mozilla.org/nss/ident?i=NSS_GetVersion

If it is cumbersome to look up and call a function in
libsoftokn3.so, we can hide that complexity by adding a
function to libnss3.so that checks or returns the version
of the libsoftokn3.so in use.

Comment 5

[Robert Relyea]

> This is the easiest solution, but is an abuse of firmwareVersion.
> Perhaps in time I'll consider this a clever trick.

The meanin of firmwareVersion is pretty much token dependent, so it's really not that much of a stretch here.


> I would add a SOFTOKEN_VersionCheck() or SOFTOKEN_GetVersion()
> function to libsoftokn3.so similar to NSS_VersionCheck() or
> NSS_GetVersion

That's very non-PKCS #11. I'm OK for adding that to other NSS shared libraries, but not softoken so much.

Comment 6

[Robert Relyea]

> That's very non-PKCS #11. I'm OK for adding that to other NSS shared libraries, but not softoken so much.

I should note that softoken is dl loaded by hand, so we always dlsymbol lookup softoken addresses, which make some solutions (like versionCheck) harder.

bob

Comment 7

[Wan-Teh Chang]

Thank you for the comments. I now consider this patch a clever solution.