On Tue, Apr 9, 2024 at 10:14 PM Arrigo Marchiori <ard...@apache.org> wrote:
> Hello Damjan, All,
>
> replying to this other message.
>
> On Mon, Apr 08, 2024 at 02:42:01PM +0000, Damjan Jovanovic wrote:
>
> [...]
> > Here's how you set RPATH in Curl:
> >
> > ---snip---
> > diff --git a/main/curl/makefile.mk b/main/curl/makefile.mk
> > index 044bf4d8c9..ecef11820a 100644
> > --- a/main/curl/makefile.mk
> > +++ b/main/curl/makefile.mk
> > @@ -59,6 +59,7 @@ curl_LDFLAGS+:=$(ARCH_FLAGS)
> > ssl_param=--with-ssl
> > .ELSE
> > ssl_param=--with-ssl=$(OUTDIR)
> > +curl_LDFLAGS+=-Wl,-z,origin -Wl,-rpath,\\\$$\$$ORIGIN
> > PATCH_FILES+= curl-bundled_openssl.patch
> > .ENDIF
> >
> > ---snip---
> >
> > which gets libcurl.so to search for the OpenSSL dynamic libraries in its
> > own directory before the system directories:
> >
> > $ ldd solver/450/unxfbsdx.pro/lib/libcurl.so
> > ...
> > libssl.so.3 => /path/to/openoffice-git/main/solver/450/
> > unxfbsdx.pro/lib/libssl.so.3 (0x299f766bc000)
> > libcrypto.so.3 => /path/to/openoffice/openoffice-git/main/solver/450/
> > unxfbsdx.pro/lib/libcrypto.so.3 (0x299f77747000)
>
> It works under Linux too!
>
Great, thank you for testing.
> If we want to use the dynamically linked OpenSSL, then, we have to
> amend 0ca5b4b7b8e66fbc937f89173ce45fcc179e72b3 and have
> main/scp2/source/ooo/file_library_ooo.scp include "libssl.so.3" and
> "libcrypto.so.3" instead of "libssl.so" and "libcrypto.so".
>
> I think the same should happen under FreeBSD, so you may want to
> commit all these edits together after testing them?
>
Here is my change:
commit 8eb9a7e66a3128669216ddb884f844d50ac59fb9 (HEAD -> trunk,
origin/trunk, origin/HEAD)
Author: Damjan Jovanovic <dam...@apache.org>
Date: Sun Apr 7 10:41:42 2024 +0200
Build OpenSSL as a dynamic link library, instead of a static library.
Patch its users to use an RPATH of $ORIGIN, so they use the correct
copy.
This reduces the size of the build by about 4615 KiB, or 3.78%.
>
> Next step will be asking p11-kit for the CA certificates, as you
> proposed here:
> https://lists.apache.org/thread/3rb1t9jf5fnp4nfxr2z9dxmzt9l61tjq
> otherwise Linux builds may be unable to validate certificate chains,
> unfortunately.
>
No, that was a separate issue. I wanted to make a new xmlsecurity provider
that could be used on Linux instead of Mozilla (which requires category B
nss) and mscrypto for Windows. As currently, --disable-category-b badly
breaks AOO: the macro security dialog won't open, the document signatures
dialog won't open, and a few other features probably break.
We'd need to provide at least the following:
- Cryptographic functions. We could do that with OpenSSL.
- The read-only trusted system certificate store. We could do that with
p11-kit's trust policy module.
- The writable user certificate store, with client certificates. There is
currently no way to do that on the Linux desktop. See my detailed
investigation on https://gitlab.gnome.org/GNOME/seahorse/-/issues/205 for
details, which found several bugs and even design defects that stop it from
working.
However what I am now thinking, is that we could make a partially working
provider, with just the cryptographic functions and system certificate
store, and add the user certificates later. It should only break document
signatures, rather than the macro dialog.
As for Linux validating certificate chains, I'll cover that in another
email.
>
> Best regards,
> --
> Arrigo
>
>
Regards
Damjan
