Issue 126891 - bundled nss-3.14.4-with-nspr-4.9.5 has many security vulnerabilities
Summary: bundled nss-3.14.4-with-nspr-4.9.5 has many security vulnerabilities
Status: RESOLVED FIXED
Alias: None
Product: Build Tools
Classification: Code
Component: external prerequisites (show other issues)
Version: 4.2.0-dev
Hardware: All All
: P5 (lowest) Normal (vote)
Target Milestone: 4.1.8
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-03-26 07:50 UTC by Don Lewis
Modified: 2020-09-26 10:30 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: 4.2.0-dev
Developer Difficulty: ---


Attachments
patch to upgrade to nss-3.23-with-nspr-4.12 (19.36 KB, patch)
2016-03-26 07:50 UTC, Don Lewis
no flags Details | Diff
revised patch to upgrade to nss-3.23-with-nspr-4.12 (20.00 KB, patch)
2016-03-29 04:41 UTC, Don Lewis
no flags Details | Diff
revised patch to upgrade to nss-3.24-with-nspr-4.12 (21.25 KB, patch)
2016-06-15 09:05 UTC, Don Lewis
no flags Details | Diff
revised^2 patch to upgrade to nss-3.24-with-nspr-4.12 (21.97 KB, patch)
2016-06-16 17:00 UTC, Don Lewis
no flags Details | Diff
revised^3 patch to upgrade to nss-3.24-with-nspr-4.12 (22.46 KB, patch)
2016-06-18 21:41 UTC, Don Lewis
no flags Details | Diff
patch to upgrade to nss-3.25-with-nspr-4.12 (23.79 KB, patch)
2016-07-17 15:14 UTC, Don Lewis
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description Don Lewis 2016-03-26 07:50:50 UTC
Created attachment 85369 [details]
patch to upgrade to nss-3.23-with-nspr-4.12

The nss-3.14.4-with-nspr-4.9.5 software bundled with OpenOffice has
these vulnerabilities:
    CVE-2014-1533
    CVE-2014-1534
    CVE-2014-1536
    CVE-2014-1537
    CVE-2014-1540
    CVE-2014-1541
    CVE-2014-1542
    CVE-2014-1543
    CVE-2014-1544
    CVE-2014-1545
    CVE-2014-1547
    CVE-2014-1548
    CVE-2014-1549
    CVE-2014-1550
    CVE-2014-1551
    CVE-2014-1552
    CVE-2014-1555
    CVE-2014-1556
    CVE-2014-1557
    CVE-2014-1558
    CVE-2014-1559
    CVE-2014-1560
    CVE-2014-1561
    CVE-2014-1568
    CVE-2014-1569
    CVE-2014-1587
    CVE-2014-1588
    CVE-2014-1589
    CVE-2014-1590
    CVE-2014-1591
    CVE-2014-1592
    CVE-2014-1593
    CVE-2014-1594
    CVE-2014-1595
    CVE-2015-4513
    CVE-2015-4514
    CVE-2015-4515
    CVE-2015-4518
    CVE-2015-7181
    CVE-2015-7182
    CVE-2015-7183
    CVE-2015-7185
    CVE-2015-7186
    CVE-2015-7187
    CVE-2015-7188
    CVE-2015-7189
    CVE-2015-7190
    CVE-2015-7191
    CVE-2015-7192
    CVE-2015-7193
    CVE-2015-7194
    CVE-2015-7195
    CVE-2015-7196
    CVE-2015-7197
    CVE-2015-7198
    CVE-2015-7199
    CVE-2015-7200
    CVE-2015-7575
    CVE-2016-1938
    CVE-2016-1950
    CVE-2016-1978
    CVE-2016-1979

Whether any of these actually impacts OpenOffice is not known.

