p11-kit: Set proper proxy_module variable for pkg-config #22595
Conversation
| p11_module_path=@p11_module_path@ | ||
| p11_trust_paths=@with_trust_paths@ | ||
| -proxy_module=@libdir@/p11-kit-proxy@p11_shlext@ | ||
| +proxy_module=libp11-kit-0.dll |
There was a problem hiding this comment.
| +proxy_module=libp11-kit-0.dll | |
| +proxy_module=@exec_prefix@/bin/libp11-kit-0.dll |
Wouldn't this be more correct?
There was a problem hiding this comment.
I was pondering about this. It does look good but I think it is impractical. If let be, applications that depend on it will likely compile the path in (C:/msys64/ucrt64/bin/libp11-kit-0.dll) thus making msys2 installation not so portable. Of course, one may patch up the application, but what is the point of having pkg-config then?
Here is somewhat related (portability) issue #22187 . It looks like MSYS2 build farm uses D:/a/MSYS64 prefix. However, for end user MSYS2 typically installs into C:/MSYS64. That implies proxy_module will be broken out of the gate for libp11 without more patching.
Also speaking of pkg-config, while building libp11, I stumbled on this
$ pkg-config --variable=enginesdir libcrypto
C:/msys64/ucrt64/lib/engines-3
mlt@DESKTOP-K26J5U0 UCRT64 /c/dev/MINGW-packages/mingw-w64-libp11
$ find . -name pkcs11.dll
./pkg/mingw-w64-ucrt-x86_64-libp11C:/msys64/ucrt64/lib/engines-3/pkcs11.dll
I'm sure there is a reason why pkg-config expands prefix Windows style, but it causes pain as well.
There was a problem hiding this comment.
I see, hm. Hardcoding absolute path in binaries on Windows is a no-no in general, independent of pkg-config. Everything else works just as on Linux.
I'd say the real fix is to make libp11 relocatable, but I see that this here would be easier for now, hm... so guess this is fine.
There was a problem hiding this comment.
I see that libp11 calls pkg-config incorrectly in configure.ac in multiple places and doesn't provide the configured prefix to it. That would be even wrong on Linux if installing into a different prefix there (which is rarely used there though..)
Every call to pkg-config that gets used as an install path needs to be passed --define-variable=prefix="${prefix}" so the paths get relocated to the install prefix.
That doesn't fix the hardcode issue, but fixes the wrong install paths.
There was a problem hiding this comment.
My only concern is whether there are any security (or other) implications by allowing to load everything with same name on the PATH. I think here it is okayish.
There was a problem hiding this comment.
Yeah, by not passing an absolute path it will even load from the current working dir before looking at PATH (with it using plain LoadLibrary), unless the exe is in the same dir.
There was a problem hiding this comment.
I think it is acceptable as one can just set PKCS11_MODULE_PATH environment variable in the first place.
There was a problem hiding this comment.
Last but not least. Would it be better to use sed for a single line edits instead of a patch? Are patches the only acceptable norm?
Is there any easy way to infer -0 besides reading dlname from libp11-kit.la? I mean how stable is it? I understand it comes somewhere from libtool but I'm clueless at this point what could make it -1.
There was a problem hiding this comment.
Usually it is SOVERSION IIRC
|
bump pkgrel |
Normally on POSIX systems, p11-kit-proxy is created as a symlink in install-exec-hook target (
p11-kit/Makefile.am). I believe it is easier to simply adjust the name instead of dealing with symlink especially since the library is on the PATH. This affects #22589