NSS softoken should be buildable with its own tag

Assigned to


10 years ago
11 months ago


(Reporter: Christophe Ravel, Assigned: Elio Maldonado)


(Blocks: 1 bug)

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: FIPS)


(1 attachment, 3 obsolete attachments)



10 years ago
We want to be able to build the NSS softoken with its own tag (a FIPS validated tag for example).

Softoken tag should apply to:
- mozilla/security/nss/lib/freebl
- mozilla/security/nss/lib/softoken

The rest of NSS should be taken from the same or a more recent tag (not older).

Softoken should consume only lower level components:
- libnssutil (mozilla/security/nss/lib/util)
- Database
    * SQLITE from mozilla/security/nss/lib/sqlite
    * DBM from mozilla/dbm, mozilla/security/dbm

Comment 1

10 years ago
Current issues with FREEBL:

freebl/loader.c needs
  - cryptohi/hasht.h
freebl/rawhash.c needs
  - cryptohi/sechash.h

Current issues with SOFTOKEN:

softoken/pkcs11.c needs
  - nss/nss.h
softoken/pkcs11c.c needs
  - ssl/ssl3prot.h
softoken/sftkdb.c needs
  - pk11wrap/secmodt.h
softoken/pk11db.c needs
  - pk11wrap/pk11init.h

Whiteboard: FIPS

Comment 2

