Re: NSS and NSPR compilation error: ssl3con.c:36:18: fatal error: zlib.h: No such file
Thanks for helping of yours! Now I have enabled the option you said, with this line: sudo make nss_build_all NSS_SSL_ENABLE_ZLIB= BUILD_OPT=1 Before that I also installed zlib1g-dev sudo apt-get install zlib1g-dev And all errors are gone! Thanks a lot and have a good day. 1 week struggling... 2016-10-20 23:08 GMT+00:00 Martin Thomson : > You can compile with > > make nss_build_all NSS_SSL_ENABLE_ZLIB= > > To disable zlib. It's not a feature you want, we just keep it because > some existing users depend on it. > > On Thu, Oct 20, 2016 at 11:10 PM, Kai Engert wrote: > > On Thu, 2016-10-20 at 10:13 +, Ding Yangliang wrote: > >> ssl3con.c:36:18: fatal error: zlib.h: no such file or directory > > > > zlib.h is a file that should be provided by your development environment. > > > > I don't know what package on Ubuntu provides that file, but I'm guessing > the > > name should be similar to zlib-dev. > > > > Kai > > > > -- > > dev-tech-crypto mailing list > > dev-tech-crypto@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-tech-crypto > -- > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto > -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
NSS_Context and FIPS
I'm trying to figure out how to dynamically enable FIPS support for NSS Contexts. I started with multinit.c and initialize FIPS right after calling NSS_InitContext() using this: if (!PK11_IsFIPS()) { fprintf(stderr, "Initializing FIPS\n"); SECMODModule *mod = SECMOD_GetInternalModule(); if (!mod) { fprintf(stderr, "No module!?\n"); exit(1); } char * internal_name = PR_smprintf("%s", SECMOD_GetInternalModule()->commonName); if ((SECMOD_DeleteInternalModule(internal_name) != SECSuccess) || !PK11_IsFIPS()) { fprintf(stderr, "Unable to enable FIPS mode on certificate database\n"); exit(1); } I'm executing it like this, initializing only db1 and db2 as contexts: $ ./multinit --verbose --lib1_db db1/ --lib2_db db2 --lib1_command list_certs --lib2_command list_certs --lib1_readonly --lib2_readonly --order 12zi This is the output: $ ./multinit --verbose --lib1_db db1/ --lib2_db db2 --lib1_command list_certs --lib2_command list_certs --lib1_readonly --lib2_readonly --order 12zi * initializing with order "12zi"* *NSS_Init for lib1* Checking for FIPS Initializing FIPS *Executing nss command "list_certs" for lib1* cacert CTu,Cu,Cu * Slot=NSS FIPS 140-2 Certificate DB* * Nickname=cacert* * Subject=* * Issuer=* * SN=01 * Server-Cert u,u,u * Slot=NSS FIPS 140-2 Certificate DB* * Nickname=Server-Cert* * Subject=* * Issuer=* * SN=04 * *NSS_Init for lib2* Checking for FIPS FIPS already enabled *Executing nss command "list_certs" for lib1* *Executing nss command "list_certs" for lib2* *NSS_Shutdown for lib2 *Shutdown lib2 state = 0 *Executing nss command "list_certs" for lib1* *NSS_Shutdown for lib1 *Shutdown lib1 state = 0 So db1 is successfully put into FIPS mode and the slot names are changed as one would expect, but then lib2 isn't set into FIPS mode and subsequently no certificates are discovered at all (I can only assume because there is a mix of FIPS and non-FIPS tokens so it throws up?) Any idea what I'm doing wrong? thanks rob -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS_Context and FIPS
On 10/21/2016 07:04 AM, Rob Crittenden wrote: I'm trying to figure out how to dynamically enable FIPS support for NSS Contexts. I started with multinit.c and initialize FIPS right after calling NSS_InitContext() using this: So you can't change the state of an already open database. NSS will switch all new databases that are opened, and idle the old ones (basically they are open, but not really accessible). if (!PK11_IsFIPS()) { fprintf(stderr, "Initializing FIPS\n"); SECMODModule *mod = SECMOD_GetInternalModule(); if (!mod) { fprintf(stderr, "No module!?\n"); exit(1); } char * internal_name = PR_smprintf("%s", SECMOD_GetInternalModule()->commonName); if ((SECMOD_DeleteInternalModule(internal_name) != SECSuccess) || !PK11_IsFIPS()) { fprintf(stderr, "Unable to enable FIPS mode on certificate database\n"); exit(1); } I'm executing it like this, initializing only db1 and db2 as contexts: So when you do an initcontext, you're main database is usually not the same as the main database when you open NSS, so it won't get automatically switched. Is there a reason you are trying to do a dynamic switch to FIPS mode from within a library? (I'd like to know the use case). Dynamic switching is a pretty careful choreographed dance that applications like mozilla can execute with care. It usually involves both fips and non-fips tokens opened for a short period until all the references can be cleared. Databases opened before the switch will almost certainly be inaccessible. $ ./multinit --verbose --lib1_db db1/ --lib2_db db2 --lib1_command list_certs --lib2_command list_certs --lib1_readonly --lib2_readonly --order 12zi This is the output: $ ./multinit --verbose --lib1_db db1/ --lib2_db db2 --lib1_command list_certs --lib2_command list_certs --lib1_readonly --lib2_readonly --order 12zi * initializing with order "12zi"* *NSS_Init for lib1* Checking for FIPS Initializing FIPS *Executing nss command "list_certs" for lib1* cacert CTu,Cu,Cu * Slot=NSS FIPS 140-2 Certificate DB* * Nickname=cacert* * Subject=* * Issuer=* * SN=01 * Server-Cert u,u,u * Slot=NSS FIPS 140-2 Certificate DB* * Nickname=Server-Cert* * Subject=* * Issuer=* * SN=04 * *NSS_Init for lib2* Checking for FIPS FIPS already enabled *Executing nss command "list_certs" for lib1* *Executing nss command "list_certs" for lib2* *NSS_Shutdown for lib2 *Shutdown lib2 state = 0 *Executing nss command "list_certs" for lib1* *NSS_Shutdown for lib1 *Shutdown lib1 state = 0 So db1 is successfully put into FIPS mode and the slot names are changed as one would expect, but then lib2 isn't set into FIPS mode and subsequently no certificates are discovered at all (I can only assume because there is a mix of FIPS and non-FIPS tokens so it throws up?) yes. Any idea what I'm doing wrong? pushing the limits of what is possible;). So things are acting as I would expect. your other lib will likely need to shutdown it's database and reopen it. bob thanks rob -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS_Context and FIPS
Robert Relyea wrote: On 10/21/2016 07:04 AM, Rob Crittenden wrote: I'm trying to figure out how to dynamically enable FIPS support for NSS Contexts. I started with multinit.c and initialize FIPS right after calling NSS_InitContext() using this: So you can't change the state of an already open database. NSS will switch all new databases that are opened, and idle the old ones (basically they are open, but not really accessible). if (!PK11_IsFIPS()) { fprintf(stderr, "Initializing FIPS\n"); SECMODModule *mod = SECMOD_GetInternalModule(); if (!mod) { fprintf(stderr, "No module!?\n"); exit(1); } char * internal_name = PR_smprintf("%s", SECMOD_GetInternalModule()->commonName); if ((SECMOD_DeleteInternalModule(internal_name) != SECSuccess) || !PK11_IsFIPS()) { fprintf(stderr, "Unable to enable FIPS mode on certificate database\n"); exit(1); } I'm executing it like this, initializing only db1 and db2 as contexts: So when you do an initcontext, you're main database is usually not the same as the main database when you open NSS, so it won't get automatically switched. Is there a reason you are trying to do a dynamic switch to FIPS mode from within a library? (I'd like to know the use case). I'm converting mod_nss to use contexts. I previously had an option to switch on FIPS mode which turned it on in NSS, did some sanity checking on the cipher options and required a password. I'd be ok requiring an all or nothing with the FIPS databases if that simplifies thiungs. Dynamic switching is a pretty careful choreographed dance that applications like mozilla can execute with care. It usually involves both fips and non-fips tokens opened for a short period until all the references can be cleared. Databases opened before the switch will almost certainly be inaccessible. $ ./multinit --verbose --lib1_db db1/ --lib2_db db2 --lib1_command list_certs --lib2_command list_certs --lib1_readonly --lib2_readonly --order 12zi This is the output: $ ./multinit --verbose --lib1_db db1/ --lib2_db db2 --lib1_command list_certs --lib2_command list_certs --lib1_readonly --lib2_readonly --order 12zi * initializing with order "12zi"* *NSS_Init for lib1* Checking for FIPS Initializing FIPS *Executing nss command "list_certs" for lib1* cacert CTu,Cu,Cu * Slot=NSS FIPS 140-2 Certificate DB* * Nickname=cacert* * Subject=* * Issuer=* * SN=01 * Server-Cert u,u,u * Slot=NSS FIPS 140-2 Certificate DB* * Nickname=Server-Cert* * Subject=* * Issuer=* * SN=04 * *NSS_Init for lib2* Checking for FIPS FIPS already enabled *Executing nss command "list_certs" for lib1* *Executing nss command "list_certs" for lib2* *NSS_Shutdown for lib2 *Shutdown lib2 state = 0 *Executing nss command "list_certs" for lib1* *NSS_Shutdown for lib1 *Shutdown lib1 state = 0 So db1 is successfully put into FIPS mode and the slot names are changed as one would expect, but then lib2 isn't set into FIPS mode and subsequently no certificates are discovered at all (I can only assume because there is a mix of FIPS and non-FIPS tokens so it throws up?) yes. Any idea what I'm doing wrong? pushing the limits of what is possible;). So things are acting as I would expect. your other lib will likely need to shutdown it's database and reopen it. I'm still a little unclear. So if I open all the databases, and THEN set FIPS mode, that will do the trick? I was pretty sure I tried that but who knows. thanks rob -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS_Context and FIPS
On 10/21/2016 01:59 PM, Rob Crittenden wrote: Robert Relyea wrote: On 10/21/2016 07:04 AM, Rob Crittenden wrote: I'm trying to figure out how to dynamically enable FIPS support for NSS Contexts. I started with multinit.c and initialize FIPS right after calling NSS_InitContext() using this: So you can't change the state of an already open database. NSS will switch all new databases that are opened, and idle the old ones (basically they are open, but not really accessible). if (!PK11_IsFIPS()) { fprintf(stderr, "Initializing FIPS\n"); SECMODModule *mod = SECMOD_GetInternalModule(); if (!mod) { fprintf(stderr, "No module!?\n"); exit(1); } char * internal_name = PR_smprintf("%s", SECMOD_GetInternalModule()->commonName); if ((SECMOD_DeleteInternalModule(internal_name) != SECSuccess) || !PK11_IsFIPS()) { fprintf(stderr, "Unable to enable FIPS mode on certificate database\n"); exit(1); } I'm executing it like this, initializing only db1 and db2 as contexts: So when you do an initcontext, you're main database is usually not the same as the main database when you open NSS, so it won't get automatically switched. Is there a reason you are trying to do a dynamic switch to FIPS mode from within a library? (I'd like to know the use case). I'm converting mod_nss to use contexts. I previously had an option to switch on FIPS mode which turned it on in NSS, did some sanity checking on the cipher options and required a password. Did you know if it was used much? I'd be ok requiring an all or nothing with the FIPS databases if that simplifies thiungs. That's probably the best. NSS allows mixed FIPS/non-fips to a point, but really only to add the transition from one to another. Only one is usefully active at once. So things are acting as I would expect. your other lib will likely need to shutdown it's database and reopen it. I'm still a little unclear. So if I open all the databases, and THEN set FIPS mode, that will do the trick? I was pretty sure I tried that but who knows. No, you need to switch to FIPS mode first. It's the databases that were opened before you got into FIPS mode that's the issue. (NOTE: when you swith from FIPS to non-fips, you are actually switching modules. The old modules and their slots hang around only as long as there are references to them. Everthing you open before you switch to FIPS mode will be on the old module which will go defunct after the switch). bob -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: NSS_Context and FIPS
Robert Relyea wrote: On 10/21/2016 07:04 AM, Rob Crittenden wrote: I'm trying to figure out how to dynamically enable FIPS support for NSS Contexts. I started with multinit.c and initialize FIPS right after calling NSS_InitContext() using this: So you can't change the state of an already open database. NSS will switch all new databases that are opened, and idle the old ones (basically they are open, but not really accessible). if (!PK11_IsFIPS()) { fprintf(stderr, "Initializing FIPS\n"); SECMODModule *mod = SECMOD_GetInternalModule(); if (!mod) { fprintf(stderr, "No module!?\n"); exit(1); } char * internal_name = PR_smprintf("%s", SECMOD_GetInternalModule()->commonName); if ((SECMOD_DeleteInternalModule(internal_name) != SECSuccess) || !PK11_IsFIPS()) { fprintf(stderr, "Unable to enable FIPS mode on certificate database\n"); exit(1); } I'm executing it like this, initializing only db1 and db2 as contexts: So when you do an initcontext, you're main database is usually not the same as the main database when you open NSS, so it won't get automatically switched. A further question: Is NSS_Initialize required or can I just use all contexts everywhere? rob -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto