it fails to build without WINBUILD_ACKNOWLEDGE_DEPRECATED with
WARNING:
The winbuild build system is deprecated and will be removed in
September 2025 in favor of the CMake build system.
curl dropped winbuild support in 8.17.
See https://curl.se/ch/8.17.0.html
Change-Id: I236414c670d1d62d82c5a430e2abdbf71a50a2ff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201470
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
Downloaded from https://curl.se/download/curl-8.12.0.tar.xz
Windows build fails now with
WARNING:
The winbuild build system is deprecated and will be removed in
September 2025 in favor of the CMake build system.
Please see docs/INSTALL-CMAKE.md : "Migrating from winbuild builds"
To use the winbuild build system you must acknowledge this warning by
setting command line option WINBUILD_ACKNOWLEDGE_DEPRECATED=yes
Makefile.vc(37) : fatal error U1050: The user must acknowledge the deprecation warning to continue.
Stop.
so building with WINBUILD_ACKNOWLEDGE_DEPRECATED=yes for now until
the migration from winbuild is done
Change-Id: I5d357b20a93863c81f7637f43abbf7d3167f6dd2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/181173
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
* Which also requires external/curl. But implicitly use --without-gssapi,
checking for it in configure.ac would fail with
> configure: error: could not find function 'gss_init_sec_context' required for GSSAPI
And building ExternalProject_curl needs to see the -pthread from
gb_EMSCRIPTEN_CPPFLAGS, otherwise linking Executable_soffice_bin would fail with
> wasm-ld: error: --shared-memory is disallowed by libcurl_la-easy.o because it was not compiled with 'atomics' or 'bulk-memory' features.
* By default, GetCABundleFile in include/systools/opensslinit.hxx will fail
now. (But to make https work, applications could bring along their own such
file in the Emscripten FS, in one of the places where GetCABundleFile checks for
it.) So, for Emscripten only, make failure of GetCABundleFile non-fatal in
InitCurl_easy.
* Some code in sw was erroneously hidden behind !ENABLE_WASM_STRIP_EXTRA (off
by default for Emscripten), but is needed with HAVE_FEATURE_CURL.
* See <https://emscripten.org/docs/porting/networking.html> for how to actually
use networking in an Emscripten application.
Change-Id: I2bbe9f3fd0e20143e18eb1e8104568b1c7a304de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/172167
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
FTP support has been deprecated since LO 7.4.
The UCP currently doesn't even support TLS connections.
Also disable FTP protocol in libcurl.
Also remove JunitTest_ucb_complex: turns out the only test in it,
checkWrongFtpConnection, fails on Linux because now GIO UCP handles
ftp:// URLs and it throws InteractiveAugmentedIOException instead of
expected ones, and on other platforms it would fail differently because
there is no GIO.
Change-Id: I4631d124371fef390f105fb16bf09aaa59e739e7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159065
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Fixes CVE-2023-38039
* NSS support was removed in this release, so NSS related patches are not necessary now.
* add configure options for curl.
Change-Id: I71e09bac3c69ce4b13deee770a32225f39f79c46
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156917
Tested-by: Jenkins
Reviewed-by: Taichi Haradaguchi <20001722@ymail.ne.jp>
As discussed in the mailing list thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2023-January/089808.html>
"Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*)",
the bridge implementation at bridges/source/cpp_uno/gcc3_aix_powerpc is
apparently dead and should thus be removed. However, that was the only bridge
implementation for AIX, which implies that support for the AIX platform as a
whole is dead and should thus be removed.
Change-Id: I96de3f7f97d4fd770ff78256f0ea435383688be9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146057
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
otherwise with (default due to --disable-dynamic-loading) --disable-nss
we get:
configure: error: select TLS backend(s) or disable TLS with --without-ssl.
Select from these:
--with-amissl
--with-bearssl
--with-gnutls
--with-mbedtls
--with-nss
--with-openssl (also works for BoringSSL and libressl)
--with-rustls
--with-schannel
--with-secure-transport
--with-wolfssl
alternative we could --without-ssl entirely without nss
Change-Id: Iea25b918c135664dffacfb74089d7c7c0818695e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141956
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Fixes CVE-2022-32221 which could affect libcmis, CVE-2022-42915,
and 2 more CVEs that probably don't affect LO.
* remove --without-ssl:
On the one hand, on GNU/Linux this now results in:
configure: error: --without-ssl has been set together with an explicit option to use an ssl library
On the other hand, using the more obvious --without-openssl yields a link
failure on Android on the nss check in configure:
configure:28220: checking for SSL_VersionRangeSet in -lnss
/home/cl/Android/Sdk/ndk/20.1.5948944/toolchains/llvm/prebuilt/linux-x86_64/bin/../lib/gcc/aarch64-linux-android/4.9.x/../../../../aarch64-linux-android/bin/ld: warning: liblog.so, needed by /home/cl/rpmbuild/BUILD/lo-android2/workdir/UnpackedTarball/nss/dist/out/lib/libnss3.so, not found (try using -rpath or -rpath-link)
/home/cl/rpmbuild/BUILD/lo-android2/workdir/UnpackedTarball/nss/dist/out/lib/libnspr4.so: undefined reference to `__android_log_write'
/home/cl/rpmbuild/BUILD/lo-android2/workdir/UnpackedTarball/nss/dist/out/lib/libnspr4.so: undefined reference to `__android_log_assert'
... so add the -llog for android in curl-nss.patch.1
Change-Id: I3931a1eec2d681c2ce0e5695039492772e9fcc81
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141866
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
There is no justification why this patch was added, upstream doesn't
want to add such a feature[1], and maintaining feature patches in LO
for bundled externals doesn't make sense.
Also, this doesn't respect the Inet::Settings::ooInetHTTPProxy*
settings from the configuration.
Let's remove it and hope nobody complains.
[1] https://curl.se/mail/lib-2022-05/0083.html
Change-Id: I1ccdefb76f69e6795a28d4d25bf443555c16ab0b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135182
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
This is basically ea68de2968 but
for LDFLAGS. A number of external libs cannot use this because
their libtool mishandles -fuse-ld.
Change-Id: Idee379eb0a3afb475b536519ee3de064b4e218f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133639
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
No idea why we just provided the platform flags when cross-
compiling. In the curious case, where the host platform is
detected as x86_64-pc-mingw32 per default and we actually
want to override it with x86_64-pc-cygwin, we don't do a
cross compile, but must override the host platform.
But there is additional special handling needed for the omitted
cross-platform build in the special case of --host=i686-pc-cygwin
and --build=x86_64-pc-cygwin, where we deliberatly ignore cross
building; Windows is already a slow build, so try to keep this
optimization (AMD64 can execute x86 binaries).
There is the theoretical case, where the externals config.guess
would have detected something else and that "magically" even
worked, while the LO detected triplet would fail, but this
should be fixed in the external in any way.
Change-Id: Ib7a9719e0e406fe90334b7611dc3f01b51692bfa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129153
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
This fixes the same issue as
<https://github.com/curl/curl/commit/e39421cef31f13a19b6bef5c644978e0c54e4e16>
"curl-functions.m4: fix LIBRARY_PATH adjustment to avoid eval", just in a less
intrusive way so that we can get away with just fixing the resulting configure
rather than having to run any Autotools reconfiguration commands.
40a84af1bd "upgrade to curl-7.81.0" caused
<https://ci.libreoffice.org/job/lo_ubsan/2272/> to fail with the cryptic
[...]
> checking for gethostbyname in -lnetwork... no
> checking for gethostbyname in -lnet... no
> configure: error: couldn't find libraries for gethostbyname()
> /home/tdf/lode/jenkins/workspace/lo_ubsan/external/curl/ExternalProject_curl.mk:41: recipe for target '/home/tdf/lode/jenkins/workspace/lo_ubsan/workdir/ExternalProject/curl/build' failed
> make[1]: *** [/home/tdf/lode/jenkins/workspace/lo_ubsan/workdir/ExternalProject/curl/build] Error 1
because somewhere in the middle of curl's configure LD_LIBRARY_PATH got garbled
because of this issue, so that invoking
/home/tdf/lode/opt_private/clang-llvmorg-9.0.1/bin/clang started to fail with
> /home/tdf/lode/opt_private/clang-llvmorg-9.0.1/bin/clang: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.22' not found (required by /home/tdf/lode/opt_private/clang-llvmorg-9.0.1/bin/clang)
> /home/tdf/lode/opt_private/clang-llvmorg-9.0.1/bin/clang: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /home/tdf/lode/opt_private/clang-llvmorg-9.0.1/bin/clang)
> /home/tdf/lode/opt_private/clang-llvmorg-9.0.1/bin/clang: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /home/tdf/lode/opt_private/clang-llvmorg-9.0.1/bin/clang)
(because that clang is built against a local GCC and libstdc++, so needs
LD_LIBRARY_PATH to be set up properly to find the latter), which caused the
gethostbyname check to fail (as seen when looking into that build's
workdir/UnpackedTarball/curl/config.log).
Change-Id: I3d45018cdfdb22b98c0dec0757e754a172a811de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128850
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...than ae36ee4f3a "Work around use-after-poison"
for
> ==1922539==ERROR: AddressSanitizer: use-after-poison on address
> 0x61d00190fab0 at pc 0x00000026aaa9 bp 0x7f422ee84b80 sp
> 0x7f422ee84348 WRITE of size 192 at 0x61d00190fab0 thread T44 #0 in
> memset at
> ~/github.com/llvm/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:800:3
> (instdir/program/soffice.bin +0x26aaa8) #1 at <null>
> (/lib64/libnsspem.so +0x15f3d) #2 at <null> (/lib64/libnsspem.so
> +0x16185) #3 at <null> (/lib64/libnsspem.so +0x8a9b) #4 at <null>
> (/lib64/libnsspem.so +0xe13b) #5 in secmod_ModuleInit at
> workdir/UnpackedTarball/nss/nss/lib/pk11wrap/pk11load.c:244:11
> (instdir/program/libnss3.so +0x4ad372) #6 in secmod_LoadPKCS11Module
> at workdir/UnpackedTarball/nss/nss/lib/pk11wrap/pk11load.c:544:10
> (instdir/program/libnss3.so +0x4b1fca) #7 in SECMOD_LoadModule at
> workdir/UnpackedTarball/nss/nss/lib/pk11wrap/pk11pars.c:1946:10
> (instdir/program/libnss3.so +0x50de92) #8 in SECMOD_LoadUserModule
> at workdir/UnpackedTarball/nss/nss/lib/pk11wrap/pk11pars.c:2042:28
> (instdir/program/libnss3.so +0x50e9a9) #9 in nss_load_module at
> workdir/UnpackedTarball/curl/lib/vtls/nss.c:1310:12
> (instdir/program/libcurl.so.4 +0x4fdd25) #10 in nss_setup_connect at
> workdir/UnpackedTarball/curl/lib/vtls/nss.c:1894:12
> (instdir/program/libcurl.so.4 +0x4eeffb) #11 in nss_connect_common
> at workdir/UnpackedTarball/curl/lib/vtls/nss.c:2235:14
> (instdir/program/libcurl.so.4 +0x4ee237) #12 in
> nss_connect_nonblocking at
> workdir/UnpackedTarball/curl/lib/vtls/nss.c:2291:10
> (instdir/program/libcurl.so.4 +0x4ebe4a) #13 in
> Curl_ssl_connect_nonblocking at
> workdir/UnpackedTarball/curl/lib/vtls/vtls.c:361:12
> (instdir/program/libcurl.so.4 +0x514039) #14 in https_connecting at
> workdir/UnpackedTarball/curl/lib/http.c:1591:12
> (instdir/program/libcurl.so.4 +0x2f29ce) #15 in Curl_http_connect at
> workdir/UnpackedTarball/curl/lib/http.c:1517:14
> (instdir/program/libcurl.so.4 +0x2f23d5) #16 in protocol_connect at
> workdir/UnpackedTarball/curl/lib/multi.c:1696:16
> (instdir/program/libcurl.so.4 +0x3b8620) #17 in multi_runsingle at
> workdir/UnpackedTarball/curl/lib/multi.c:1997:16
> (instdir/program/libcurl.so.4 +0x3a2232) #18 in curl_multi_perform
> at workdir/UnpackedTarball/curl/lib/multi.c:2568:14
> (instdir/program/libcurl.so.4 +0x39dc5c) #19 in
> http_dav_ucp::CurlProcessor::ProcessRequestImpl(http_dav_ucp::CurlSession&,
> http_dav_ucp::CurlUri const&, curl_slist*,
> com::sun::star::uno::Reference<com::sun::star::io::XOutputStream>
> const*, com::sun::star::uno::Sequence<signed char> const*,
> std::pair<std::__debug::vector<rtl::OUString,
> std::allocator<rtl::OUString> > const&, http_dav_ucp::DAVResource&>
> const*, (anonymous namespace)::ResponseHeaders&) at
> ucb/source/ucp/webdav-curl/CurlSession.cxx:880:14
> (instdir/program/../program/libucpdav1.so +0x5aad30) 0x61d00190fab0
> is located 48 bytes inside of 2048-byte region
> [0x61d00190fa80,0x61d001910280) allocated by thread T44 here: #0 in
> malloc at
> ~/github.com/llvm/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:69:3
> (instdir/program/soffice.bin +0x2d3c7e) #1 in PR_Malloc at
> workdir/UnpackedTarball/nss/nspr/out/pr/src/malloc/../../../../pr/src/malloc/prmem.c:448:55
> (instdir/program/libnspr4.so +0x123629) #2 in PL_ArenaAllocate at
> workdir/UnpackedTarball/nss/nspr/out/lib/ds/../../../lib/ds/plarena.c:134:27
> (instdir/program/libplds4.so +0x9a32) #3 at <null>
> (/lib64/libnsspem.so +0x15f77)
during UITest_sw_options:
That --with-system-nss workaround for <https://ci.libreoffice.org/job/lo_ubsan/>
had caused CppunitTest_desktop_lib to start to fail there, presumably "caused by
--with-system-nss on the CentOS7 baseline", see the mail thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2021-December/088136.html>
"Re: [global-libreoffice-ci] UBSAN Linux Build - Build # 2217 - Still Failing!"
And while I had initially not been able to reproduce the use-after-poison during
UITest_sw_options with my local ASan+UBSan build (on Fedora 35), I now found out
that that was just because my machine happened to not have an nsspem library
installed in the system (the nss-pem RPM on Fedora). With that system library
installed, my local build failed UITest_sw_options in the same way as the
Jenkins tinderbox.
Which lead me to the idea of avoiding the whole mess by avoiding that CUrl loads
the (apparently optional) nsspem library in ASan builds altogether. (Another
approach might have been to disable the __asan_poison_memory_region
functionality in workdir/UnpackedTarball/nss/nspr/lib/ds/plarena.h, but the
chosen approach nicely makes us less dependent on accidental differences in
build-time execution environments, at least for ASan builds.)
Change-Id: I8fd2ff255771622f26ad666ca78a6d9ded0af2d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126451
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
There's no official MSVC support in ccache yet, but there are patches
in progress of getting upstreamed. So right now it's necessary
to get a patched ccache.
Ccache cannot work with -Zi option, since sharing debuginfo in a .PDB
cannot be cached. Added --enable-z7-symbols that gets enabled
by default if ccache is detected.
It works even with PCHs enabled, and externals seem to work too.
I get almost 100% hit rate on a rebuild, although such a rebuild
is slower than on Linux.
Change-Id: I1d230ee1fccc441b9d9bec794cc2e1ec13161999
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125179
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
* Fixes CVE-2020-8284 CVE-2021-22924
* Also fixes these which don't look relevant to LO:
CVE-2020-8231
CVE-2020-8285 CVE-2020-8286
CVE-2021-22876 CVE-2021-22890
CVE-2021-22897 CVE-2021-22898 CVE-2021-22901
CVE-2021-22922 CVE-2021-22923 CVE-2021-22925 CVE-2021-22926
* disable some new protocols and dependencies
* remove curl-ios.patch.1 as the code no longer exists upstream
Change-Id: I12d5f87f4d503a5f9859226a05cfe2a07e46d993
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119313
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
We must link nss statically, including the three dylibs that normally
are loaded at run-time, because including bare dylibs in an iOS appp
on the App Store is not OK. See
https://developer.apple.com/forums/thread/125796 .
For linking the softokn3 library statically, NSS already had code,
behind NSS_STATIC_SOFTOKEN ifdefs. Introduce two more macros:
NSS_STATIC_FREEBL for the freebl library and NSS_STATIC_PKCS11 for the
nssckbi library.
Turn off parallelism for the sub-make building nss. There seems to be
race conditions or something when running simultaneous instances of
the nsinstall.py script or the nsinstall program in nss (used when
building nss for the build platform).
When cross-compiling from macOS, use python3 to run the nsinstall.py
script, as it is Python 3.
Change-Id: Idd427b5ebf21f802b3feb0d5a3d259317ba8fc67
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103106
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103218
Tested-by: Jenkins
Xisco Fauli