10 years ago
This bug is a duplicate of bug 360426.
(In reply to comment #2)
> This bug is a duplicate of bug 360426.

bug 360426 is an umbrella bug.  This bug is one of its many blockers.

Comment 4

10 years ago
Created attachment 339390 [details] [diff] [review]
Decouple lib/softoken and lib/ssl

Rather than adding a new header sftkssl3.h for the portions of
ssl3prot.h used by lib/softoken, perhaps we should move the
contents of sftkssl3.h to an existing header file in lib/softoken.
Attachment #339390 - Flags: review?(nelson)

Comment 5

10 years ago
Created attachment 339402 [details] [diff] [review]
Decouple lib/softoken and lib/ssl, v2

Don't add a new header.  Some unrelated cleanup.
Attachment #339390 - Attachment is obsolete: true
Attachment #339402 - Flags: review?(nelson)
Attachment #339390 - Flags: review?(nelson)

Comment 6

10 years ago
Created attachment 339448 [details] [diff] [review]
Decouple lib/softoken and lib/ssl, v3

SSL3RSAPreMasterSecret is not used by lib/ssl, so remove its definition
from ssl3prot.h.
Attachment #339402 - Attachment is obsolete: true
Attachment #339402 - Flags: review?(nelson)
Attachment #339448 - Flags: review?(nelson)
Comment on attachment 339448 [details] [diff] [review]
Decouple lib/softoken and lib/ssl, v3

r+ for all aspects of this patch except one.
Leave the declaration of struct SSL3RSAPreMasterSecret in ssl3prot.h.
It's part of the definition of SSL3/TLS, and the purpose of ssl3prot.h
is to collect all the declarations of SSL3 protocol structures in 
one place for libSSL, even if they're not presently used.
I don't mind if it's duplicated elsewhere outside of libSSL.
Attachment #339448 - Flags: review?(nelson) → review+

Comment 8

10 years ago
Created attachment 339875 [details] [diff] [review]
Decouple lib/softoken and lib/ssl, v4 (checked in)

I checked in this patch on the NSS trunk (NSS 3.12.2).
ssl3prot.h was not changed.

Checking in softoken/pkcs11c.c;
/cvsroot/mozilla/security/nss/lib/softoken/pkcs11c.c,v  <--  pkcs11c.c
new revision: 1.103; previous revision: 1.102
Checking in ssl/manifest.mn;
/cvsroot/mozilla/security/nss/lib/ssl/manifest.mn,v  <--  manifest.mn
new revision: 1.18; previous revision: 1.17
Checking in ssl/ssl3con.c;
/cvsroot/mozilla/security/nss/lib/ssl/ssl3con.c,v  <--  ssl3con.c
new revision: 1.113; previous revision: 1.112
Attachment #339448 - Attachment is obsolete: true


10 years ago
Blocks: 459298

Comment 9

9 years ago
Has this patched been applied already or reviewed?

Comment 10

9 years ago
Here is a report on my investigation on building Fedora packages for utils and softtoken. I made the contents I thought I needed from the mozilla sources that would go into into tar ball by hand. I kept the existing layout.

Building NSSUTIL is fairly straightforward. The discovery here is that util has a dependency on the pkcs #11 headers that currently reside in softtoken. I moved these pkcs11 #11 headers to util and also made a version header for util.

Keeping the same layout after removing unneeded stuff, this is the contents of the make-believe utils tar ball I used to build.
        coreconf/                -- kept as is expcept fort ...
              mlocal.mk          -- 
                    nssutil.h     -- new - contains the nssutil version
                    pkcs11xxx.h   -- moved pkcs11's here from softtoken       
                    manifest.mn   -- added nssutil and pkcs11 headers   to                                EXPORTS list
             pkg/  -- kept as is

On the Fedora side, in the nssutil/devel directory I have:
nssutil.spec modeled after nss.spec, Makefile like NSS' Makefile but with line NAME := nssutil, nssutil-congif.in, nssutil-prelink.conf nssutil.pc.in modeled after the ones for nss. No need for the blank .db files or the patch files. Make install, make local, and mockbuild work okay. Installing the goods in one's system is a bad thing. Will do it in a VM.

That is not as straightforward as utils because of unwanted dependencies.
Here besides freebl, softoken, and shlibsign applications it would be nice to include the blapitest and fipstest. Unfortunately the tests need /cmd/lib and that brings in dependencies on higher level calls.  The test do initialize NSS for one and use SECU_ calls from the lib. The lib uses higher level APIs.
As before I kept the layout found in NSS and removed a lot of unneeded stuff.
    dbm/                      -- had to keep it
        coreconf/           -- kept mostly as is, except for ...
           mlocal.mk        -- added NSSUTIL_INCLUDE_DIR and NSSUTIL_LIB_DIR
            Makefile        -- Works unmodified! 
            manifest.mn     -- modified one line RELEASE = softoken instead of NSS I guess that could be done downstream instead.
                shlibsign         -- 
           no util/ needed here, 
         I modified the .spec and a local.mk to get it from the system
             pkg/  -- kept as is

On the Fedora side, in the softoken/devel directory I have: softoken.spec modeled after nss.spec, Makefile modeled after NSS' own but with line NAME := softoken and added BuildRquires nssutil and nssutil-devel. The rest, softoken-config.in, softoken.conf softoken.pc.in -- modeled after the ones for nss
Don't seem to need the blank-xxx.db files or the patch files.

Make install and local okay. I could not do a mockbuild because it triggers yum which wants to download nssutil-devel from the fedora repo but and it isn't in there yet.
Moving the PKCS#11 header files to util doesn't seem right.
What dependency does util have on PKCS#11 header files?

Comment 12

9 years ago
The problem is that util/secoid.c needs pkcs11t.h for the CKM_xxxx constants.

Comment 13

9 years ago
Elio: see bug 402777 comment 19 for the remaining problems
for building lib/util as a standalone component.  The pkcs11*.h
headers are one of the problems.  The other problem, which
affects Windows only, is that nssutil.rc needs nss.h for
the NSS version macros.  We probably should give lib/util
its own version number.

Comment 14

9 years ago
I agree util should have a version header just like nss and softoken have theirs. As I mentioned above I have a nssutil.h made a modification to security/coreconf/mlocal.mk which I would like to atttach the header and the patch to mlocal.mk either here or the another bug. Should bug 402777 should be reopened?

Comment 15

9 years ago
It's better to open a new bug to finish the remaining work from bug 402777.


9 years ago
Depends on: 482742


9 years ago
Assignee: nobody → emaldona


9 years ago
No longer blocks: 459298

Comment 16

9 years ago
NSS 3.12.4 has been submitted to NISt for FIPS validation and has gone RTM without this bug been resolved. I am changing the target to 3.13 as I still think that being able to realease Softokn/freebl is still a worthy goal.
Target Milestone: --- → 3.13


5 years ago
Target Milestone: 3.13 → 3.15.3

Comment 17

4 years ago
changing target milestone to 3.15.4
Target Milestone: 3.15.3 → 3.15.4
You need to log in before you can comment on or make changes to this bug.