Hi Damjan, Am 27.04.22 um 19:11 schrieb Damjan Jovanovic: > Thank you Matthias. > > Not too happy to use Github, but here is the pull request: > https://github.com/apache/openoffice/pull/146
Thanks, Git makes it a lot easier for me to build... BTW: Is it OK when I cherry-pick your other two commits to AOO42X? Regards, Matthias > > > > On Wed, Apr 27, 2022 at 5:44 PM Matthias Seidel <matthias.sei...@hamburg.de> > wrote: > >> Hi Damjan, >> >> Sounds great! >> >> Can we have that as a Pull Request? >> >> Regards, >> >> Matthias >> Am 26.04.22 um 19:56 schrieb Damjan Jovanovic: >> >> On Mon, Nov 15, 2021 at 9:57 PM Jim Jagielski <j...@jagunet.com> wrote: >> >>> I'm gonna look into the serf->(lib)curl option... Since we don't use any >>> of the fancy features of serf, I'm thinking that the easy option might be >>> best >> >> >> Hi >> >> I've ported our WebDAV content provider module from Serf to Curl. >> >> While it ended well, and several other bugs were found and fixed, it >> definitely wasn't the "easy option" Jim ;). Starting with conservative >> changes, it ended up needing total restructuring, and became more of a >> rewrite. The crashes were frequent and hung connections many, and I had to >> read up on the HTTP protocol, and read Curl and Serf's source code, but >> eventually I prevailed, and a clean elegant stable Curl WebDAV module >> emerged. >> >> The huge patch is attached for anyone wishing to review and test. Unless >> there are major objections, I'll push it in a couple of days. >> >> STATUS >> >> It builds and works well on FreeBSD and Windows. >> >> Most of the code was reused, and all the operations and semantics >> previously present with Serf, should have been preserved. >> >> Browsing WebDAV files and directories, loading files, overwriting them >> ("Save"), creating them ("Save As"), renaming and deleting them, all works. >> >> HTTP and HTTPS proxies work. Unlike Serf, Curl could also support SOCKS >> proxies (with minimal further changes), but AOO lacks that setting in the >> proxy UI and configuration. >> >> Authentication works, both to the destination server and to the proxy >> server. I've successfully tested Basic and Digest authentication. Curl >> supports every authentication method Serf does and more. >> >> HTTPS works, with a custom certificate verification function, using our >> own certificate store from NSS and its API (like the Serf code used). A bug >> was discovered (which is in the Serf implementation too) where self-signed >> certificates were being unconditionally rejected; apparently NSS wants to >> see that a copy of that certificate in its certificate chain parameter >> too. Now they work, and the user gets prompted to allow access. >> >> HTTPS and authentication can be used together on the same connection and >> work well, both bringing up their UI dialogs as needed. >> >> A bug was fixed where when username and password were both present in the >> URL (dav://user:pass@host/path), the code was trying to split them at the >> "@" instead of ":". >> >> Unnecessary base64 encoding and decoding was removed, when importing the >> TLS connection's certificates into our XSecurityEnvironment. They now come >> in directly as ASN.1 DER, and still work. >> >> The code was greatly restructured and cleaned up, as Curl's API is >> synchronous and blocking, with parameters set in advance instead of through >> many callbacks, which has allowed using short clear methods, and clean >> separation between the session and request classes. The WebDAV content >> provider has shrunk from 35 to 21 C++ files, 43 to 29 header files, and >> 19129 to 15991 lines of code. With WebDAV methods centralized and >> refactored into only 10-20 lines of code each, instead of scattered across >> 4 files, it is much more understandable and maintainable now. >> >> Curl is vastly more portable than Serf. We should build easily now even on >> OS/2. We can remain with existing build tools instead of needing scons or >> cmake just to build Serf. >> >> 3 now unused dependencies were removed: apr, apr-util, and serf. Serf >> isn't so bad. APR's pool idea is an ingenious way of doing resource >> management in C. However Curl has excellent documentation, guides, >> examples, and detailed explanations and even example code for each setting, >> while Serf has no documentation. Serf might be worth it in a project that >> already uses APR a lot, but we don't. >> >> Instead of the historical, crippled forms of logging like OSL_TRACE(), >> which don't appear in release builds, I've made it use the newer >> com.sun.star.logging UNO component (wrapped in comphelper::EventLogger), >> which was inspired by java.util.logging, with configurable verbosity >> levels, handlers (file and console) and output formats (plain, csv), and >> importantly, which produces output in release builds too. I've also made it >> so that on LogLevel::FINEST, Curl's verbose mode is enabled and Curl's >> debug output is also logged through us, with descriptions of what Curl is >> doing, and logs of all HTTP traffic including headers and bodies, before >> encryption and after decryption in the case of HTTPS, giving us tremendous >> detail that can be used for troubleshooting problems. >> >> CURL CHANGED TO USE OPENSSL AND ZLIB >> >> Curl only supports the custom TLS certificate verification function we use >> (the CURLOPT_SSL_CTX_FUNCTION option) when built with OpenSSL, wolfSSL or >> mbedTLS providers. We currently use schannel on Windows instead, which had >> to be changed. I also made it use zlib, which generally helps, and WebDAV >> uses XML which is very verbose and benefits from compression. On other OSes >> with system curl, it is now checked for its SSL provider, and configure >> fails if it isn't OpenSSL. >> >> The new WebDAV module successfully builds and runs with both OpenSSL 1.0.2 >> or 1.1.1. However 1 function was renamed between those versions, so the >> OpenSSL version at runtime probably has to match the one used at compile >> time (although building with 1.0.2 headers might allow running with 1.1.1 - >> not tested). >> >> (After completing development and testing, it dawned on me there is a >> completely different way to do the certification verification, which should >> allow other SSL providers to be used and might be better in various ways. >> See later.) >> >> We currently build zlib as a static library only, and on Windows its C >> runtime library is linked statically (_MT), which can't be mixed with >> curl's dynamic linking of the runtime library (_MD). Thus curl was made to >> link it statically too. Most if not all of our modules link the runtime >> library statically too (which begs the question, why do we ship the msvcr* >> redistributables to users at all then?). >> >> ISSUES >> >> The file open dialog (Ctrl+O) can hang for several minutes when first >> connecting to a server. This is not new - it happens with Serf as well. >> This appears to be caused by autocompletion in the file dialog. When typing >> in a URL like "davs://127.0.0.1", the WebDAV content provider is first >> called with a partial "https://1", before the rest of the URL is entered. >> That "1" is (somehow) treated as IP address "0.0.0.1", and a TCP connection >> to 0.0.0.1 is started. Only after several minutes, when that connection >> times out and fails, does the content provider get another request with the >> complete URL, which succeeds. The distinctly unpleasant wait, is luckily >> only present that the first time that server is used, as caching remembers >> the URL even across AOO restarts, so the "1" is automatically expanded to >> the full URL and the content provider never sees "https://1" again. >> >> You can only enter credentials for the HTTP(S) proxy or the destination, >> never both, as the credential manager caches credentials per URL, not per >> host/realm, so while you are prompted for credentials for both, and Curl is >> told about both, the destination credentials overwrite the proxy >> credentials in the cache, so one Curl request works but future Curl >> requests use the wrong credentials to the proxy. This doesn't matter, as >> AOO doesn't support passwords for proxy servers anyway, and Serf has the >> same issue. >> >> Damjan >> >> -- >> >> P.S. APACHE 2.4 SETUP FOR TESTING >> >> Put some files in /var/tmp/dav/files, then configure Apache HTTPD's >> httpd.conf with something along these lines: >> >> Listen 127.0.0.1:8080 >> LoadModule dav_module libexec/apache24/mod_dav.so >> LoadModule dav_fs_module libexec/apache24/mod_dav_fs.so >> >> <VirtualHost 127.0.0.1:8080> >> DocumentRoot "/var/tmp/dav" >> ErrorLog "/var/tmp/dav/errors.txt" >> TransferLog "/var/tmp/dav/access.txt" >> DavLockDB "/var/tmp/dav/DavLock" >> >> # If using TLS, generate these self-signed certificates too: >> # SSLEngine on >> # SSLCertificateFile "/var/tmp/dav/cert.pem" >> # SSLCertificateKeyFile "/var/tmp/dav/key.pem" >> >> <Directory "/var/tmp/dav/files"> >> AllowOverride none >> Require valid-user >> # Require all granted >> >> AuthType Basic >> AuthName "WebDAV" >> AuthBasicProvider file >> AuthUserFile "/var/tmp/dav/passwords" >> >> Dav on >> </Directory> >> </VirtualHost> >> >> Enter your username and password with: >> htpasswd -c /var/tmp/dav/passwords username >> >> Then in the file open dialog, enter "dav://127.0.0.1:8080/files/" (or use >> scheme davs:// instead, if using HTTPS). >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> >>
smime.p7s
Description: S/MIME Cryptographic Signature