new configuration args for system NSS.

ASSIGNED
Assigned to

Status

NSS
Libraries
ASSIGNED
9 years ago
8 years ago

People

(Reporter: Robert Relyea, Assigned: Robert Relyea)

Tracking

3.12.4
3.12.5
All
Linux

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Assignee)

Description

9 years ago
We need 2 new NSS configuration arguments which applies to module DB's to facilitate the new NSS System init design.

module DB's are loadable modules that give you access to what PKCS #11 modules to load and when. These module DB's are chainable. That is one module DB can load another one. NSS system init design takes advantage of this feature. In system NSS, a fixed system module DB loads the system defined libraries, then chains out to the traditional module DB's to load any system or user configured modules (like smart cards).

The first new argument is 'skipFirst' which tells NSS to skip the first PKCS #11 module presented by a module DB. This allows us to load a softoken from the system module, then ask our existing moduleDB code to load the other pkcs #11 modules in that module DB (skipping it's request to load softoken). This allows the system init finer control over the configuration of that softoken module.

The second new argument is 'defaultModuleDB'. This allows system init to mark a different module DB as the 'default' module DB (the one in which 'Add module' changes will go into). Currently NSS takes the first module as the defaultModuleDB, but in system NSS, that first module is the system module, which is likely read only (at least to the user). This allows system NSS to delegate those changes to the user's module DB, preserving the user's ability to load new PKCS #11 modules (which only affect him), from existing applications like Firefox.
(Assignee)

Comment 1

9 years ago
Created attachment 395101 [details] [diff] [review]
Adds new arguments.

This patch overloads the Boolean isModuleDB flag. These arguments only apply to moduleDBs. The overload is to preserve binary compatibility.

The patch makes the accessor functions public. This isn't strictly necessary as applications have little need for these flags, but I prefer applications access them through accessor functions rather than directly. If we want to keep them private it's a simple matter to move the declarations to secmodi.h, remove them from nss.def and rename them with lower case name.

bob
(Assignee)

Updated

9 years ago
Blocks: 505553
(Assignee)

Updated

9 years ago
Attachment #395101 - Flags: review?(nelson)
Attachment #395101 - Flags: review?(nelson) → review-
Comment on attachment 395101 [details] [diff] [review]
Adds new arguments.

The big problem I have with this patch is the total lack of comments
explaining what the new features do.  There's a comment that explains
that the implementation of one new feature attempts to maintain backward
binary compatibility, but no clues about the meanings of the new features.

>+/* private flags, 1 is reserved. */

The value 1 clearly means "is the DB module", so let's give it a symbolic
name, e.g 
+#define SECMOD_FLAG_IS_DB_MODULE   0x01
and use that symbol below instead of the unexplained magic number 1.

>+#define SECMOD_FLAG_SKIP_FIRST    0x02
>+#define SECMOD_FLAG_DEFAULT_MODDB 0x04
>+
> /*
>  * for 3.4 we continue to use the old SECMODModule structure
>  */

>     mod->isModuleDB   = secmod_argHasFlag("flags","moduleDB",nssc);
>     mod->moduleDBOnly = secmod_argHasFlag("flags","moduleDBOnly",nssc);
>     if (mod->moduleDBOnly) mod->isModuleDB = PR_TRUE;
> 
>+    /* we need more bits, but we also want to preserve binary compatibility 
>+     * we overload the isModuleDB PRBool with and additional flag. 
                                                ^^  "an", not "and".
>+     * NOTE: this depends on the fact that PRBool is at least a char on 
>+     * all platforms. These flags are only valid if moduleDB is set, so 
>+     * code checking if (mod->isModuleDB) will continue to work correctly. */

Those comments are all fine and good, but they need to mention that the values
of the other bits in this char are meaningful ONLY if the bit 
SECMOD_FLAG_IS_DB_MODULE is set to 1.

