USE_STATIC_LIBS fails to compile
Compiler details == $ make --version GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for i386-apple-darwin11.3.0 $ gcc --version i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Downloaded the recent NSS/NSPR https://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_15_4_RTM/src/nss-3.15.4-with-nspr-4.10.2.tar.gz $ tar -xvzf nss-3.15.4-with-nspr-4.10.2.tar.gz $ cd nss-3.15.4/nss/ $ export USE_STATIC_LIBS=1 $ make nss_build_all ERROR gcc -arch i386 -o Darwin12.5.0_DBG.OBJ/certutil -g -fPIC -Di386 -Wall -fno-common -pipe -DDARWIN -DHAVE_STRERROR -DHAVE_BSD_FLOCK -DXP_UNIX -DNSPR20 -DDEBUG -UNDEBUG -DDEBUG_hari -DUSE_UTIL_DIRECTLY -DNO_NSPR_10_SUPPORT -DNSS_USE_STATIC_LIBS -I../../../dist/Darwin12.5.0_DBG.OBJ/include -I../../../dist/public/nss -I../../../dist/private/nss -I../../../dist/public/dbm -I../../../dist/public/seccmd Darwin12.5.0_DBG.OBJ/certext.o Darwin12.5.0_DBG.OBJ/certutil.o Darwin12.5.0_DBG.OBJ/keystuff.o ../../../dist/Darwin12.5.0_DBG.OBJ/lib/libsmime.a ../../../dist/Darwin12.5.0_DBG.OBJ/lib/libssl.a ../../../dist/Darwin12.5.0_DBG.OBJ/lib/libnss.a ../../../dist/Darwin12.5.0_DBG.OBJ/lib/libssl.a ../../../dist/Darwin12.5.0_DBG.OBJ/lib/libsectool.a ../../../dist/Darwin12.5.0_DBG.OBJ/lib/libpkcs12.a ../../../dist/Darwin12.5.0_DBG.OBJ/lib/libpkcs7.a ../../../dist/Darwin12.5.0_DBG.OBJ/lib/libcerthi.a ../../../dist/Darwin12.5.0_DBG.OBJ/lib/libpk11wrap.a ../../../dist/Darwin12.5.0_DBG.OBJ/lib/l ibcryptohi.a ../../../dist/Darwin12.5.0_DBG.OBJ/lib/libcerthi.a ../../../dist/Darwin12.5.0_DBG.OBJ/lib/libnsspki.a ../../../dist/Darwin12.5.0_DBG.OBJ/lib/libpk11wrap.a ../../../dist/Darwin12.5.0_DBG.OBJ/lib/libsoftokn.a ../../../dist/Darwin12.5.0_DBG.OBJ/lib/libcertdb.a ../../../dist/Darwin12.5.0_DBG.OBJ/lib/libnsspki.a ../../../dist/Darwin12.5.0_DBG.OBJ/lib/libnssdev.a ../../../dist/Darwin12.5.0_DBG.OBJ/lib/libnssb.a ../../../dist/Darwin12.5.0_DBG.OBJ/lib/libfreebl.a ../../../dist/Darwin12.5.0_DBG.OBJ/lib/libdbm.a ../../../dist/Darwin12.5.0_DBG.OBJ/lib/libpkixtop.a ../../../dist/Darwin12.5.0_DBG.OBJ/lib/libpkixutil.a ../../../dist/Darwin12.5.0_DBG.OBJ/lib/libpkixsystem.a ../../../dist/Darwin12.5.0_DBG.OBJ/lib/libpkixcrlsel.a ../../../dist/Darwin12.5.0_DBG.OBJ/lib/libpkixmodule.a ../../../dist/Darwin12.5.0_DBG.OBJ/lib/libpkixstore.a ../../../dist/Darwin12.5.0_DBG.OBJ/lib/libpkixparams.a ../../../dist/Darwin12.5.0_DBG.OBJ/lib/libpkixchecker.a ../../../dist/Darwin12.5.0_DBG.O BJ/lib/libpkixpki.a ../../../dist/Darwin12.5.0_DBG.OBJ/lib/libpkixtop.a ../../../dist/Darwin12.5.0_DBG.OBJ/lib/libpkixresults.a ../../../dist/Darwin12.5.0_DBG.OBJ/lib/libpkixcertsel.a ../../../dist/Darwin12.5.0_DBG.OBJ/lib/libnss.a ../../../dist/Darwin12.5.0_DBG.OBJ/lib/libpk11wrap.a ../../../dist/Darwin12.5.0_DBG.OBJ/lib/libcerthi.a -L../../../dist/Darwin12.5.0_DBG.OBJ/lib -lsqlite3 -L../../../dist/Darwin12.5.0_DBG.OBJ/lib -lnssutil3 -L../../../dist/Darwin12.5.0_DBG.OBJ/lib -lplc4 -lplds4 -lnspr4 duplicate symbol _SECKEY_PQGParamsTemplate in: Darwin12.5.0_DBG.OBJ/keystuff.o ../../../dist/Darwin12.5.0_DBG.OBJ/lib/libcryptohi.a(seckey.o) duplicate symbol _CERT_OidSeqTemplate in: Darwin12.5.0_DBG.OBJ/certext.o ../../../dist/Darwin12.5.0_DBG.OBJ/lib/libcertdb.a(polcyxtn.o) ld: 2 duplicate symbols for architecture i386 collect2: ld returned 1 exit status make[2]: *** [Darwin12.5.0_DBG.OBJ/certutil] Error 1 make[1]: *** [libs] Error 2 make: *** [libs] Error 2 Should I do anything else? -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
USE_STATIC_LIBS=1; make nss_build_all fails?
I'm on Mac OS X and compiling the nss with nspr. I want to build the binaries (signtool) use the static library. But the build fails with duplicate errors. ld: duplicate symbol _CERT_OidSeqTemplate in ../../../dist/Darwin11.4.2_DBG.OBJ/lib/libcertdb.a(polcyxtn.o) and Darwin11.4.2_DBG.OBJ/certext.o collect2: ld returned 1 exit status make[2]: *** [Darwin11.4.2_DBG.OBJ/certutil] Error 1 make[1]: *** [libs] Error 2 make: *** [libs] Error 2 Any solutions? -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [Alert! Online Banking VbV]
VerefedByVisa sercive@ppai|.com wrote in message news:mailman.139.1360444568.29872.dev-tech-cry...@lists.mozilla.org... Phishing in a news group. How nice. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Intel Identity Protection Technology with PKI
From: Anders Rundgren anders.rundg...@telia.com http://www.intel.com/content/www/us/en/architecture-and-technology/identity-protection/public-key-infrastructure.html Like most HW-security solutions this appears to be more or less secret... Anders This is the result of Intel's acquisition of McAfee. PKI and CAC are the cornerstones of Today's DoD INFOSEC. -- Dave Multi-AV Scanning Tool - http://multi-av.thespykiller.co.uk http://www.pctipp.ch/downloads/dl/35905.asp -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [ANNOUNCE] NSS 3.12.11 Release
From: Robert Relyea rrel...@redhat.com On 08/16/2011 07:36 AM, David H. Lipman wrote: From: Wan-Teh Chang w...@google.com The NSS 3.12.11 release is now available. The CVS tag is NSS_3_12_11_RTM. The source tarball can be downloaded from https://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_12_11_RTM/src/ The bugs fixed in NSS 3.12.11 can be found with this Bugzilla query: https://bugzilla.mozilla.org/buglist.cgi?list_id=1105376resolution=FIXEDclassification=Componentsquery_format=advancedtarget_milestone=3.12.11product=NSS plus the following bug: Bug 668397: Crash when verifying certificate chain containing Fortezza certificates (the smaller patch for NSS_3_12_BRANCH only) Wan-Teh Chang Who uses Fortezza anymore ? The were replaced with Enhanced Crypto Cards. Do you know if your code will work with these new NSA PCMCIA cards ? ;-) The code is specific to the MISSI Fortezza/SkipJack infrastructure. If the NSA PCMCIA cards use PKIX certificate standards and standard algorithms, the our code should still work (Assuming you have PKCS #11 drivers for your cards). If the cards use SkipJack and KEA, then they won't work, and probably have not worked for 10 years or more.;). Danke -- Dave Multi-AV Scanning Tool - http://multi-av.thespykiller.co.uk http://www.pctipp.ch/downloads/dl/35905.asp -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: [ANNOUNCE] NSS 3.12.11 Release
From: Wan-Teh Chang w...@google.com The NSS 3.12.11 release is now available. The CVS tag is NSS_3_12_11_RTM. The source tarball can be downloaded from https://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_12_11_RTM/src/ The bugs fixed in NSS 3.12.11 can be found with this Bugzilla query: https://bugzilla.mozilla.org/buglist.cgi?list_id=1105376resolution=FIXEDclassification=Componentsquery_format=advancedtarget_milestone=3.12.11product=NSS plus the following bug: Bug 668397: Crash when verifying certificate chain containing Fortezza certificates (the smaller patch for NSS_3_12_BRANCH only) Wan-Teh Chang Who uses Fortezza anymore ? The were replaced with Enhanced Crypto Cards. Do you know if your code will work with these new NSA PCMCIA cards ? ;-) -- Dave Multi-AV Scanning Tool - http://multi-av.thespykiller.co.uk http://www.pctipp.ch/downloads/dl/35905.asp -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: FIPS requirements changing in 2013?
From: Dave Tubbs tu...@moorglade.com Greetings, We're utilizing NSS and will be submitting a Linux-based hardware platform for FIPS certification. The FIPS/CC organization we're working with is telling us that the FIPS requirements will change in 2013. I'm wondering which NSS versions might support these 2013 specs: 1- For DSA, p = 2048 and q = 224 2- For ECDSA generation, n = 224; for ECDSA verification, n = 160 and n 224 3- RSA key generation = 2048 Just getting spun-up on the NSS code, but thought someone on the list may have some quick answers. Thanks! Have you researched it with the NIST ? -- Dave Multi-AV Scanning Tool - http://multi-av.thespykiller.co.uk http://www.pctipp.ch/downloads/dl/35905.asp -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: certutil -D corrupting NSS database...
Hey, I've been massively distracted in other projects so I'm way behind in this issue... On Sat, 2011-02-12 at 22:33 -0800, Nelson B Bolyard wrote: On 2011-01-25 13:07 PDT, Michael H. Warfield wrote: [...] Instead of having a cert in the database with the name I specified in creating the .p12 file, I ended up with a cert in the database with the name of the E-Mail address in the cert. Not sure where that problem is (openssl or the pk12util import). But, I went to delete that certificate and that's when the fun begun. certutil -D -n postmas...@wittsend.com ran without error but the cert was still there. Run it again and you get this error: [root@romulus ipsec.d]# certutil -D -n postmas...@wittsend.com -d . certutil: could not find certificate named postmas...@wittsend.com: security library: bad database. That's also when I noticed I was missing at least one other cert. I was unable to reproduce any of this with the cert DB you sent me. Before I deleted the cert with that command above, the cert DB was OK, not corrupted, and after I deleted it, it was also OK. The cert I had specified, and its nickname record AND its email record were all deleted from the DB, leaving it in a consistent state. A second delete attempt produced the same error message you saw, but didn't modify the DB at all. I tried with both certutil and libs from NSS 3.11.latest and 3.12.latest and got the same results both ways. I have these thoughts about the different behaviors that you and I experienced. 1) Maybe you had another program that was also holding the DB files open at the same time you did the certutil -D command. Nope. Absolutely not. This was done in an isolated test directory which nothing else even referenced. 2) IINM, You had the private key for some certs in your key3.db by virtue of having used pk12util to import one or more, and I didn't. That might have made a difference. Ah... Now we may have something here. I'm doing a pure import. Nothing original was created in the NSS database. Everything was imported into it. Take that as a premise. It is fundamental. Start with a database and import everything. Create nothing new within NSS itself. This is, unfortunately, a result of Fedora's decision to convert OpenSwan to use NSS. It's caused a number of people a great deal of grief. People are trying to import existing configurations into NSS and the documentation, quite frankly, doesn't work in many cases. People with established X.509 cert setups that have been working for years don't want to recreate everything from scratch. It's unfortunate that this was poorly planned with no concrete upgrade / transition mechanism in place before doing this and abysmal documentation. 3) It's possible that the original cert DB you had was in some state of corruption, and the cert DB you reconstructed for my testing was not corrupted. No. I took snapshots of the database as I performed those actions. You literally got what I had at each step of the process. Nothing was a reconstruction. I'm a practiced diagnostician and forensic investigator. Unless and until I can reproduce the behavior you saw, I won't be of much help in resolving it. Sorry. :-/ Sounds like I need to drop back a couple of steps then and give you the whole process, step by steo, from the very beginning of the creation of the database to the corruption. This I had not done. I'll go back and set those scenarios back up and reproduce them from the mkdir forward and provide you with the full import data (including the creation of the pk12 files using openssl). It may take some time. My schedule is full and I tend to get distracted. -- /Nelson Bolyard Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
{Filename?} Re: certutil -D corrupting NSS database...
the great details. -- /Nelson Bolyard -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! This is a message from the MailScanner E-Mail Virus Protection Service -- The original e-mail attachment gorgon10.wittsend.com.p12 is on the list of unacceptable attachments for this site and has been replaced by this warning message. If you wish to receive a copy of the original attachment, please e-mail helpdesk and include the whole of this message in your request. Alternatively, you can call them, with the contents of this message to hand when you call. At Sun Jan 30 12:18:41 2011 the virus scanner said: MailScanner: Attempt to hide real filename extension (gorgon10.wittsend.com.p12) Note to Help Desk: Look on the WittsEnd () MailScanner in /var/spool/MailScanner/quarantine/20110130 (message p0UHId0R012599). -- Postmaster Thaumaturgy Speculums Technology www.wittsend.com For all your IT requirements visit: http://www.transtec.co.uk signature.asc Description: This is a digitally signed message part -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
certutil -D corrupting NSS database...
Hey all! I'm posting this from one of my alternate accounts since the Mozilla sever (notorious.mozilla.org) strangely doesn't seem to like my spf record and for some reason thinks that my server at 130.205.32.3 does not match the ipv4:130.205.32.0/20 criterion in my spf record. Last I looked 130.205.32.3 was contained within 130.205.32.0/20. Go figure. IAC Just wanted to raise an issue on this list before opening a bugzilla ticket on it but I seem to have run into a circumstance under which deleting a certificate from the NSS database ends up doing the wrong thing with some real confusion resulting that looks like a corrupted or bad database (but seems to be just a poor error message). The senario is in Openswan with NSS for the peer certificates. The host certificates are imported through pk12util after being converted from their OpenSSL cert and key. The peer certificates have been imported directly using certutil -A since they don't have a private key. Everything was fine and someone on the Openswan list happen to ask why didn't I used pk12 for the peer certificate by using the -nokey option when creating them from openssl. So I tried that and didn't get an error, but the import did something strange and didn't give me the correct name from the openssl command. Instead of having a cert in the database with the name I specified in creating the .p12 file, I ended up with a cert in the database with the name of the E-Mail address in the cert. Not sure where that problem is (openssl or the pk12util import). But, I went to delete that certificate and that's when the fun begun. certutil -D -n postmas...@wittsend.com ran without error but the cert was still there. Run it again and you get this error: [root@romulus ipsec.d]# certutil -D -n postmas...@wittsend.com -d . certutil: could not find certificate named postmas...@wittsend.com: security library: bad database. That's also when I noticed I was missing at least one other cert. It appears that the first delete deleted the wrong cert and then looked like it did something bad in the database and can't find the cert showing up in the list with that name. Turned out it had deleted the first .p12 cert that I had imported and could no longer find the other cert. Looking a little closer, it looks like certutil -D will give that same bad database error anytime it can not find a named cert, so it may actually not be corrupting the database per se but it is deleting the wrong certificate and then refuse to find the right certificate at all afterwords. You can't list it even though it's still there on the list. Sequence of things I did and the results are below my signature block with a few comments in square brackets... I figure this one is heading for bugzilla one way or the other but wanted to hear others thoughts on it first. Oh... This is on Fedora 13 with nss-util 3.12.8 as well as Fedora 14 with nss-util 3.12.9. Regards, Mike -- Michael H. Warfield (AI4NB) | Desk: (404) 236-2807 Senior Researcher - X-Force | Cell: (678) 463-0932 IBM Security Services| m...@linux.vnet.ibm.com m...@wittsend.com 6303 Barfield Road | http://www.iss.net/ Atlanta, Georgia 30328 | http://www.wittsend.com/mhw/ | PGP Key: 0x674627FF -- [root@romulus ipsec.d]# certutil -L -d . Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI remus.wittsend.com u,u,u gorgon8.wittsend.com ,, romulus.wittsend.com u,u,u complex.wittsend.com ,, gorgon9.wittsend.com ,, wittsendCA C,C,C WittsEndCA C,C,C [root@romulus ipsec.d]# openssl pkcs12 -export -in certs/gorgon10.wittsend.com.crt -nokeys -name gorgon10.wittsend.com -out gorgon10.wittsend.com.p12 Enter Export Password: Verifying - Enter Export Password: [root@romulus ipsec.d]# pk12util -i gorgon10.wittsend.com.p12 -d . Enter password for PKCS12 file: pk12util: PKCS12 IMPORT SUCCESSFUL [root@romulus ipsec.d]# certutil -L -d . Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI remus.wittsend.com u,u,u gorgon8.wittsend.com ,, romulus.wittsend.com u,u,u complex.wittsend.com ,, gorgon9.wittsend.com ,, wittsendCA C,C,C WittsEndCA C,C,C postmas
Re: (nss-3.12.6) unable to engage FIPS mode: security library: invalid arguments.
On Sat, Jun 12, 2010 at 02:11:14PM -0700, Nelson B Bolyard wrote: You have a problem with a distribution of NSS that is not identical to the NSS as built from the upstream NSS source repository. Mozilla's NSS team supports NSS as it comes from the builds from the upstream NSS source repository. Mozilla's NSS team does not attempt to keep track of all the changes made to NSS by every downstream Linux distro. If the upstream NSS works, but some downstream distribution does not, then the differences are due to changes outside of the control of Mozilla's NSS team, and primary support for those problems (that are unique to a downstream distribution) must come from the suppliers of that downstream distribution. LOOK at the links I provided, there are ZERO changes to the actual source code. There is an additional file packaged for pkgconfig support, and we compile with -fno-strict-aliasing. It is true that virtually every Linux distribution modifies NSS sources significantly and distributes a downstream flavor of NSS that differs from the upstream version in a number of ways. For some distros, the differences are so minor that you can simply download the upstream NSS sources, build them yourself, and use the resultant binaries as a replacement for the binaries that came with the distribution, and it all works fine. For other distros, they've made changes on such a large scale, such as renaming the functions, renaming the shared libraries and splitting up the shared libraries so that they no longer all live in the same directory, that a vanilla build of NSS from upstream sources simply will not work with programs that were built to work with that distro's NSS libraries. If your distro is one of those, then you'll have no choice but to get help from the maintainers of that distro. NONE of the above is the case, as I noted in previous emails. The C source is absolutely stock. It may be that, in your case, the problem is as simple as this: the distro did not include the .chk files that are generated during the NSS build process, or it put them in the wrong directory or gave them the wrong file names, so that NSS cannot find them. Or they may have changed the shared libraries, but not regenerated the .chk files. If that is the case, and the distro HAS distributed NSS's shlibsign program, then you may be able to remedy this yourself by generating replacements for the missing (or old) .chk files using shlibsign. Instructions on how to use shlibsign may be found at http://www.mozilla.org/projects/security/pki/nss/tech-notes/tn6.html Ok, this helped tremendously. The root of the problem is that the shared libraries can change POST-install, as needed for ELF signing, split-debug and prelinking. The ELF signing is a catch-22. Either I have to run shlibsign afterwards, or I have to not sign those files, and leave them open to potential compromise. Running shlibsign does remedy the problem. However, this entire matter could be remedied if some more useful error had been returned instead of 'Invalid Arguments'. Something to indicate that the library checksums no longer matched. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgp2rACleeKNf.pgp Description: PGP signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: (nss-3.12.6) unable to engage FIPS mode: security library: invalid arguments.
On Sun, Jun 13, 2010 at 02:02:39AM -0700, Nelson B Bolyard wrote: The root of the problem is that the shared libraries can change POST-install, as needed for ELF signing, split-debug and prelinking. The ELF signing is a catch-22. Either I have to run shlibsign afterwards, or I have to not sign those files, and leave them open to potential compromise. Rerun shlibsign. It's fast and easy. As an intermediate related question, is there a standalone verification tool for the CHK files shlibsign -V -i seems to just sign again, not verify. Running shlibsign does remedy the problem. However, this entire matter could be remedied if some more useful error had been returned instead of 'Invalid Arguments'. Something to indicate that the library checksums no longer matched. It's open source. Patches are invited. Ok, I'll take that up. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgptVek32QP0X.pgp Description: PGP signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: (nss-3.12.6) unable to engage FIPS mode: security library: invalid arguments.
On Sun, Jun 13, 2010 at 03:08:07PM -0700, Nelson B Bolyard wrote: On 2010-06-13 13:02 PDT, Robin H. Johnson wrote: On Sun, Jun 13, 2010 at 02:02:39AM -0700, Nelson B Bolyard wrote: The root of the problem is that the shared libraries can change POST-install, as needed for ELF signing, split-debug and prelinking. The ELF signing is a catch-22. Either I have to run shlibsign afterwards, or I have to not sign those files, and leave them open to potential compromise. Rerun shlibsign. It's fast and easy. As an intermediate related question, is there a standalone verification tool for the CHK files shlibsign -V -i seems to just sign again, not verify. Yes. modutil is that test tool. You already know how to use it. Just drop the -force argument. I should have clarified, that I want to verify without any disk writes, nor assuming a pre-setup database. # modutil -chkfips true modutil: function failed: security library: bad database. Just exactly that the chk files are valid, and nothing else. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: (nss-3.12.6) unable to engage FIPS mode: security library: invalid arguments.
On Sat, Jun 12, 2010 at 12:15:07PM -0700, Matt McCutchen wrote: On Jun 12, 2:25 pm, Nelson B Bolyard nel...@bolyard.me wrote: On 2010-06-10 22:59 PDT, Robin H. Johnson wrote: The testcase has been run on Arch and Fedora now, and both of those cases it works fine. Does that mean this problem is resolved? As I read, it is not; it was reported on Gentoo Linux. No, it still exists on Gentoo, and I haven't been able to reproduce it anywhere else. Build script: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/nss/nss-3.12.6-r1.ebuild?revision=1.7view=markup Patches: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/nss/files/ -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: (nss-3.12.6) unable to engage FIPS mode: security library: invalid arguments.
On Thu, Jun 10, 2010 at 10:45:03PM +, Robin H. Johnson wrote: Testcase 2: (see attached minimal C code, based on posts to the list and used in the modutils source AND Mozilla). Bah, forgot the actual file. The testcase has been run on Arch and Fedora now, and both of those cases it works fine. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpe2R3lhYEfZ.pgp Description: PGP signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: (nss-3.12.6) unable to engage FIPS mode: security library: invalid arguments.
On Fri, Jun 11, 2010 at 05:59:27AM +, Robin H. Johnson wrote:
On Thu, Jun 10, 2010 at 10:45:03PM +, Robin H. Johnson wrote:
Testcase 2:
(see attached minimal C code, based on posts to the list and used in the
modutils source AND Mozilla).
Bah, forgot the actual file.
The testcase has been run on Arch and Fedora now, and both of those
cases it works fine.
Ah, no, this list is stripping my code.
//-
//compile: gcc nss-fipstest.c $(pkg-config --cflags nss) $(pkg-config --libs
nss) -o nss-fipstest
#include nss.h
#include pk11pub.h
#include secmod.h
/* Define to the default location of the NSS configuration directory. */
#define DEFAULT_CONFIG_DIR /etc/pki/nssdb
int main(int argc, char **argv) {
const char* configdir = DEFAULT_CONFIG_DIR;
int status;
status = NSS_NoDB_Init(configdir);
if (status != SECSuccess) {
fprintf(stderr, Error initializing NSS.\n);
return status;
}
// The way to toggle FIPS mode in NSS is extremely obscure.
// Basically, we delete the internal module, and voila it
// gets replaced with the opposite module, ie if it was
// FIPS before, then it becomes non-FIPS next.
SECMODModule *internal;
// This function returns us a pointer to a local copy of
// the internal module stashed in NSS. We don't want to
// delete it since it will cause much pain in NSS.
internal = SECMOD_GetInternalModule();
if (!internal) {
fprintf(stderr, Failed to get internal module\n);
return 1;
}
fprintf(stderr, Got internal module: %s\n, internal-commonName);
SECStatus srv = SECMOD_DeleteInternalModule(internal-commonName);
if (srv != SECSuccess) {
fprintf(stderr, Failed to delete internal module (%s)\n,
internal-commonName);
return 1;
}
return 0;
}
//-
--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
pgpb1XBtRyxwO.pgp
Description: PGP signature
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
(nss-3.12.6) unable to engage FIPS mode: security library: invalid arguments.
I was trying to package up the hmaccalc application from Fedora so we can have
it in Gentoo as well, and noticed that it was failing when it tried to engage
FIPS mode.
Doing some backtracing, it seems FIPS isn't enabling at all on my system, as
the DeleteInternalModule call is returning INVALID_ARGS.
Testcase 1:
# d=/tmp/fips M=modutil -dbdir $d ; mkdir -p $d ; $M -create -force
# $M -chkfips true ; $M -fips true -force ; $M -chkfips true
FIPS mode disabled.
security library: invalid arguments.
ERROR: Unable to switch FIPS modes.
FIPS mode disabled.
# $M -rawlist ; $M -list
name=NSS Internal PKCS #11 Module parameters=configdir=/tmp/fips
certPrefix= keyPrefix= secmod=secmod.db flags=readOnly NSS=trustOrder=75
cipherOrder=100
slotParams={0x0001=[slotFlags=RSA,RC4,RC2,DES,DH,SHA1,MD5,MD2,SSL,TLS,AES,Camellia,SEED,RANDOM
askpw=any timeout=30 ] } Flags=internal,critical
Listing of PKCS #11 Modules
---
1. NSS Internal PKCS #11 Module
slots: 2 slots attached
status: loaded
slot: NSS Internal Cryptographic Services
token: NSS Generic Crypto Services
slot: NSS User Private Key and Certificate Services
token: NSS Certificate DB
---
Testcase 2:
(see attached minimal C code, based on posts to the list and used in the
modutils source AND Mozilla).
Build params:
USE_64=1
NSPR_INCLUDE_DIR=`nspr-config --includedir`
NSPR_LIB_DIR=`nspr-config --libdir`
BUILD_OPT=1
NSS_USE_SYSTEM_SQLITE=1
NSDISTMODE=copy
NSS_ENABLE_ECC=1
XCFLAGS=${CFLAGS}
FREEBL_NO_DEPEND=1
The only patches applied in Gentoo add some pkconfig bits,
--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
pgpold6im0x1N.pgp
Description: PGP signature
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
