Created attachment 90184 [details] LibreOffice Error Alfresco CE 4.2e LibreOffice 4.2.0.0beta1 CA certificate is in firefox installed and work, LibreOffice point to the Firefox profil for the CA certificate. When search the repository LibreOffice ask me for Username and Passwort, after fill them in and click ok LibreOffice show me "The specified device is invalid.". Do not know whats the problem, is there a way to debug it?
Cédric: you might be interested in this one.
Same with Version: 4.2.0.0.beta2 (Build ID: 1a27be92e320f97c20d581a69ef1c8b99ea9885d) "The specified device is invalid."
Install a test setup today and libreoffice 4.2 beta2 work without https fine. In my productive system which is only available over https libreoffice show still the error. Load the "RepositoryService?wsdl" file in the terminal via wget works as expected. Can someone explain me what libreoffice with "The specified device is invalid." means? samuel@testsystem:/tmp$ wget 'https://alfresco.intern/alfresco/cmisws/RepositoryService?wsdl' --2013-12-12 16:19:23-- https://alfresco.intern/alfresco/cmisws/RepositoryService?wsdl Auflösen des Hostnamen »alfresco.intern (alfresco.intern)«... 10.23.0.52 Verbindungsaufbau zu alfresco.intern (alfresco.intern)|10.23.0.52|:443... verbunden. HTTP-Anforderung gesendet, warte auf Antwort... 200 OK Länge: nicht spezifiziert [text/xml] In »»RepositoryService?wsdl«« speichern. [ <=> ] 37.876 --.-K/s in 0,002s 2013-12-12 16:19:23 (21,3 MB/s) - »»RepositoryService?wsdl«« gespeichert [37876] samuel@testsystem:/tmp$
Just ran into the exact same problem here: CMIS connections to Alfresco 4 will not work using https, error message is 'The specified device is invalid.' Tried to investigate a bit further, here is what I found: - commandline curl will download RepositoryService?wsdl xml file fine (now that I installed the correct CA cert) - tcpdump shows no connection attempt to alfresco server as soon as I specify https - Libreoffice will ask for credentials but then display the error message dialog immediately. My impression is 'https' is not handled correctly somewhere inside libreoffice so this might not be a libcmis/licurl issue.
Same with version 4.2.0.1 Build ID: 7bf567613a536ded11709b952950c9e8f7181a4a Can confirm what guenter find out, after change to https tcpdump shows no connection attempt to alfresco server. :-(
Can someone confirm that CMIS over https work? According to libcmis news https/ssl should work: http://sourceforge.net/p/libcmis/code/ci/master/tree/NEWS It would be a real shame if ssl would not work in libreoffice 4.2 because of a gui bug in the input field.
Samuel
Just noticed I sent a little too quickly my previous comment. Anyway, I could connect to a cmis server with 4.2 sources (updated 1 week ago) and master sources (updated today). Now I'd like to test an example with https, would it be possible to give me one so I can try to reproduce and retrieve some logs ? (I build with debug mode).
(In reply to comment #8) > Just noticed I sent a little too quickly my previous comment. :) the mystery is solved. > > Anyway, I could connect to a cmis server with 4.2 sources (updated 1 week > ago) and master sources (updated today). Can confirm this in my test setup without ssl. > Now I'd like to test an example with https, would it be possible to give me > one so I can try to reproduce and retrieve some logs ? (I build with debug > mode). Unfortunately not one which is accessible over the internet, but in my test i can confirm what guenter find out. After use https LibreOffice show without any connection to the https server 'The specified device is invalid.'. I guess it go wrong in LibreOffice before libcmis start a connection to the alfresco server over https (tcpdump shows no connection). Anyway you can test with my URL: https://alfresco.intern/alfresco/cmisws/RepositoryService?wsdl Thank you for investigate in this problem.
(In reply to comment #8) > Just noticed I sent a little too quickly my previous comment. > > Anyway, I could connect to a cmis server with 4.2 sources (updated 1 week > ago) and master sources (updated today). > Now I'd like to test an example with https, would it be possible to give me > one so I can try to reproduce and retrieve some logs ? (I build with debug > mode). Julien, Alfresco provides an open cmis server which you can test against: https://cmis.alfresco.com/cmisatom http://cmis.alfresco.com/cmisatom username: admin password: admin I've reproduced the same error locally and at a client site where it is impossible to connect to an https server as of the 4.2 beta. I'm going to try the libcmis tool as soon as possible to try to verify if this error is withing libcmis or in LibreOffice.
Test with libcmis, using the 0.4 branch of libcmis which cedric worked on in december as part of another libreoffice fix. $ ./cmis-client --url http://localhost/alfresco/cmisatom list-repos Username (empty to cancel): admin Password (empty to cancel): ******** Repositories: name (id) Main Repository (b067cd88-f881-4e10-86f8-c65dede6ce0e) mars @ kakmonstret ~/Documents/libreoffice/libcmis-code/src on libcmis-0.4* $ ./cmis-client --url https://localhost/alfresco/cmisatom list-repos Username (empty to cancel): admin Password (empty to cancel): ******** Repositories: name (id) Main Repository (b067cd88-f881-4e10-86f8-c65dede6ce0e) both http and https works, so the problem seems to be in libreoffice
Thank you Marcus for your feedback. On Debian x86-64 with master sources updated today, I can reproduce the problem.
(In reply to comment #12) > Thank you Marcus for your feedback. > On Debian x86-64 with master sources updated today, I can reproduce the > problem. I'm doing some additional testing and I'm actually getting the same symptoms when running Windows 7 and LibreOffice 4.1.3.2 and 4.1.4.2. I don't see any ssl traffic going out of LibreOffice using Fiddler2 to trace.
Julien Nabet committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0d1f724f9645e7ec0da6a4c3a1c22d0dcf785cb6 Resolves: fdo#72277 https CMIS Alfresco "The specified device is invalid." The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Julien, thank you very much for the commit. Whiteboard: target:4.3.0 means that it will fixed in LibreOffice 4.3 and not in LibreOffice 4.2?
Yes the target indicated which LO version should be ok. For the moment, I pushed the fix (perhaps I forgot something but at least, I can see files from https://cmis.alfresco.com/cmisatom) on master branch (future 4.3.0). About 4.2, there's https://gerrit.libreoffice.org/#/c/7388/ which awaits for review by some devs.
I've verified that this works with the daily build of Libre 4.3.0 alpha on Win 7. It works on both the alfresco cmis server and real production server of Alfresco. This is great, lets just hope that this will get into 4.2! Thanks Julien for the quick fix!
The fix works around the whole SSL problem, which isn't very satisfactory. The strange thing is that I don't have the problem at all here with the alfresco HTTPS test server.
Cédric: Should I revert this? Also, Stephan had some suggestions for the patch (see http://nabble.documentfoundation.org/Re-Libreoffice-commits-core-git-ucb-source-td4091961.html)
(In reply to comment #19) > Cédric: Should I revert this? > Also, Stephan had some suggestions for the patch (see > http://nabble.documentfoundation.org/Re-Libreoffice-commits-core-git-ucb- > source-td4091961.html) Yes, better revert it than leave and forget it.
Cédric: I abandoned cherry pick for 4.2, but I'll be able to revert the patch on master only tonight after my job hours. Have you succeeded in reproducing the problem with https? (BTW, I saw other related bugs, I'll put them in see also)
(In reply to comment #21) > Cédric: I abandoned cherry pick for 4.2, but I'll be able to revert the > patch on master only tonight after my job hours. Ok thanks. > Have you succeeded in reproducing the problem with https? (BTW, I saw other > related bugs, I'll put them in see also) No I just tried with master RPMs daily build from a few days ago on a brand new opensuse 13.1 virtual machine and it works like a charm. Did someone manage to reproduce it on a linux machine? if yes, any infos on the setup would help.
Julien Nabet committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4bdaa70ffba4c782859bddc5c32d897c84d08b8a Revert "Resolves: fdo#72277 https CMIS Alfresco "The specified device is invalid."" The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Cédric: yes I had reproduced this on pc Debian x86-64 I had found this: SessionFactory::createSession contains the parameter noSslCheck which calls here WSSession::WSSession which calls BaseSession with the same parameter. m_noSSLCheck takes the value of this parameter Then, since noSSLCheck is false, we don't enter the if. 616 if ( m_noSSLCheck ) 617 { 618 #if LIBCURL_VERSION_VALUE >= 0x070801 619 curl_easy_setopt(m_curlHandle, CURLOPT_SSL_VERIFYHOST, 0); 620 #endif 621 #if LIBCURL_VERSION_VALUE >= 0x070402 622 curl_easy_setopt(m_curlHandle, CURLOPT_SSL_VERIFYPEER, 0); 623 #endif 624 } Now taking again a look again, m_noSSLCheck may be assigned by: 1) BaseSession::setNoSSLCertificateCheck 2) 682 if ( !certificates.empty() ) 683 { 684 libcmis::CertValidationHandlerPtr validationHandler = 685 libcmis::SessionFactory::getCertificateValidationHandler( ); 686 bool ignoreCert = validationHandler && validationHandler->validateCertificate( certificates ); 687 if ( ignoreCert ) 688 { 689 m_noSSLCheck = true; I'll try to find some time to take a look more precisely to 2)
Argh! With 4.2 sources updated yesterday (8daeef732b33780c8d91835ff1e61c2eb7cf1472), no problem to open https! (??) I must test again with master sources but I'm waiting the end of building (since git updated to revert the patch) so I should be able to do this only tomorrow now :-(
Ok I reproduce the problem with master sources updated today.
Cédric: Weird thing is no difference between workdir/UnpackedTarball/cmis and for ucb/source/ucp/cmis, only this: diff -r ucb/source/ucp/cmis/ucpcmis1.component /home/julien/compile-libreoffice/libo/ucb/source/ucp/cmis/ucpcmis1.component 10,11c10,11 < <component loader="com.sun.star.loader.SharedLibrary" prefix="ucpcmis1" < xmlns="http://openoffice.org/2010/uno-components"> --- > <component loader="com.sun.star.loader.SharedLibrary" environment="@CPPU_ENV@" > prefix="ucpcmis1" xmlns="http://openoffice.org/2010/uno-components"> (via diff -r) but I don't think it's a problem. Any idea where to dig?
(In reply to comment #27) > Cédric: Weird thing is no difference between workdir/UnpackedTarball/cmis > and for ucb/source/ucp/cmis, only this: > diff -r ucb/source/ucp/cmis/ucpcmis1.component > /home/julien/compile-libreoffice/libo/ucb/source/ucp/cmis/ucpcmis1.component > 10,11c10,11 > < <component loader="com.sun.star.loader.SharedLibrary" prefix="ucpcmis1" > < xmlns="http://openoffice.org/2010/uno-components"> > --- > > <component loader="com.sun.star.loader.SharedLibrary" environment="@CPPU_ENV@" > > prefix="ucpcmis1" xmlns="http://openoffice.org/2010/uno-components"> > > (via diff -r) but I don't think it's a problem. > > Any idea where to dig? The more I think about it, the more it could be some problem with the way internal curl is built.
(In reply to comment #28) > (In reply to comment #27) > > Any idea where to dig? > > The more I think about it, the more it could be some problem with the way > internal curl is built. But should I see than not a connection start with tcpdump? Or did you mean curl break before the connection start and LibreOffice show the error? I can download the file of https://alfresco.intern/alfresco/cmisws/RepositoryService?wsdl with curl, my certificat work fine on the terminal/system.
I tested again with 4.2 and it failed. Following my previous comment, https://bugs.freedesktop.org/show_bug.cgi?id=72277#c25, I don't understand. Anyway, I took a look to git history searching about curl and retrieved this: http://cgit.freedesktop.org/libreoffice/core/log/?qt=grep&q=curl more particularly this (the Curl upgrade): http://cgit.freedesktop.org/libreoffice/core/commit/?id=fa66ae3a739594da13fb78638ef98a2c8cc5ed2e I wonder if it could be related.
Quick info: Version: 4.2.0.3 Build-ID: c63c03decdf780d8fb80823950665b782ec9ecd0 CMIS over https do not work on debian 7.3 (wheezy) amd64.
This issue is effectively blocking all use of CMIS in production environments since https used is in 99% of those cases. Is there any plan on how to solve this issue? Would be very nice if we could find a solution which could be part of the first service pack for 4.2...
Just to give an update, on pc Debian x86-64 with master sources updated 2 days ago + with 4.2 sources updated 1 week ago, I reproduced the same problem. Michael: I noticed this commit http://cgit.freedesktop.org/libreoffice/core/commit/?id=88e65df2e4be47ae3ae1ae1b3a30003f4cfe4b11. I thought you might have an idea about this problem if it's related to Curl (BTW, there's now 7.35 version of Curl)
Is there some change in 4.2.1 RC1?
I finally managed to reproduce the bug here with a build as close as possible to the release or daily builds. The problems comes from the cacert bundle internal curl is using: curl request sends back CURLE_SSL_CACERT_BADFILE. I still don't really know how to fix it, just storing infos here for the record.
Cédric: I noticed this patch http://cgit.freedesktop.org/libreoffice/core/commit/?id=92ca6ef11daa892cffaff136b9a4380665f0ecc2 Could it help to pinpoint the problem? I mean, could the pb be related to nss?
(In reply to comment #36) > Cédric: I noticed this patch > http://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=92ca6ef11daa892cffaff136b9a4380665f0ecc2 > Could it help to pinpoint the problem? I mean, could the pb be related to > nss? Well, that could only make things worse for macos / ios. I'm not sure curl implemented getting cert infos for native macos / ios SSL implementation... but that is another problem.
Same with Version: 4.2.2.1 Will be a create future to use LibreOffice & CMIS for checkout and checkin of documents, but this is only possible with https which still not work :(
> Will be a create future to use LibreOffice & CMIS for checkout and checkin > of documents, but this is only possible with https which still not work :( oh, mean "great feature".
Any progress on this bug, or has it been forgotten?
(In reply to comment #40) > Any progress on this bug, or has it been forgotten? Sadly I didn't manage to find time for LibreOffice hacking recently... Still not forgotten and pretty hard to fix.
Ok! thanks for the update Cedric.
Do not understand where the root cause is, because: * curl work with https * cmislib in a python script work with https * wget work with https * firefox work with https Why LibreOffice do not work with the same cmislib?
(In reply to comment #43) > Do not understand where the root cause is, because: > > * curl work with https > * cmislib in a python script work with https > * wget work with https > * firefox work with https > > Why LibreOffice do not work with the same cmislib? The root cause is the SSL CA bundle used by the libcurl embedded in LibreOffice. We somehow need to find a way to use the ones from the system. And cmislib isn't the same thing than libcmis: one is written in python the other in C++.
(In reply to comment #44) > The root cause is the SSL CA bundle used by the libcurl embedded in > LibreOffice. That mean LibreOffice do not use the CAs from the settings...? > We somehow need to find a way to use the ones from the system. > And cmislib isn't the same thing than libcmis: one is written in python the > other in C++. I wanted to say, the CA in my system is fine and work with all the other os tools.
Created attachment 100462 [details] Certificate Path Certificate path to my firefox profile, which works fine with my CA.
This bug is still in LibreOffice 4.2.5.2 as downloaded from: http://donate.libreoffice.org/home/dl/deb-x86_64/4.2.5/en-GB/LibreOffice_4.2.5_Linux_x86-64_deb.tar.gz Tested on Ubuntu 14.04 LTS (Trusty) http works. https fails with "The specified device is invalid." This doesn't seem to be an SSL issue at all. When I run wireshark and try to connect to the cmisatom URL via https all I see are: 1. LO sends SYN (starts the sequence) 2. server sends SYN,ACK to #1 3. LO sends ACK to #2 4. LO sends Fin,ACK (not in reply to anything). 5. server sends ACK to #4 some wireshark traces have #5 server sending FIN,ACK to #4. (and sometimes I don't get exactly the above, but close enough). The sequence is sometimes repeated (not sure why, maybe I press the reload button twice or maybe it just sends the request twice and fails twice). There is no TCP/IP connection completed, so it certainly doesn't get to the SSL bit at all. If no alfresco 4 server available, test against: https://alfresco.wgtn.cat-it.co.nz/alfresco/cmisws/RepositoryService?wsdl the wireshark trace is pretty much the same.
Cedric Bosdonnat committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=165075e0d705cbd146463c94b027e728db864ab2 fdo#72277: Use NSS CACERT in cmis ucp with internal curl The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Cedric Bosdonnat committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6602f904ac1858ef571eab5b2df733be0461e7e3 fdo#72277: nss-pem fixed windows and macos build errors The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Cedric Bosdonnat committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=85d1bd151cca1572e39019288cb2b7b35fc0bbda fdo#72277: NSS-PEM yet another build fix for MS compiler The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Cedric Bosdonnat committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0058b4370070c96e1edc9dd3c80715187ad30cca fdo#72277: NSS-PEM, use PR_snprintf instead of snprintf The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Cedric Bosdonnat committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a8fd30771a019f727b07adfd82d610028f640f1e fdo#72277: NSS-PEM windows fixes. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
resolved in master
Cedric Bosdonnat committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=89361fa68af9a6854dc3a07711279f27561ea8fb fdo#72277: don't build and use nsspem when building against system curl The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Cedric Bosdonnat committed a patch related to this issue. It has been pushed to "libreoffice-4-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=01f46d8a5d8b60e791205e74ffb86e730499b273&h=libreoffice-4-3 fdo#72277: Use NSS CACERT in cmis ucp with internal curl It will be available in LibreOffice 4.3.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
> fdo#72277: Use NSS CACERT in cmis ucp with internal curl > It will be available in LibreOffice 4.3.1. It doesn't work in my setup. Mount from the same server a WebDAV share on the terminal without a error. New problem or still the same?
Created attachment 105977 [details] Same error with LibreOffice 4.3.1.2
On pc Debian x86-64 with 4.3 sources updated about 2 weeks ago, I could connect to https://cmis.alfresco.com/cmisatom For the test, could you give a try to this one? (perhaps after having renamed your LO directory profile, see https://wiki.documentfoundation.org/UserProfile)
Delete my LibreOffice user profile and test it with https://cmis.alfresco.com/cmisatom same error. Install my own CA system-wide on my debian machine, which work fine except LibreOffice CMIS. root@desktop:/tmp# cat /etc/debian_version 7.6 root@desktop:/tmp# dpkg -l | grep libreoffice ii libreoffice4.3 4.3.1.2-2 amd64 Brand module for LibreOffice 4.3 .1.2 ii libreoffice4.3-base 4.3.1.2-2 amd64 Base brand module for LibreOffice 4.3 .1.2 ii libreoffice4.3-calc 4.3.1.2-2 amd64 Calc brand module for LibreOffice 4.3 .1.2 ii libreoffice4.3-de 4.3.1.2-2 amd64 Brand language module for LibreOffice 4.3 .1.2 ii libreoffice4.3-debian-menus 4.3.1-2 all LibreOffice 4.3 desktop integration ii libreoffice4.3-dict-de 4.3.1.2-2 amd64 De dictionary for LibreOffice 4.3 .1.2 ii libreoffice4.3-dict-en 4.3.1.2-2 amd64 En dictionary for LibreOffice 4.3 .1.2 ii libreoffice4.3-dict-es 4.3.1.2-2 amd64 Es dictionary for LibreOffice 4.3 .1.2 ii libreoffice4.3-dict-fr 4.3.1.2-2 amd64 Fr dictionary for LibreOffice 4.3 .1.2 ii libreoffice4.3-draw 4.3.1.2-2 amd64 Draw brand module for LibreOffice 4.3 .1.2 ii libreoffice4.3-en-us 4.3.1.2-2 amd64 Brand language module for LibreOffice 4.3 .1.2 ii libreoffice4.3-impress 4.3.1.2-2 amd64 Impress brand module for LibreOffice 4.3 .1.2 ii libreoffice4.3-math 4.3.1.2-2 amd64 Math brand module for LibreOffice 4.3 .1.2 ii libreoffice4.3-ure 4.3.1.2-2 amd64 UNO Runtime Environment .1.2 ii libreoffice4.3-writer 4.3.1.2-2 amd64 Writer brand module for LibreOffice 4.3 .1.2 root@desktop:/tmp#
(In reply to comment #59) > Delete my LibreOffice user profile and test it with > https://cmis.alfresco.com/cmisatom > same error. > > Install my own CA system-wide on my debian machine, which work fine except > LibreOffice CMIS. This is pretty weird... it's working fine on windows builds for https://cmis.alfresco.com/cmisatom.
(In reply to comment #60) > This is pretty weird... it's working fine on windows builds for > https://cmis.alfresco.com/cmisatom. Would you say, you can confirm it doesn't work on a Debian or Linux machine?
(In reply to comment #61) > (In reply to comment #60) > > This is pretty weird... it's working fine on windows builds for > > https://cmis.alfresco.com/cmisatom. > > Would you say, you can confirm it doesn't work on a Debian or Linux machine? didn't try on debian yet, but windows build was suffering from the problem originally described by this bug: it coudln't reach the NSS CA-cert database due to missing libnsspem. Do you have a mozilla product installed on your machine? LibreOffice uses the CA certificates from there. In the same way, if you need to add a certificate on your system, for LibreOffice to see it, you'll need to add it to the certificates in your user's mozilla profile. See also the LO options to set a different mozilla profile.
(In reply to comment #62) > didn't try on debian yet, but windows build was suffering from the problem > originally described by this bug: it coudln't reach the NSS CA-cert database > due to missing libnsspem. No such package in debian. > Do you have a mozilla product installed on your machine? LibreOffice uses > the CA certificates from there. In the same way, if you need to add a > certificate on your system, for LibreOffice to see it, you'll need to add it > to the certificates in your user's mozilla profile. See also the LO options > to set a different mozilla profile. Yes, Firefox and LibreOffice settings point to the mozilla profile. The CA and a https connection work fine in Firefox to the *same* server which doesn't work with LibreOffice. :-(
Can somebody confirm this should work in Debian?
Samuel: did you take a look to https://bugs.freedesktop.org/show_bug.cgi?id=72277#c58 ?
@ Julien, (In reply to comment #65) > Samuel: did you take a look to > https://bugs.freedesktop.org/show_bug.cgi?id=72277#c58 ? yes, test both with 4.3.1.2 from libreoffice.org. (In reply to comment #58) > On pc Debian x86-64 with 4.3 sources updated about 2 weeks ago, I could > connect to https://cmis.alfresco.com/cmisatom Is 4.3.1.2 (from libreoffice.org) not ok because you speek from "4.3 sources".
Samuel: ok I'll give a try with Debian (testing) LO package 4.3.1.2.
(In reply to comment #67) > Samuel: ok I'll give a try with Debian (testing) LO package 4.3.1.2. Thank you, this will be great! You can test if you want with version 4.3.2.2 as well, doesn't work for me.
(In reply to comment #68) > (In reply to comment #67) > > Samuel: ok I'll give a try with Debian (testing) LO package 4.3.1.2. > > Thank you, this will be great! > You can test if you want with version 4.3.2.2 as well, doesn't work for me. I made the test with 4.3.1.2, it worked. However, I noticed that the url in your last screenshot is different from what I use. Indeed, I just put this in "binding url": https://cmis.alfresco.com/cmisatom nothing more or different.
(In reply to comment #69) > I made the test with 4.3.1.2, it worked. I give up, my 25 Debian 7/Wheezy desktops not work with cmis and https. Terminal wget work as expected: samuel@desktop:/tmp$ wget --user=admin --ask-password https://cmis.alfresco.com/cmisatom Passwort für Benutzer »»admin««: --2014-09-29 20:56:16-- https://cmis.alfresco.com/cmisatom Auflösen des Hostnamen »cmis.alfresco.com (cmis.alfresco.com)«... 94.236.54.237 Verbindungsaufbau zu cmis.alfresco.com (cmis.alfresco.com)|94.236.54.237|:443... verbunden. HTTP-Anforderung gesendet, warte auf Antwort... 401 Unauthorized Verbindungsaufbau zu cmis.alfresco.com (cmis.alfresco.com)|94.236.54.237|:443... verbunden. HTTP-Anforderung gesendet, warte auf Antwort... 200 OK Länge: nicht spezifiziert [application/atomsvc+xml] In »»cmisatom«« speichern. [ <=> ] 28.569 --.-K/s in 0,08s 2014-09-29 20:56:17 (332 KB/s) - »»cmisatom«« gespeichert [28569] samuel@desktop:/tmp$
Created attachment 107082 [details] CMIS Error 4.3.2.2
Is it normal "Server type" is empty instead of containing "Alfresco"?
(In reply to comment #72) > Is it normal "Server type" is empty instead of containing "Alfresco"? More precisely "Alfresco 4"
(In reply to comment #73) > (In reply to comment #72) > > Is it normal "Server type" is empty instead of containing "Alfresco"? > > More precisely "Alfresco 4" Makes no difference, doesn't work with or without "Alfresco 4". I guess this only preset the url?
(In reply to comment #69) > I made the test with 4.3.1.2, it worked. @ Julien, did you tested with LibreOffice .deb from libreoffice.org or the Debian LibreOffice Package? I can confirm it work on Debian 8/Testing with the Debian LibreOffice packages. ii libreoffice-base 1:4.3.1-2 amd64 office productivity suite -- database ii libreoffice-base-core 1:4.3.1-2 amd64 office productivity suite -- shared library ii libreoffice-base-drivers 1:4.3.1-2 amd64 Database connectivity drivers for LibreOffice ii libreoffice-calc 1:4.3.1-2 amd64 office productivity suite -- spreadsheet ii libreoffice-common 1:4.3.1-2 all office productivity suite -- arch-independent files ii libreoffice-core 1:4.3.1-2 amd64 office productivity suite -- arch-dependent files samuel@notebook:~$ cat /etc/debian_version jessie/sid Next step is install the original LibreOffice package from libreoffice.org and test again.
Samuel: I tested from Debian package not from .deb provided by official website. However, perhaps I'm wrong but I think .deb is for distrib packagers. Rene: I thought you might be interested in this tracker since you seem to add some "magic" to official .deb so Debian LO package works with https cmis whereas official .deb doesn't work
(In reply to comment #76) > Samuel: I tested from Debian package not from .deb provided by official > website. > However, perhaps I'm wrong but I think .deb is for distrib packagers. > > Rene: I thought you might be interested in this tracker since you seem to > add some "magic" to official .deb so Debian LO package works with https cmis > whereas official .deb doesn't work That's just "magic", it's just using the system curl that is built with openSSL support and get access to openssl system CA database. Normally the official TDF deb packages are built with internal curl, handling SSL with NSS. Thus it needs libnsspem to be able to read the certs from mozilla profile... which is now working with the .rpm and windows builds.
(In reply to comment #77) > That's just "magic", it's just using the system curl that is built with > openSSL support and get access to openssl system CA database. Oh! That's the root cause I search so long. > > Normally the official TDF deb packages are built with internal curl, > handling SSL with NSS. Thus it needs libnsspem to be able to read the certs > from mozilla profile... which is now working with the .rpm and windows > builds. I don't find a Debian package with libnsspem in Debian 7. Is there a plan to add this feature to TDF .deb?
(In reply to comment #78) > I don't find a Debian package with libnsspem in Debian 7. > Is there a plan to add this feature to TDF .deb? There is no need for such a package: ther should already be a libnsspem.so file in the TDF debs
(In reply to comment #79) > There is no need for such a package: ther should already be a libnsspem.so > file in the TDF debs You are right: root@desktop:~# locate libnsspem.so /opt/libreoffice4.3/program/libnsspem.so But it doesn't work in the moment as you write in commet 77: "[...] which is now working with the .rpm and windows builds."
(In reply to comment #79) > There is no need for such a package: ther should already be a libnsspem.so > file in the TDF debs I start the TDF Libreoffice with strace and test the connection to CMIS https: strace libreoffice4.3 &> debug_lo.txt Close LibreOffice and grep for "libnsspem.so" which result in no match. cat debug_lo.txt | grep libnsspem.so LibreOffice *never* load "libnsspem.so".
(In reply to Samuel Wolf from comment #81) > strace libreoffice4.3 &> debug_lo.txt strace -f libreoffice4.3 &> debug_lo.txt is better :) [pid 5881] open("/opt/libreoffice4.3/program/libnsspem.so", O_RDONLY|O_CLOEXEC) = 35 LibreOffice load the CA databases of my firefox profile: [pid 5881] lstat("/home/samuel/.mozilla", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 [pid 5881] access("/home/samuel/.mozilla", W_OK) = 0 [pid 5881] access("/home/samuel/.mozilla", X_OK) = 0 [pid 5881] stat("/home/samuel/.mozilla/firefox/uo77e06z.default/secmod.db", {st_mode=S_IFREG|0600, st_size=16384, ...}) = 0 [pid 5881] open("/home/samuel/.mozilla/firefox/uo77e06z.default/secmod.db", O_RDONLY) = 32 [pid 5881] stat("/home/samuel/.mozilla/firefox/uo77e06z.default/cert8.db", {st_mode=S_IFREG|0600, st_size=393216, ...}) = 0 [pid 5881] open("/home/samuel/.mozilla/firefox/uo77e06z.default/cert8.db", O_RDWR) = 32 [pid 5881] stat("/home/samuel/.mozilla/firefox/uo77e06z.default/key3.db", {st_mode=S_IFREG|0600, st_size=16384, ...}) = 0 [pid 5881] open("/home/samuel/.mozilla/firefox/uo77e06z.default/key3.db", O_RDWR) = 33 LibreOffice looking for "libnssckbi.so" which not exist: [pid 5881] open("/home/samuel/.mozilla/firefox/uo77e06z.default/libnssckbi.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) Is this the problem?
I switch to the original Debian LibreOffice packages which works for me as expected. In my eyes this bug is not solved with the original TDF debs.
Bjoern/Michael/Rene: is it a dependency problem in the TDF deb package (so could be build part) or is it something else (packaging part)?
(In reply to Cédric Bosdonnat from comment #77) > Normally the official TDF deb packages are built with internal curl, > handling SSL with NSS. Thus it needs libnsspem to be able to read the certs > from mozilla profile... which is now working with the .rpm and windows > builds. I can confirm this work with TDF rpm in CentOS as expected.
I highly recommend closing this bug as FIXED and creating a new bug with a clear description that it's only affecting certain setups now. Multiple people are saying that the bug is now fixed - with 85+ comments it's really hard to get to the bottom and see that it's still affecting a single user. Actually I'm going to go ahead and close as FIXED. Please open a new bug report if you're still seeing this problem. This bug is just a mess with over 80 comments.
(In reply to Joel Madero from comment #86) > Actually I'm going to go ahead and close as FIXED. Please open a new bug > report if you're still seeing this problem. This bug is just a mess with > over 80 comments. https://bugs.documentfoundation.org/show_bug.cgi?id=90038#c8