Apache OpenOffice (AOO) Bugzilla – Issue 124701
signing of documents/macros are broken on non windows platforms
Last modified: 2017-05-20 10:35:11 UTC
we currently have an issue with digital signing on non Windows platforms. The whole problem was introduced with the drop of some very old Mozilla stuff that made always problems. Feature description (simplified) Digital signing of document and/or macros is a feature to increase the integrity in a workflow where documents are exchanged and to build a trusted environment. 1. document signatures With a valid certificate it is possible to sign a document after it is saved. It is comparable with a seal. Other users loading this document will see a signature icon in the status bar that shows that this document is signed. Double click on this icon opens a dialog where the user can view the certificate. Two status are possible, the first one is that the certificate can be validated and is marked as trusted. The second (identified with the same icon + a yellow triangle warning sign) is where the certificate can't be validated automatically. 2. macro signatures Similar to documents the user can sign macros in the same way. When a user load a document with signed macros a dialog is opened to enable macros or not. In this dialog the user get also information that the macro is signed and is able to view the certificate. It is also possible to trust this certificate always and the next time the macro is accepted automatically. Problem This functionality was tightly coupled to Mozilla and made use of the Mozilla certificate store. At least on Linux and MacOS where as on Windows system certificate store was used directly. Current situation is that it still works on Windows but is partly broken on Linux and MacOS. Signing of new document or macros is not possible at all because no certificate store is available or better accessible. Signed documents can be loaded but the cert can't be validated. Signed macros can be loaded/enabled and executed. It is also possible to add an exception to trust this cert always to prevent the macro dialog in the future. General This feature heavily depends on the Mozilla certificate store which seems to be not optimal. For example on Mac the user would have to install Mozilla to make use of this feature. Standard browser for most users is Safari. A further observation is why I can't accept a cert for document signatures but for macro signatures. For example if I know where it comes from and know that it is a self signed cert why I can't trust this cert.
Created attachment 83213 [details] signed document simple sample document, signed with self-signed root certificate
Created attachment 83214 [details] signed macro simple sample document, containing a signed macro. Signed with a self-signed root certificate
Created attachment 83216 [details] signed doc with test cert simple sample document, signed with a self-signed root certificate "OpenOffice QA 1", see test-cert.zip
Created attachment 83217 [details] signed macro with a test certificate simple sample document, containing a macro. Signed with self-signed root certificate "OpenOffice Qa1", see test-cert.zip
Created attachment 83218 [details] 2 self-signed test certificates 2 self-signed test certificates OpenOffice QA 1 pw: openofficeqa1 OpenOffice QA 2 pw: openofficeqa2
added 2 test document, one signed document and one signed macro. And a file containing 2 self-signed test certificates usable for more detailed testing. For signing you have to import the pk12 file in your Firefox/Mozilla cert store. For verification or making the cert visible importing the cer file is enough. On Windows in your cert management console. For validation copy it as trusted root authority. Be careful and make this only of you know what are you doing.
Setting the environment variable MOZILLA_CERTIFICATE_FOLDER to the currently active Mozilla/Thunderbird/Firefox/etc. profile works around the problem. E.g. on Linux setting the environment variable could look like MOZILLA_CERTIFICATE_FOLDER=sql:/home/xxx/.mozilla/firefox/23d7j.default and on Mac it could look like MOZILLA_CERTIFICATE_FOLDER="sql:/Users/xxx/Library/Application Support/Firefox/Profiles/23d7j.default" Note the "sql:" before the directory name to indicate that the stores are in database file formats.
From a code perspective a better fix could/should be in the getMozillaCurrentProfile() function in main/xmlsecurity/source/xmlsec/nss/nssinitializer.cxx If there is only one relevant profile from in the user's Thunderbird/Mozilla/Firefox/Iceweasel/Icedove/etc. home or application support directory then choosing that directory automatically would be the right thing to do. Of course the directory name would have to be prepended by "sql:" too.
Signing documents has an erratic behaviour, with the same certifcate sometimes it wors, but sometimes not, a non-pro build shows: Error: libxml2 error: func=xmlSecIORegisterCallbacks:file=io.c:line=239:obj=unknown:subj=xmlSecPtrListAdd:error=1:xmlsec library function failed: ;last nss error=0 (0x00000000) From File /build/aoo/src/playground/trunk/main/unoxml/source/xpath/xpathapi.cxx at Line 312 4.0 does not display this erratic behaviour.
Created attachment 83226 [details] Patch to bring back mozbootstrap in its minimal profile discovery version
Are we using rev. AOO410m17(Build:9763) - Rev. 1586357 RC3 to test? No joy for me yet with putting the Linux env variable in quotes or not. Still can not find my cert.
(In reply to hdu@apache.org from comment #9) > From a code perspective a better fix could/should be in the > getMozillaCurrentProfile() > function in > main/xmlsecurity/source/xmlsec/nss/nssinitializer.cxx > > If there is only one relevant profile from in the user's > Thunderbird/Mozilla/Firefox/Iceweasel/Icedove/etc. home or application > support directory then choosing that directory automatically would be the > right thing to do. Of course the directory name would have to be prepended > by "sql:" too. IMO it would be better to bring mozbootstrap back (see attachment 83226 [details]) that already has some logic to discover profiles; by the way, it is a UNO component that implements publilshed API (with the mozilla removal the css.mozilla module should have been marked as @deprecated and then be removed in the next major version).
OK, here's some more detailed information on what I've done. 1) obtained a 25 day trial certificate from Symantec (in truth it isn't behaving all that well, but it is showing up in my Firefox and Thunderbird cert stores) 2) Added -- export MOZILLA_CERTIFICATE_FOLDER='sql:<my home directory path>/.mozilla/firefox/t207ahin.default' to .bashrc .profile .xinitrc I used the single quote because this is what I saw in another file that uses certs on my system (I have had problems in the past with adding items to my .bashrc and my X session doesn't pick them up so that's why I put it in there as well.) Still no acknowledgment by OpenOffice that this certificate even exists. I'm on openSUSE 12.3 w/ KDE 4.10 Before I got back into this today, I did some "googling" of this issue, and, it seems it been around and a problem *for a while* -- as early as 2008 for Linux folks along with various suggestions on what to do about it. Then I came across this bit from LO's BZ -- https://bugs.freedesktop.org/show_bug.cgi?id=66158 in which the UI now allows for explictly setting the cert path. I have NO idea how quick or easy this would be. I would have included it in the Paths options myself, but, a matter for discussion. Meanwhile, I have contacted Symantec about problems with the certificate itself. Maybe this is causing the hang-up though Thunderbird lets me use it in it's flawed state. I'm sorry I don't have better news.
"jsc" committed SVN revision 1589050 into trunk: #124701# bring back moz bootstrap to find profile
"jsc" committed SVN revision 1589052 into branches/AOO410: #124701# merge from trunk, bring moz bootstrap back to find profiles
patch for bringing moz bootstrap reviewed and integrated. We have now the same behaviour as before, still not optimal because the dependency to mozilla certificate stores.
Niltze! I don't understand why people insist on the sql prefix and/or quotes, "Apache OpenOffice Wiki: Certificate Detection" clearly explains that below statement is what should be, either typed before executing ApacheOO from the shell, or inserted in a file such as .bashrc at a user's home: export MOZILLA_CERTIFICATE_FOLDER=~/.mozilla/firefox/<your_user_profile> Attaching digitally signed ODT with a 'valid' certificate created under ApacheOO 4.1.0 RC3: apacheOO-4.1.0_RC3_valid-crt.odt -Jose
Created attachment 83266 [details] ApacheOO 4.1.0 RC3 sample .odt document digitally signed with valid certificate Don't rock the boat...
Hello again -- New info and SUCCESS! from me. It seems, at least according to this article from archlinux wiki -- https://wiki.archlinux.org/index.php/Network_Security_Services that for Linux, Mozilla/nss cert info is now located in $HOME/.pki/nssdb, which is true in my case with opensuse as well. So, including the following in a .bashrc file (or whatever the typical "profile" settings file is for your distro)-- export MOZILLA_CERTIFICATE_FOLDER='sql:$HOME/.pki/nssdb' should work for all Linux users. It did for me. And yes, the 'sql' prefix is needed. When I removed this, I was back to AOO not finding my certificate. I will be happy to add this tidbit to the Release Notes and/or wiki information on the subject. HTH!
sorry -- one slight change to my posting yesterday correct variable definition should be: export MOZILLA_CERTIFICATE_FOLDER=sql:$HOME/.pki/nssdb instead of: export MOZILLA_CERTIFICATE_FOLDER='sql:$HOME/.pki/nssdb' no single quotes
(In reply to Kay from comment #20) > It seems, at least according to this article from archlinux wiki -- > https://wiki.archlinux.org/index.php/Network_Security_Services > > that for Linux, Mozilla/nss cert info is now located in $HOME/.pki/nssdb, > which is true in my case with opensuse as well. Thanks for identifying the problem on these platforms! > So, including the following in a .bashrc file (or whatever the typical > "profile" settings file is for your distro)-- > > export MOZILLA_CERTIFICATE_FOLDER='sql:$HOME/.pki/nssdb' > > should work for all Linux users. It did for me. And yes, the 'sql' prefix is > needed. It doesn't work for ALL Linux users yet (e.g. some RHEL, Debian, SuSE versions) but according to [1] all Linux platforms will eventually converge to this. [1] https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX > I will be happy to add this tidbit to the Release Notes and/or wiki > information on the subject. Great! Please do so.
Changes have now been made to: https://wiki.openoffice.org/wiki/How_to_use_digital_Signatures https://wiki.openoffice.org/wiki/Certificate_Detection but, needs help with Macintosh areas. (will post to dev) Also, inline help needs to be changed at some as well to reference these wiki pages due to additional changes that may take place.