The attached patch upgrades to nss-3.23-with-nspr-4.12 which
has no publicly disclosed vulnerabilities at this time.  The
nss patches are rebased to the new version and any non-conflicting
changes are moved from the [latform-specific patch files to
nss.patch.  The nss.patch.mingw file was already out of date and
was not updated.
Comment 1 Kay 2016-03-27 21:46:59 UTC
Add me.
Comment 2 Kay 2016-03-29 02:24:43 UTC
OK, I incorporated your patch and updated to rev v. 1736692.

I'm getting a failure from this patch with the following particulars (I use -P2 build option so I hope this makes sense):

make[2]: Entering directory `.../trunk/main/nss/unxlngi6/misc/build/nss-3.23/nss/external_tests/der_gtest'
if test ! -d out; then rm -rf out; ../../coreconf/nsinstall/out/nsinstall -D out; fi
g++ -o out/der_getint_unittest.o -c -O2 -fPIC -Di386 -DLINUX2_1  -pipe -ffunction-sections -fdata-sections -DLINUX -Dlinux -DHAVE_STRERROR -DHAVE_UNISTD_H -Wall -DNSS_NO_GCC48 -DXP_UNIX -UDEBUG -DNDEBUG -D_REENTRANT -DUSE_UTIL_DIRECTLY -DNO_NSPR_10_SUPPORT -DSSL_DISABLE_DEPRECATED_CIPHER_SUITE_NAMES -I../../external_tests/google_test/gtest/include -I../../external_tests/common -I../../../dist/out/include -I../../../dist/public/nss -I../../../dist/private/nss -I../../../dist/public/nspr -I../../../dist/public/nss -I../../../dist/public/libdbm -I../../../dist/public/gtest  -std=c++0x der_getint_unittest.cc

--more stuff --

g++ -o out/der_gtest.o -c -O2 -fPIC -Di386 -DLINUX2_1  -pipe -ffunction-sections -fdata-sections -DLINUX -Dlinux -DHAVE_STRERROR -DHAVE_UNISTD_H -Wall -DNSS_NO_GCC48 -DXP_UNIX -UDEBUG -DNDEBUG -D_REENTRANT -DUSE_UTIL_DIRECTLY -DNO_NSPR_10_SUPPORT -DSSL_DISABLE_DEPRECATED_CIPHER_SUITE_NAMES -I../../external_tests/google_test/gtest/include -I../../external_tests/common -I../../../dist/out/include -I../../../dist/public/nss -I../../../dist/private/nss -I../../../dist/public/nspr -I../../../dist/public/nss -I../../../dist/public
/libdbm -I../../../dist/public/gtest  -std=c++0x der_gtest.cc

--- more stuff --

der_gtest.cc: In function 'int main(int, char**)':
der_gtest.cc:14: error: 'nullptr' was not declared in this scope
make[2]: *** [out/der_gtest.o] Error 1
make[2]: Leaving directory `.../trunk/main/nss/unxlngi6/misc/build/nss-3.23/nss/external_tests/der_gtest'
make[1]: *** [libs] Error 2
make[1]: Leaving directory `.../trunk/main/nss/unxlngi6/misc/build/nss-3.23/nss/external_tests'
make: *** [libs] Error 2
dmake:  Error code 2, while making './unxlngi6/misc/build/so_built_nss'
Comment 3 Don Lewis 2016-03-29 04:18:07 UTC
What version of gcc are you using?  nullptr is a c++11 feature that is supposed to have first appeared in gcc 4.6.  I test compiled der_gtest.cc with gcc 4.8 here and got the same error unless I specified -std=c++0x.  Since your build is using that option, I suspect that your gcc is too old.

Since this could also affect Windows builds and nullptr is only used in the test code, I think the easiest thing to do would be to skip the tests during the build.

Find this in main/nss/makefile.mk:

BUILD_DIR=nss
BUILD_ACTION= $(GNUMAKE) nss_build_all
#See #i105566# && moz#513024#
.IF "$(OS)"=="LINUX"
BUILD_ACTION+=FREEBL_NO_DEPEND=1 FREEBL_LOWHASH=1
PATCH_FILES+=nss_linux.patch
.ENDIF

Change this line:
BUILD_ACTION= $(GNUMAKE) nss_build_all
to:
BUILD_ACTION= $(GNUMAKE) nss_build_all NSS_DISABLE_GTESTS=1
Comment 4 Don Lewis 2016-03-29 04:41:09 UTC
Created attachment 85375 [details]
revised patch to upgrade to nss-3.23-with-nspr-4.12

This patch disables the nss tests which require at least partial c++11 (-std=c++0x) support because they use nullptr.  This reportedly requires at least gcc 4.6.
Comment 5 Kay 2016-03-29 16:37:23 UTC
(In reply to Don Lewis from comment #3)
> What version of gcc are you using?  nullptr is a c++11 feature that is
> supposed to have first appeared in gcc 4.6.  I test compiled der_gtest.cc
> with gcc 4.8 here and got the same error unless I specified -std=c++0x. 
> Since your build is using that option, I suspect that your gcc is too old.
> 
> Since this could also affect Windows builds and nullptr is only used in the
> test code, I think the easiest thing to do would be to skip the tests during
> the build.
> 
> Find this in main/nss/makefile.mk:
> 
> BUILD_DIR=nss
> BUILD_ACTION= $(GNUMAKE) nss_build_all
> #See #i105566# && moz#513024#
> .IF "$(OS)"=="LINUX"
> BUILD_ACTION+=FREEBL_NO_DEPEND=1 FREEBL_LOWHASH=1
> PATCH_FILES+=nss_linux.patch
> .ENDIF
> 
> Change this line:
> BUILD_ACTION= $(GNUMAKE) nss_build_all
> to:
> BUILD_ACTION= $(GNUMAKE) nss_build_all NSS_DISABLE_GTESTS=1

OK, my gcc is quite old -- gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16). I'm on CentOS 6.7. We use CentOS5 as our baseline currently, so I suspect this will impact our distributed builds as well.

I will add this option and see what happens. I did a complete and successful build before these changes about a week ago. later...
Comment 6 Don Lewis 2016-03-29 16:42:26 UTC
Try my updated patch which adds this option for all platforms except Mac.
Comment 7 Don Lewis 2016-06-15 09:05:06 UTC
Created attachment 85574 [details]
revised patch to upgrade to nss-3.24-with-nspr-4.12

nss is now up to version 3.24, which is a feature enhancement and bug fix release.  There are no additional security fixes.

Windows also has problems building the tests that require c++11.  Unfortunately the previous patch did not contain the proper magic to disable them.
Comment 8 Don Lewis 2016-06-15 22:50:30 UTC
I've gotten this to build on FreeBSD, Ubuntu 12, and Windows.
Comment 9 Don Lewis 2016-06-16 17:00:11 UTC
Created attachment 85577 [details]
revised^2 patch to upgrade to nss-3.24-with-nspr-4.12

Fix build issue on FreeBSD 11.0 and other platforms with picky compilers.  The result of shifting a negative signed value is undefined in C and C++.  The generated code does the expected thing in my experience and this construct just generates a compiler warning, but nss-3.24/nss/lib/zlib/inflate.c is compiled with -Werror, which breaks the build.  Fix the issue by doing the calculations using the equivalent unsigned type.  The function return should probably also be changed, but that is more invasive.

Unfortunately I am now observing a build error on Windows:

Compiling: xmlsecurity/source/xmlsec/nss/cl : Command line warning D9025 : overriding '/GR' with '/GR-'
nssinitializer.cxx
C:/PROGRA~1/MICROS~1.0/VC/include\ivec.h(96) : warning C4190: '&' has C-linkage specified, but returns UDT 'M64' which is incompatible with C
        C:/PROGRA~1/MICROS~1.0/VC/include\ivec.h(77) : see declaration of 'M64'
C:/PROGRA~1/MICROS~1.0/VC/include\ivec.h(97) : warning C4190: '|' has C-linkage specified, but returns UDT 'M64' which is incompatible with C
        C:/PROGRA~1/MICROS~1.0/VC/include\ivec.h(77) : see declaration of 'M64'
C:/PROGRA~1/MICROS~1.0/VC/include\ivec.h(98) : warning C4190: '^' has C-linkage specified, but returns UDT 'M64' which is incompatible with C
        C:/PROGRA~1/MICROS~1.0/VC/include\ivec.h(77) : see declaration of 'M64'
C:/PROGRA~1/MICROS~1.0/VC/include\ivec.h(99) : warning C4190: 'andnot' has C-linkage specified, but returns UDT 'M64' which is incompatible with C
        C:/PROGRA~1/MICROS~1.0/VC/include\ivec.h(77) : see declaration of 'M64'
C:/PROGRA~1/MICROS~1.0/VC/include\ivec.h(162) : warning C4190: 'cmpeq' has C-linkage specified, but returns UDT 'I32vec2' which is incompatible with C
        C:/PROGRA~1/MICROS~1.0/VC/include\ivec.h(133) : see declaration of 'I32vec2'
C:/PROGRA~1/MICROS~1.0/VC/include\ivec.h(163) : warning C4190: 'cmpneq' has C-linkage specified, but returns UDT 'I32vec2' which is incompatible with C
        C:/PROGRA~1/MICROS~1.0/VC/include\ivec.h(133) : see declaration of 'I32vec2'
C:/PROGRA~1/MICROS~1.0/VC/include\ivec.h(165) : warning C4190: 'unpack_low' has C-linkage specified, but returns UDT 'I32vec2' which is incompatible with C
        C:/PROGRA~1/MICROS~1.0/VC/include\ivec.h(133) : see declaration of 'I32vec2'
C:/PROGRA~1/MICROS~1.0/VC/include\ivec.h(166) : warning C4190: 'unpack_high' has C-linkage specified, but returns UDT 'I32vec2' which is incompatible with C
        C:/PROGRA~1/MICROS~1.0/VC/include\ivec.h(133) : see declaration of 'I32vec2'
C:/PROGRA~1/MICROS~1.0/VC/include\ivec.h(233) : warning C4190: 'cmpeq' has C-linkage specified, but returns UDT 'Is32vec2' which is incompatible with C
        C:/PROGRA~1/MICROS~1.0/VC/include\ivec.h(171) : see declaration of 'Is32vec2'
C:/PROGRA~1/MICROS~1.0/VC/include\ivec.h(233) : error C2733: second C linkage of overloaded function 'cmpeq' not allowed
        C:/PROGRA~1/MICROS~1.0/VC/include\ivec.h(233) : see declaration of 'cmpeq'
[and lots more]

My best guess is that this is erroneously getting included inside an extern "C" block, but the compiler isn't helpful enough to report the path through the nested includes.  I don't know why I did not see this problem before.
Comment 10 Kay 2016-06-16 22:34:55 UTC
(In reply to Don Lewis from comment #7)
> Created attachment 85574 [details]
> revised patch to upgrade to nss-3.24-with-nspr-4.12
> 
> nss is now up to version 3.24, which is a feature enhancement and bug fix
> release.  There are no additional security fixes.
> 
> Windows also has problems building the tests that require c++11. 
> Unfortunately the previous patch did not contain the proper magic to disable
> them.

Building with this revised patch now. I'll let you know the outcome.
Comment 11 Kay 2016-06-17 02:24:01 UTC
(In reply to Kay from comment #10)
> (In reply to Don Lewis from comment #7)
> > Created attachment 85574 [details]
> > revised patch to upgrade to nss-3.24-with-nspr-4.12
> > 
> > nss is now up to version 3.24, which is a feature enhancement and bug fix
> > release.  There are no additional security fixes.
> > 
> > Windows also has problems building the tests that require c++11. 
> > Unfortunately the previous patch did not contain the proper magic to disable
> > them.
> 
> Building with this revised patch now. I'll let you know the outcome.

OK. Good build with this new patch. No testing yet, though. I'll get to that soon.
Comment 12 Don Lewis 2016-06-17 15:49:11 UTC
I tracked the Windows build issue to the pratom.h include file from the nspr side of the new version of nss.  It includes <intrin.H> inside an extern "C" block.  I won't have the first build results on Windows until late tonight.  If that works, I hope to be able to have build results on the other platforms tomorrow morning.  The change should only affect Windows.
Comment 13 Don Lewis 2016-06-18 21:41:40 UTC
Created attachment 85583 [details]
revised^3 patch to upgrade to nss-3.24-with-nspr-4.12

With this version of the patch, I am able to get successful builds with FreeBSD 10, FreeBSD 11, and Ubuntu 12.  The Windows build is still in progress, but it has gotten past the point where it previously failed.
Comment 14 Don Lewis 2016-06-19 16:49:51 UTC
I also got a successful build on Windows.
Comment 15 Kay 2016-06-21 02:33:03 UTC
Good build on CentOS 6.8 32-bit for me. I'll do some testing on docs soon.
Comment 16 Kay 2016-06-21 20:59:41 UTC
Well...bad news. I tried to open a doc, an .odt file, and just sign it, 
and no go! :(

I did the same with my distributed version of 4.1.2 and no problems. We had quite a number of issues with this in the past, and I have an env variable set --

MOZILLA_CERTIFICATE_FOLDER=sql:/<dir>/<subdir>/.pki/nssdb

which seems to make 4.1.2 happy.

Here's the error:

Error: Error initializing security context!
From File /--some stuff--/openoffice/trunk/main/xmlsecurity/source/dialogs/digitalsignaturesdialog.cxx at Line 269
Abort ? (Yes=abort / No=ignore / Cancel=core dump)


So, maybe my build is the problem? What do you use for ./config?

This is what I use --

./configure \
  --build=i686-pc-linux-gnu \
  --host=i686-pc-linux-gnu \
  --target=i686-pc-linux-gnu \
  --with-package-format="installed rpm" \
  --disable-ldap \
  --disable-beanshell \
  --with-jdk-home=/etc/alternatives/java_sdk_1.8.0 \
  --with-junit=/usr/share/java/junit4.jar \
  --without-stlport \
  --enable-category-b \
  --with-java \
  --with-ant-home=/opt/ant \
  --with-dmake-path=/usr/local/bin/dmake \
  --without-ppds \
  --with-epm-url="http://www.msweet.org/files/project2/epm-3.7-source.tar.gz " \
  --with-lang="en-US" \
  --with-perl-home=/usr \
  --with-system-stdlibs \
  --disable-directx \
  --enable-dbus \
  --enable-opengl \
  --disable-activex \
  --disable-atl \
  --disable-gnome-vfs \
  --enable-verbose \  	
  --with-x
Comment 17 Don Lewis 2016-06-21 21:43:32 UTC
Hmn, the FreeBSD port uses the system nss and nspr and they have been at versions 3.24 and 4.12 for some time now.  The -devel version of the port tracks trunk, but is a few months old, but I don't think there have been any recent commits that would break signing.

I just tried signing an existing .odt and OpenOffice found my StartCom-issued certificate without any special settings and successfully signed the document.

These are the configure arguments used by the port:
        --with-unix-wrapper=${EXECBASE}
        --with-system-apache-commons=yes
        --with-commons-codec-jar=${JAVALIBDIR}/commons-codec.jar
        --with-commons-lang-jar=${JAVALIBDIR}/commons-lang.jar
        --with-commons-httpclient-jar=${JAVALIBDIR}/commons-httpclient.jar
        --with-commons-logging-jar=${JAVALIBDIR}/commons-logging.jar
        --with-system-apr
        --with-system-apr-util
        --with-system-beanshell
        --with-beanshell-jar=${JAVALIBDIR}/bsh.jar
        --with-system-boost
        --enable-category-b
        --with-system-cairo --enable-cairo
        --with-system-coinmp
        --with-system-curl
        --enable-crashdump
        --with-system-dicts
        --with-epm=${LOCALBASE}/bin/epm
        --with-system-expat
        --disable-fetch-external
        --without-fonts
        --with-gnu-patch=${LOCALBASE}/bin/gpatch
        --with-gperf=${LOCALBASE}/bin/gperf
        --with-system-graphite
        --enable-gtk
        --with-system-hunspell
        --with-external-dict-dir=${LOCALBASE}/share/hunspell
        --with-system-hyphen
        --with-external-hyph-dir=${LOCALBASE}/share/hyphen
        --with-system-jpeg
        --with-junit=${LOCALBASE}/share/java/classes/junit.jar
        --with-system-libtextcat
        --disable-kde
        --disable-kde4
        --with-system-libxml
        --with-system-libxslt
        --with-system-lucene
        --with-lucene-core-jar=${JAVALIBDIR}/lucene-core-3.6.2.jar
        --with-lucene-analyzers-jar=${JAVALIBDIR}/lucene-analyzers-3.6.2.jar
        --with-system-mythes
        --with-external-thes-dir=${LOCALBASE}/share/mythes
        --with-system-nss
        --enable-opengl
        --with-system-openssl
        --with-package-format="archive"
        --with-system-poppler
        --with-system-python
        --with-system-redland
        --with-system-sane
        --with-system-serf
        --with-system-stdlibs
        --without-stlport
        --with-vendor="FreeBSD ports system"
        --enable-verbose
        --with-system-vigra
        --with-system-xrender
        --with-system-zlib
        --enable-cups
        --enable-dbus
        --enable-gconf
        --enable-lockdown
        --enabled-gnone-vfs
        --disable-gio
        --enable-gstreamer
        --enable-pdfimport
        --enable wiki-publisher

Can you try the trunk version without this patch?  I'll try updating the FreeBSD port to the latest trunk.
Comment 18 Kay 2016-06-21 23:22:23 UTC
Well...let's see if we can get a build on an alternate OS, Windows, first.

And, I should have let the error boxes continue before canceling last time. My final error from inside the app sez:

"Digital signature functionality could not be used, because no Mozilla user profile was found. Please check the Mozilla installation."

At this point, my conclusion is:
* this build is ignoring my previously set and used env variable
* the env variable is somehow non-functional with this particular build, or
* because of how this version is being launched, it can't find the env variable

 I do have my own cert installed in Mozilla in addition to the default location, so I don't know what's going on.

In the past, we've  built AOO to look in what's considered default system locations, and not rely on a "Mozilla user profile".
Comment 19 Don Lewis 2016-06-22 01:24:37 UTC
I've got it built on Windows.  I'll give try signing a document with it later tonight.
Comment 20 Don Lewis 2016-06-22 04:21:44 UTC
I was able to import my certificate in Windows and sign a document.
Comment 21 Don Lewis 2016-06-22 04:35:40 UTC
I updated the FreeBSD -devel port to trunk version r1749607 and signing works for me there.  I am using my Firefox user profile.  You may be right about the problem being related to MOZILLA_CERTIFICATE_FOLDER.

On Windows, OpenOffice looks for certificates imported via the Control Panel.  It ignored my Firefox profile.  That matches the Applying Digital Signatures help page.
Comment 22 Don Lewis 2016-06-22 04:54:42 UTC
I wonder if this problem is related to
<https://bz.apache.org/ooo/show_bug.cgi?id=125431>
Comment 23 Kay 2016-06-22 15:12:15 UTC
(In reply to Don Lewis from comment #22)
> I wonder if this problem is related to
> <https://bz.apache.org/ooo/show_bug.cgi?id=125431>

I don't think so. I will investigate later today. I suspect it's related to where I'm running the test version from -- "installed" -- and the fact that it can't find the env variable setting.
Comment 24 Don Lewis 2016-06-22 16:19:32 UTC
It would be helpful it know whether or not this patch is the cause of the problem.  If the problem has another cause, that probably should be handled as a separate issue.

Unfortunately, I'm mostly unavailable to work on this for about the next week.
Comment 25 Kay 2016-06-23 21:59:48 UTC
Upon review of additional messages that I did not see before. It seems this new build IS finding the certificate location (in the syntax we were formerly told to use), but :(

[xmlsecurity] Using profile: <correct profile found>
[xmlsecurity] Initializing NSS with profile failed.

Technically my certificate is expired (??)

or perhaps the instructions/syntax we were using 
(see https://wiki.openoffice.org/wiki/Certificate_Detection) 
has changed.

Bottom line -- it looks like the certificate location IS found but there's something amisss with the the way we'd been specifying the certificate .
Bottom line -- it's likely the build is OK.
Comment 26 Kay 2016-06-23 23:05:34 UTC
Probably last comment from me on this. Likely the new nss can not verify because my cert is expired. :( The older version didn't care.
Comment 27 Kay 2016-06-30 23:42:23 UTC
More from me on this. I got a new cert and I am still a no go on signing a document. I deactivated the old  MOZILLA_CERTIFICATE_FOLDER env variable to see if that was the hangup. I have the following in my env settings: export NSS_USE_SHARED_DB=enabled

which I would think would sufffice but... ???

I only got a certificate for email and NOT document signing, but that's what I had before. What type of cert are you using?

The next step is to dig down and take a look at the calls to nss we're using and what the assumptions are vis a vis certificate locations.
Comment 28 Don Lewis 2016-07-01 00:16:37 UTC
I've got two certificates, one of which expired.  If I select the expired certificate and view its details, I get a message that it can't be validated.  If I try to sign a document with it OpenOffice crashes.

The new certificate works properly.  If I click on the View Certificate button, I get a popup that says:
  This certificate is intended for the following purpose(s):
followed by a blank line.  I got it as part of the registration process for getting a free SSL certificate from startssl.com and installed it with firefox.

I don't have any environment variables set.
Comment 29 Don Lewis 2016-07-06 18:49:20 UTC
I didn't find NSS_USE_SHARED_DB anywhere in the OpenOffice or nss code.

If I view my certificate in firefox it says:
  This certificate has been verified for the following uses:
  SSL Client Certificate
  Email Signer Certificate
  Email Recipient Certificate

The Applying Digital Signatures help page in OpenOffice says:
  Import your new root certificate, then select and edit the certificate.
  Enable the root certificate to be trusted at least for web and email
  access. This ensures that the certificate can sign your documents.
but I did not see any way of editing the permissions in firefox.
Comment 30 orcmid 2016-07-06 20:09:37 UTC
I think the information on the help page is incorrect/incomplete.

See if you can sign a document with the certificate that FireFox presented.  The certificate (and sometimes too many others) should be displayed in the signature-choice dialog of the File > Document Signatures menu selection.

The built-in Help seems to be better although it doesn't go into the procedure for obtaining and installing a certificate other than a small hand-wave.

This page is also reasonable: 
<https://wiki.openoffice.org/wiki/How_to_use_digital_Signatures>.

What is the URL of the page that appears to be deficient?
Comment 31 Don Lewis 2016-07-06 22:52:05 UTC
As I mentioned in #28, I've got two certificates that I can see in Firefox, one of which is valid and the other expired.  If I select the valid certificate in OpenOffice, I am able to successfully sign a document.  Trying the same with the expired certificate causes OpenOffice to crash, which deserves a separate bug report.

The text I quoted is from the built-in help.  The search string that took me to that page is "signing documents with digital signatures", and the text is under the "Managing your Certificates" heading.

The certificates that I've been using are the ones that I got for signing up for a free account here: <https://www.startssl.com/>.
Comment 32 Kay 2016-07-06 23:02:50 UTC
(In reply to Don Lewis from comment #29)
> I didn't find NSS_USE_SHARED_DB anywhere in the OpenOffice or nss code.
> 
> If I view my certificate in firefox it says:
>   This certificate has been verified for the following uses:
>   SSL Client Certificate
>   Email Signer Certificate
>   Email Recipient Certificate
> 
> The Applying Digital Signatures help page in OpenOffice says:
>   Import your new root certificate, then select and edit the certificate.
>   Enable the root certificate to be trusted at least for web and email
>   access. This ensures that the certificate can sign your documents.
> but I did not see any way of editing the permissions in firefox.

NSS_USE_SHARED_DB is not something that is specific to AOO. In theory, its supposed to enable finding of certificates among apps that use NSS I believe.
I've enabled it in the past for this.

For our current situation, it seems no matter what I do, my certificate can not be initialized...
 
[xmlsecurity] Initializing NSS with profile failed. 

I've always set the NSS_USE_SHARED_DB=enabled in the past along with the
OpenOffice specific export MOZILLA_CERTIFICATE_FOLDER= <some location>
I actually removed MOZILLA_CERTIFICATE_FOLDER for accessing my "local" area and it seemed that this new version was finding the correct location for my certs OK in my .mozilla area.

I can only assume at this point that the new cert I got from Comodo ONLY for email does not pass whatever test is now being used with the new nss version. However, the same cert is still fine for Digital Signing in 4.1.2. I did a rebuild today just to be sure.

I see you build --with-system-nss which I do not use. I wonder if this has any bearing? But, your Windows test was fine. Really I'm at a loss at this point.

Sorry... :(
Comment 33 orcmid 2016-07-06 23:59:04 UTC
(In reply to Don Lewis from comment #31)
[ ... ]
> The text I quoted is from the built-in help.  The search string that took me
> to that page is "signing documents with digital signatures", and the text is
> under the "Managing your Certificates" heading.

Ah, so.  The built-in help on Windows is different.  It says, under "Managing Your Certificates",

    If you are using Microsoft Windows, you can manage your certificates
    from the Control Panel applet "Internet Options" on the "Contents" 
    tab page.  Import your new root certificate into the Trusted Root
    Certification Authorities list.

In reality, the certificate generation process between the CA and a Windows PC computer happens with the browser (unless you use Symantec which has now screwed this up royally.)  The above procedure only really applies if you do a self-issued cert.

In any case, I suspect the certificate identifies what it is usable for by its Class and the only thing you should need to do on a machine where Firefox handles this instead is manage to have the certificate installed in the Firefox secure store, however that works.

When you create the other issue on using expired certificates I will test whether that happens when the Windows native private-key store is used.
Comment 34 Don Lewis 2016-07-07 00:02:08 UTC
Yeah, the FreeBSD port uses --with-system-nss, but the installed nss and nspr are very up to date:
    nss-3.25
    nspr-4.12
I don't see NSS_USE_SHARED_DB in the nss code.  I wonder if it is now the default.  This page "NSS Shared DB Howto" <https://wiki.mozilla.org/NSS_Shared_DB_Howto> is dated 2009, and I haven't turned up anything more recent.

What is strange is that while I've got ~/.pki/nssdb/cert9.db that was last modified when I installed the most recent certificate, ~/.mozilla/firefox/../cert8.db was last modified today.

Even stranger is that "certutil -L" only looks for ~/.netscape/cert7.db and .netscape/cert8.db, which it doesn't find, and then it complains:
certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an old, unsupported format.
Comment 35 orcmid 2016-07-07 00:13:10 UTC
(In reply to orcmid from comment #33)
> 
> Ah, so.  The built-in help on Windows is different.  It says, under
> "Managing Your Certificates",
> 
>     If you are using Microsoft Windows, you can manage your certificates
>     from the Control Panel applet "Internet Options" on the "Contents" 
>     tab page.  Import your new root certificate into the Trusted Root
>     Certification Authorities list.
> 
> In reality, the certificate generation process between the CA and a Windows
> PC computer happens with the browser (unless you use Symantec which has now
> screwed this up royally.)  The above procedure only really applies if you do
> a self-issued cert.
And in the case, the cert ends up in the certificate store and the Import statement is unnecessary.

I should be clear.  The above remark on certificate generation is with respect to the certificate generation process for email certificates.  These work and I would expect that to be the avenue of choice for also signing Microsoft Office (ooxml and odf) and Apache OpenOffice (odf) documents.

SSL and code-signing certificates arrive via other mechanisms.

Also the "Trusted Root Certification Authorities" list is only for installing CA certificates and that's completely not what we are talking about here. So even the simpler Windows statement is off-base.
Comment 36 Don Lewis 2016-07-07 00:41:54 UTC
I did find a bunch of references to NSS_DEFAULT_DB_TYPE.  If I set it to sql as described here: <https://wiki.mozilla.org/NSS_Shared_DB_Howto>, then certutil -L looks for cert9.db, but it looks for it under ~/.netscape/ and doesn't find it.
I tried setting MOZILLA_CERTIFICATE_FOLDER and that has no effect.

There is no man page for certutil, and certutil -h doesn't list it, but running strings on certutil turns up this option:

%-20s Cert database directory (default is ~/.netscape)
   -d certdir

Running "certutil -d ~/.pki/nssdb -L" looks like it is printing out info about one certificate, though the output is someone cryptic.

It looks like my other certificate (and a while pile of others) is in the legacy cert8.db under .mozilla if I point certutil there.

I'm guessing that Firefox and OpenOffice are looking in both places since they both see both of my signing certificates.

If you view your certificate in Firefox, what does it say about what it can be used for?
Comment 37 Don Lewis 2016-07-07 02:48:36 UTC
Is your certificate password protected?
Comment 38 Don Lewis 2016-07-07 07:27:39 UTC
Strange ... I am now able to sign a document with my expired certificate.  I was playing around with MOZILLA_CERTIFICATE_FOLDER and NSS_DEFAULT_DB_TYPE, but I've got both of those unset now.

When I first try to sign the document, it gets signed, and the popup window that displays the signatures says that that the certificate can't be validated.
No crash now, though.  I don't know what changed the behavior.
Comment 39 Kay 2016-07-11 22:32:31 UTC
I am still trying this with no success! I would love for you to try re-building with the following config that was used for 4.1.2 (no need for all the LANGS however)

Linux X86--

http://svn.apache.org/viewvc/openoffice/devtools/build-scripts/4.1.2/unxlngi6/build_aoo32bit_on_centos5.sh?revision=1736814&view=markup

Linux X86_64 --
http://svn.apache.org/viewvc/openoffice/devtools/build-scripts/4.1.2/unxlngix6/build_aoo64bit_on_centos5.sh?revision=1736814&view=markup

so we can assess what happens with supplied external sources rather than supplied on your system.
Comment 40 Don Lewis 2016-07-14 00:33:13 UTC
I managed to get OpenOffice built on CentOS 7.  When I import my certificate in Firefox on the CentOS machine and try to use it in Firefox, I observe a different failure mode.  There error I get is:
"Digital signatures functionality could not be used, because no Mozilla user profile was found. Please check the Mozilla installation."  Setting MOZILLA_CERTIFICATE_FOLDER does not make a difference.

LibreOffice on the same machine is able to find the certificate.
Comment 41 Kay 2016-07-14 15:56:52 UTC
(In reply to Don Lewis from comment #40)
> I managed to get OpenOffice built on CentOS 7.  When I import my certificate
> in Firefox on the CentOS machine and try to use it in Firefox, I observe a
> different failure mode.  There error I get is:
> "Digital signatures functionality could not be used, because no Mozilla user
> profile was found. Please check the Mozilla installation."  Setting
> MOZILLA_CERTIFICATE_FOLDER does not make a difference.
> 
> LibreOffice on the same machine is able to find the certificate.

Yes. This is exactly what's happening to me also. I have the following set:
XMLSECURITY_TRACE=1

and MOZILLA_CERTIFICATE_FOLDER

With the XMLSECURITY_TRACE, it displays the correct location for my certificates but I get the same message you are getting and thus no valid cert with these changes. Also, it seems MOZ and AOO seem to demand cert8.db rather than cert9.db. I have a mix of these on my setup. Using certutil, all certs are found.

Thanks for this additional work. All I can say is, we must be missing some important access code in AOO to comply with these changes even with the patch.
Comment 42 Don Lewis 2016-07-14 19:12:08 UTC
If I use strace, I see it access .mozilla/firefox/profiles.ini and .mozilla/firefox/[profile]/secmod.db.  It does not appear to go looking for a cert*.db file.
Comment 43 Don Lewis 2016-07-14 23:44:50 UTC
I've traced the problem as the call to SECMOD_LoadModule() in nssinit.c returning module->loaded == 0.

Unfortunately my time is pretty limited for the next several days.
Comment 44 Don Lewis 2016-07-15 02:16:58 UTC
I found the problem, libfreeblpriv3.so is not getting installed.

Meanwhile, nss is up to version 3.25 ...
Comment 45 Kay 2016-07-15 21:40:08 UTC
(In reply to Don Lewis from comment #44)
> I found the problem, libfreeblpriv3.so is not getting installed.
> 
> Meanwhile, nss is up to version 3.25 ...

Fantastic detective work, Don! 

Well, hopefully we can resolve this latest hurdle on the way to this important upgrade.
Comment 46 Don Lewis 2016-07-17 15:14:25 UTC
Created attachment 85610 [details]
patch to upgrade to nss-3.25-with-nspr-4.12

Upgrade to nss-3.25.

Package and install libfreeblpriv3.so.

Temporarily change nss download URL from https to http to avoid breaking bootstrap on the buildbots.
Comment 47 Kay 2016-07-17 22:45:47 UTC
YES! All good for me on Linux-32 with the recent changes and new patch 85610!

xmlsecurity trace is complaining a LOT about my cert not being valid for application -- yeah, OK, it IS only supposed to be for email -- but AOO let me use it for digital signing and I reverified by closing and re-opening my signed doc. All good! :)

So, at this point, I would say its a go. 

An outstanding job persevering with this! Changing to RESOLVED and hoping we can get a few more folks to test this out.
Comment 48 Don Lewis 2016-07-18 06:49:09 UTC
I committed the fix as r1753148.  Unfortunately the first line of my commit message got mangled, which lost the issue #.
Comment 49 SVN Robot 2016-07-18 07:09:59 UTC
"truckman" committed SVN revision 1753163 into trunk:
#i126891# bundled nss-3.14.4-with-nspr-4.9.5 has many security
Comment 50 Matthias Seidel 2020-09-26 10:30:37 UTC
Committed to AOO418 as part of:

https://github.com/apache/openoffice/pull/94