>+    if (mod->isModuleDB) {
>+	char flags = 1;

and use that symbolic name here:
        char flags = SECMOD_FLAG_IS_DB_MODULE;

>+	if (secmod_argHasFlag("flags","skipFirst",nssc)) {
>+	    flags |= SECMOD_FLAG_SKIP_FIRST;

skip first what?  You know what's being skipped, Bob, but no-one else does.
Please make the name self-describing, or else add a BIG block comment.
Every place where the new name "skipfirst" appears, it needs to be changed
to answer the question "skip first what?".

>+	}
>+	if (secmod_argHasFlag("flags","defaultModDB",nssc)) {
>+	    flags |= SECMOD_FLAG_DEFAULT_MODDB;
>+	}
>+	/* additional moduleDB flags could be added here in the future */
>+	mod->isModuleDB = (PRBool) flags;
>+    }
>+

>@@ -333,7 +370,12 @@ SECMOD_LoadModule(char *modulespec,SECMO
> 	if (moduleSpecList) {
> 	    char **index;
> 
>-	    for (index = moduleSpecList; *index; index++) {
>+	    index = moduleSpecList;
>+	    if (*index && SECMOD_GetSkipFirstFlag(module)) {
>+		index++;
>+	    }

OK, so here we see that what is being skipped is the first module
spec in a list of module specs.  What's special about the first one?
Why would we want to skip just the first one? and not (say) just the
last one, or just the second one?  There needs to be a good explanation
here.  


> SECStatus
> SECMOD_AddModuleToDBOnlyList(SECMODModule *newModule)
> {
>-    if (defaultDBModule == NULL) {
>+    if (defaultDBModule && SECMOD_GetDefaultModDBFlag(newModule)) {
>+	SECMOD_DestroyModule(defaultDBModule);
>+	defaultDBModule = SECMOD_ReferenceModule(newModule);
>+    } else if (defaultDBModule == NULL) {
> 	defaultDBModule = SECMOD_ReferenceModule(newModule);
>     }
>     return secmod_AddModuleToList(&modulesDB,newModule);

I gather that the intent of the above change is to create a means to 
replace the default DB module with a new one.  When a default DB 
module exists, and a new module is added to the list, if the new
module is flagged as a default DB module, it will replace the old
one, otherwise it will merely be added to the list. 

There needs to be a comment to that effect.  Also, could this have
unintended consequences on binary compatibility?  Could users have
configurations in which multiple modules are now configured as 
default modules, and today all coexist and work, but with this 
change, only one would survive?
The paragraphs in comment 0 of this bug would make WONDERFUL EXCELLENT 
comments to go into the source code near the code that implements them!!

(How strange that my mozilla email program put the email for comment 0 
in a separate thread from the other emails related to this bug!  If I had
seen it first, my review might have been somewhat different.)
(Assignee)

Comment 4

9 years ago
> The paragraphs in comment 0 of this bug would make WONDERFUL EXCELLENT 
> comments to go into the source code near the code that implements them!!

Thanks, that was going to be my first question.

> +#define SECMOD_FLAG_IS_DB_MODULE   0x01
> and use that symbol below instead of the unexplained magic number 1.

sounds good.

> Those comments are all fine and good, but they need to mention that the values
> of the other bits in this char are meaningful ONLY if the bit 
> SECMOD_FLAG_IS_DB_MODULE is set to 1.

I thought I had meantioned that already in the comments somewhere, but it's an important point and I have not problem being even more verbose about it here.


> I gather that the intent of the above change is to create a means to 
> replace the default DB module with a new one. 

yes, All modules go on the list, but there is only one 'default'. Currently it's the first module loaded. With this flag it's still the first module unless, this flag is specified, then it's the last module loaded with this flag set.

The default module is used when the application tries to 'add' a new module. There has always been, and can only ever by, one (currently the first one loaded). Applications have never been able to control this. NOTE: this not affect the ability to have more than one moduleDB loaded. All moduleDB's are still placed on the list reguardless to whether or not they are the 'default' module.

I'll provide a new patch with the updates shortly.

bob
(Assignee)

Comment 5

9 years ago
Created attachment 396310 [details] [diff] [review]
Add comment comments to address review comments
Attachment #395101 - Attachment is obsolete: true
(Assignee)

Comment 6

9 years ago
Comment on attachment 396310 [details] [diff] [review]
Add comment comments to address review comments

Requested comments added.
Attachment #396310 - Flags: review?(nelson)
Comment on attachment 396310 [details] [diff] [review]
Add comment comments to address review comments

These comments are an improvement.  They explain the purpose for which the 
flags were created, but do not tell me enough to know when to set them.  
How does the caller know when to set this SKIP_FIRST flag?  
How does he know when he's using system NSS or not?  

There's a lot of information still missing, but I'm willing to let this be 
checked in as is, and then do more word smithing in a subsequent checkin.  

>+/* private flags. */
>+/* The meaing of these flags is as follows:
>+ *
>+ * SECMOD_FLAG_IS_MODULE_DB - This is a module that accesses the database of
>+ *   other modules to load. module DB's are loadable modules that give you 
                              ^ capital M, please
>+ *   access to what PKCS #11 modules to load and when. These module DB's are 
                                                          no apostrophe ^
s/give you access to what/determine which/

>+ *   chainable. That is one module DB can load another one. NSS system init 
                         ^ add a comma there
>+ *   design takes advantage of this feature. In system NSS, a fixed system 
>+ *   module DB loads the system defined libraries, then chains out to the 
>+ *   traditional module DB's to load any system or user configured modules 
                            ^ no apostrophe
 
>+ *   (like smart cards). This bit is the same as the already existing meaning 
>+ *   of  isModuleDB = PR_TRUE. None of the other flags should be set if this
>+ *   flag isn't on.
>+ *
>+ * SEMOD_FLAG_SKIP_FIRST - This flag tells NSS to skip the first 
       ^ add missing 'C'
>+ *   PKCS #11 module presented by a module DB. This allows us to load a 

allows us?  us who?  I think the answer is "the writer of the application or 
library that calls NSS_Init" or something like that.  Please clarify.

>+ *   softoken from the system module, then ask our existing moduleDB code to 
                                                          add space ^
>+ *   load the other PKCS #11 modules in that module DB (skipping it's request 
>+ *   to load softoken). This allows the system init finer control over the 
>+ *   configuration of that softoken module.
>+ *
>+ * SECMOD_FLAG_DEFAULT_MODDB - This flag allows system init to mark a 
>+ *   different module DB as the 'default' module DB (the one in which 
>+ *   'Add module' changes will go into). Currently NSS takes the first module 
            remove redundant "into" ^^^^   ^^^^^^^^^ "Without system NSS"
>+ *   as the defaultModuleDB, but in system NSS, that first module is the 
                     ^     ^ add missing spaces
>+ *   system module, which is likely read only (at least to the user). This 
>+ *   allows system NSS to delegate those changes to the user's module DB, 
>+ *   preserving the user's ability to load new PKCS #11 modules (which only 
>+ *   affect him), from existing applications like Firefox.
>+ */
Attachment #396310 - Flags: review?(nelson) → review+
(Assignee)

Comment 8

9 years ago
Checking in lib/nss/nss.def;
/cvsroot/mozilla/security/nss/lib/nss/nss.def,v  <--  nss.def
new revision: 1.201; previous revision: 1.200
done
Checking in lib/pk11wrap/pk11pars.c;
/cvsroot/mozilla/security/nss/lib/pk11wrap/pk11pars.c,v  <--  pk11pars.c
new revision: 1.22; previous revision: 1.21
done
Checking in lib/pk11wrap/pk11util.c;
/cvsroot/mozilla/security/nss/lib/pk11wrap/pk11util.c,v  <--  pk11util.c
new revision: 1.56; previous revision: 1.55
done
Checking in lib/pk11wrap/secmod.h;
/cvsroot/mozilla/security/nss/lib/pk11wrap/secmod.h,v  <--  secmod.h
new revision: 1.27; previous revision: 1.26
done
(Assignee)

Comment 9

9 years ago
Created attachment 397972 [details] [diff] [review]
Patch as checked in (fixed minor comment issues).
Attachment #396310 - Attachment is obsolete: true

Comment 10

9 years ago
It looks like the commit in comment #8 caused the following build error (on Solaris):

cc -G -h libnss3.so -z combreloc -z defs -z ignore -R '$ORIGIN' -M SunOS5.10_DBG.OBJ/nss.def -o SunOS5.10_DBG.OBJ/libnss3.so SunOS5.10_DBG.OBJ/nssinit.o SunOS5.10_DBG.OBJ/nssver.o SunOS5.10_DBG.OBJ/utilwrap.o ../certhigh/SunOS5.10_DBG.OBJ/certhtml.o ../certhigh/SunOS5.10_DBG.OBJ/certreq.o ../certhigh/SunOS5.10_DBG.OBJ/crlv2.o ../certhigh/SunOS5.10_DBG.OBJ/ocsp.o ../certhigh/SunOS5.10_DBG.OBJ/certhigh.o ../certhigh/SunOS5.10_DBG.OBJ/certvfy.o ../certhigh/SunOS5.10_DBG.OBJ/certvfypkix.o ../certhigh/SunOS5.10_DBG.OBJ/certvfypkixprint.o ../certhigh/SunOS5.10_DBG.OBJ/xcrldist.o ../cryptohi/SunOS5.10_DBG.OBJ/sechash.o ../cryptohi/SunOS5.10_DBG.OBJ/seckey.o ../cryptohi/SunOS5.10_DBG.OBJ/secsign.o ../cryptohi/SunOS5.10_DBG.OBJ/secvfy.o ../cryptohi/SunOS5.10_DBG.OBJ/dsautil.o ../pk11wrap/SunOS5.10_DBG.OBJ/dev3hack.o ../pk11wrap/SunOS5.10_DBG.OBJ/pk11akey.o ../pk11wrap/SunOS5.10_DBG.OBJ/pk11auth.o ../pk11wrap/SunOS5.10_DBG.OBJ/pk11cert.o ../pk11wrap/SunOS5.10_DBG.OBJ/pk11cxt.o ../pk11!
 wrap/SunOS5.10_DBG.OBJ/pk11err.o ../pk11wrap/SunOS5.10_DBG.OBJ/pk11kea.o ../pk11wrap/SunOS5.10_DBG.OBJ/pk11list.o ../pk11wrap/SunOS5.10_DBG.OBJ/pk11load.o ../pk11wrap/SunOS5.10_DBG.OBJ/pk11mech.o ../pk11wrap/SunOS5.10_DBG.OBJ/pk11merge.o ../pk11wrap/SunOS5.10_DBG.OBJ/pk11nobj.o ../pk11wrap/SunOS5.10_DBG.OBJ/pk11obj.o ../pk11wrap/SunOS5.10_DBG.OBJ/pk11pars.o ../pk11wrap/SunOS5.10_DBG.OBJ/pk11pbe.o ../pk11wrap/SunOS5.10_DBG.OBJ/pk11pk12.o ../pk11wrap/SunOS5.10_DBG.OBJ/pk11pqg.o ../pk11wrap/SunOS5.10_DBG.OBJ/pk11sdr.o ../pk11wrap/SunOS5.10_DBG.OBJ/pk11skey.o ../pk11wrap/SunOS5.10_DBG.OBJ/pk11slot.o ../pk11wrap/SunOS5.10_DBG.OBJ/pk11util.o ../certdb/SunOS5.10_DBG.OBJ/alg1485.o ../certdb/SunOS5.10_DBG.OBJ/certdb.o ../certdb/SunOS5.10_DBG.OBJ/certv3.o ../certdb/SunOS5.10_DBG.OBJ/certxutl.o ../certdb/SunOS5.10_DBG.OBJ/crl.o ../certdb/SunOS5.10_DBG.OBJ/genname.o ../certdb/SunOS5.10_DBG.OBJ/stanpcertdb.o ../certdb/SunOS5.10_DBG.OBJ/polcyxtn.o ../certdb/SunOS5.10_DBG.OBJ/secname.o ..!
 /certdb/SunOS5.10_DBG.OBJ/xauthkid.o ../certdb/SunOS5.10_DBG.O!
 BJ/xbsco
nst.o ../certdb/SunOS5.10_DBG.OBJ/xconst.o ../pki/SunOS5.10_DBG.OBJ/asymmkey.o ../pki/SunOS5.10_DBG.OBJ/certificate.o ../pki/SunOS5.10_DBG.OBJ/cryptocontext.o ../pki/SunOS5.10_DBG.OBJ/symmkey.o ../pki/SunOS5.10_DBG.OBJ/trustdomain.o ../pki/SunOS5.10_DBG.OBJ/tdcache.o ../pki/SunOS5.10_DBG.OBJ/certdecode.o ../pki/SunOS5.10_DBG.OBJ/pkistore.o ../pki/SunOS5.10_DBG.OBJ/pkibase.o ../pki/SunOS5.10_DBG.OBJ/pki3hack.o ../dev/SunOS5.10_DBG.OBJ/devslot.o ../dev/SunOS5.10_DBG.OBJ/devtoken.o ../dev/SunOS5.10_DBG.OBJ/devutil.o ../dev/SunOS5.10_DBG.OBJ/ckhelper.o ../base/SunOS5.10_DBG.OBJ/arena.o ../base/SunOS5.10_DBG.OBJ/error.o ../base/SunOS5.10_DBG.OBJ/errorval.o ../base/SunOS5.10_DBG.OBJ/hashops.o ../base/SunOS5.10_DBG.OBJ/libc.o ../base/SunOS5.10_DBG.OBJ/tracker.o ../base/SunOS5.10_DBG.OBJ/item.o ../base/SunOS5.10_DBG.OBJ/utf8.o ../base/SunOS5.10_DBG.OBJ/list.o ../base/SunOS5.10_DBG.OBJ/hash.o ../libpkix/pkix/certsel/SunOS5.10_DBG.OBJ/pkix_certselector.o ../libpkix/pkix/certsel/SunOS5!
 .10_DBG.OBJ/pkix_comcertselparams.o ../libpkix/pkix/checker/SunOS5.10_DBG.OBJ/pkix_basicconstraintschecker.o ../libpkix/pkix/checker/SunOS5.10_DBG.OBJ/pkix_certchainchecker.o ../libpkix/pkix/checker/SunOS5.10_DBG.OBJ/pkix_crlchecker.o ../libpkix/pkix/checker/SunOS5.10_DBG.OBJ/pkix_ekuchecker.o ../libpkix/pkix/checker/SunOS5.10_DBG.OBJ/pkix_expirationchecker.o ../libpkix/pkix/checker/SunOS5.10_DBG.OBJ/pkix_namechainingchecker.o ../libpkix/pkix/checker/SunOS5.10_DBG.OBJ/pkix_nameconstraintschecker.o ../libpkix/pkix/checker/SunOS5.10_DBG.OBJ/pkix_ocspchecker.o ../libpkix/pkix/checker/SunOS5.10_DBG.OBJ/pkix_revocationmethod.o ../libpkix/pkix/checker/SunOS5.10_DBG.OBJ/pkix_revocationchecker.o ../libpkix/pkix/checker/SunOS5.10_DBG.OBJ/pkix_policychecker.o ../libpkix/pkix/checker/SunOS5.10_DBG.OBJ/pkix_signaturechecker.o ../libpkix/pkix/checker/SunOS5.10_DBG.OBJ/pkix_targetcertchecker.o ../libpkix/pkix/params/SunOS5.10_DBG.OBJ/pkix_trustanchor.o ../libpkix/pkix/params/SunOS5.10_DB!
 G.OBJ/pkix_procparams.o ../libpkix/pkix/params/SunOS5.10_DBG.O!
 BJ/pkix_
valparams.o ../libpkix/pkix/params/SunOS5.10_DBG.OBJ/pkix_resourcelimits.o ../libpkix/pkix/results/SunOS5.10_DBG.OBJ/pkix_buildresult.o ../libpkix/pkix/results/SunOS5.10_DBG.OBJ/pkix_policynode.o ../libpkix/pkix/results/SunOS5.10_DBG.OBJ/pkix_valresult.o ../libpkix/pkix/results/SunOS5.10_DBG.OBJ/pkix_verifynode.o ../libpkix/pkix/top/SunOS5.10_DBG.OBJ/pkix_validate.o ../libpkix/pkix/top/SunOS5.10_DBG.OBJ/pkix_lifecycle.o ../libpkix/pkix/top/SunOS5.10_DBG.OBJ/pkix_build.o ../libpkix/pkix/util/SunOS5.10_DBG.OBJ/pkix_tools.o ../libpkix/pkix/util/SunOS5.10_DBG.OBJ/pkix_error.o ../libpkix/pkix/util/SunOS5.10_DBG.OBJ/pkix_logger.o ../libpkix/pkix/util/SunOS5.10_DBG.OBJ/pkix_list.o ../libpkix/pkix/util/SunOS5.10_DBG.OBJ/pkix_errpaths.o ../libpkix/pkix/crlsel/SunOS5.10_DBG.OBJ/pkix_crlselector.o ../libpkix/pkix/crlsel/SunOS5.10_DBG.OBJ/pkix_comcrlselparams.o ../libpkix/pkix/store/SunOS5.10_DBG.OBJ/pkix_store.o ../libpkix/pkix_pl_nss/pki/SunOS5.10_DBG.OBJ/pkix_pl_basicconstraints.o ..!
 /libpkix/pkix_pl_nss/pki/SunOS5.10_DBG.OBJ/pkix_pl_cert.o ../libpkix/pkix_pl_nss/pki/SunOS5.10_DBG.OBJ/pkix_pl_certpolicyinfo.o ../libpkix/pkix_pl_nss/pki/SunOS5.10_DBG.OBJ/pkix_pl_certpolicymap.o ../libpkix/pkix_pl_nss/pki/SunOS5.10_DBG.OBJ/pkix_pl_certpolicyqualifier.o ../libpkix/pkix_pl_nss/pki/SunOS5.10_DBG.OBJ/pkix_pl_crl.o ../libpkix/pkix_pl_nss/pki/SunOS5.10_DBG.OBJ/pkix_pl_crldp.o ../libpkix/pkix_pl_nss/pki/SunOS5.10_DBG.OBJ/pkix_pl_crlentry.o ../libpkix/pkix_pl_nss/pki/SunOS5.10_DBG.OBJ/pkix_pl_date.o ../libpkix/pkix_pl_nss/pki/SunOS5.10_DBG.OBJ/pkix_pl_generalname.o ../libpkix/pkix_pl_nss/pki/SunOS5.10_DBG.OBJ/pkix_pl_infoaccess.o ../libpkix/pkix_pl_nss/pki/SunOS5.10_DBG.OBJ/pkix_pl_nameconstraints.o ../libpkix/pkix_pl_nss/pki/SunOS5.10_DBG.OBJ/pkix_pl_ocsprequest.o ../libpkix/pkix_pl_nss/pki/SunOS5.10_DBG.OBJ/pkix_pl_ocspresponse.o ../libpkix/pkix_pl_nss/pki/SunOS5.10_DBG.OBJ/pkix_pl_publickey.o ../libpkix/pkix_pl_nss/pki/SunOS5.10_DBG.OBJ/pkix_pl_x500name.o ../l!
 ibpkix/pkix_pl_nss/pki/SunOS5.10_DBG.OBJ/pkix_pl_ocspcertid.o !
 ../libpk
ix/pkix_pl_nss/system/SunOS5.10_DBG.OBJ/pkix_pl_bigint.o ../libpkix/pkix_pl_nss/system/SunOS5.10_DBG.OBJ/pkix_pl_bytearray.o ../libpkix/pkix_pl_nss/system/SunOS5.10_DBG.OBJ/pkix_pl_common.o ../libpkix/pkix_pl_nss/system/SunOS5.10_DBG.OBJ/pkix_pl_error.o ../libpkix/pkix_pl_nss/system/SunOS5.10_DBG.OBJ/pkix_pl_hashtable.o ../libpkix/pkix_pl_nss/system/SunOS5.10_DBG.OBJ/pkix_pl_lifecycle.o ../libpkix/pkix_pl_nss/system/SunOS5.10_DBG.OBJ/pkix_pl_mem.o ../libpkix/pkix_pl_nss/system/SunOS5.10_DBG.OBJ/pkix_pl_monitorlock.o ../libpkix/pkix_pl_nss/system/SunOS5.10_DBG.OBJ/pkix_pl_mutex.o ../libpkix/pkix_pl_nss/system/SunOS5.10_DBG.OBJ/pkix_pl_object.o ../libpkix/pkix_pl_nss/system/SunOS5.10_DBG.OBJ/pkix_pl_oid.o ../libpkix/pkix_pl_nss/system/SunOS5.10_DBG.OBJ/pkix_pl_primhash.o ../libpkix/pkix_pl_nss/system/SunOS5.10_DBG.OBJ/pkix_pl_rwlock.o ../libpkix/pkix_pl_nss/system/SunOS5.10_DBG.OBJ/pkix_pl_string.o ../libpkix/pkix_pl_nss/module/SunOS5.10_DBG.OBJ/pkix_pl_aiamgr.o ../libpkix/pki!
 x_pl_nss/module/SunOS5.10_DBG.OBJ/pkix_pl_colcertstore.o ../libpkix/pkix_pl_nss/module/SunOS5.10_DBG.OBJ/pkix_pl_httpcertstore.o ../libpkix/pkix_pl_nss/module/SunOS5.10_DBG.OBJ/pkix_pl_httpdefaultclient.o ../libpkix/pkix_pl_nss/module/SunOS5.10_DBG.OBJ/pkix_pl_ldaptemplates.o ../libpkix/pkix_pl_nss/module/SunOS5.10_DBG.OBJ/pkix_pl_ldapcertstore.o ../libpkix/pkix_pl_nss/module/SunOS5.10_DBG.OBJ/pkix_pl_ldapresponse.o ../libpkix/pkix_pl_nss/module/SunOS5.10_DBG.OBJ/pkix_pl_ldaprequest.o ../libpkix/pkix_pl_nss/module/SunOS5.10_DBG.OBJ/pkix_pl_ldapdefaultclient.o ../libpkix/pkix_pl_nss/module/SunOS5.10_DBG.OBJ/pkix_pl_nsscontext.o ../libpkix/pkix_pl_nss/module/SunOS5.10_DBG.OBJ/pkix_pl_pk11certstore.o ../libpkix/pkix_pl_nss/module/SunOS5.10_DBG.OBJ/pkix_pl_socket.o   -L../../../../dist/SunOS5.10_DBG.OBJ/lib -L../../../../dist/SunOS5.10_DBG.OBJ/lib -lnssutil3 -L../../../../dist/SunOS5.10_DBG.OBJ/lib -lplc4 -lplds4 -lnspr4  -lthread -lnsl -lsocket -lposix4 -ldl -lc 
Undefined			first referenced
 symbol  			    in file
SECMOD_GetDefaultModuleDBFlag       SunOS5.10_DBG.OBJ/nss.def
ld: fatal: Symbol referencing errors. No output written to SunOS5.10_DBG.OBJ/libnss3.so
gmake[2]: *** [SunOS5.10_DBG.OBJ/libnss3.so] Error 1
(Assignee)

Comment 11

9 years ago
I'll take a look, it's probably a name mismatch...

bob
You need to log in before you can comment on or make changes to this bug.