openssl: ./Configure --prefix with a Windows path always fails in a cross-build scenario
I’ve noticed your fix for the path vulnerability, thanks for this!
I was wondering if it is now also possible to manually set PREFIX/OPENSSLDIR/--prefix= to a custom, Windows path in a cross-build scenario. That case fails with the last stable releases, Windows absolute paths being misdetected as relative ones, making the build process bail out early with the error: Directory given with --prefix MUST be absolute. Another issue was that when passing a prefix containing spaces, the build process broke due to unquoted build paths that got the prefix appended to them. I could only fix the first issue by patching Configure, and the second one by using C:/Windows/ prefix, which contains no spaces.
So, I’ve made a cross-compile test (from macOS to mingw64) with the latest master, and experienced the same error as before:
./Configure mingw64 \
--cross-compile-prefix=x86_64-w64-mingw32- \
--prefix=C:/Windows/System32/OpenSSL
Output:
Failure! build file wasn't produced.
Please read INSTALL and associated NOTES files. You may also have to look over
your available compiler tool chain or change your configuration.
Directory given with --prefix MUST be absolute
The one with a vulnerable-on-Windows *nix path builds fine:
./Configure mingw64 \
--cross-compile-prefix=x86_64-w64-mingw32- \
--prefix=/usr/local
The check is done in lines below in Configure, and it uses a bare call into Perl’s native file_name_is_absolute(), where that function only works correctly on paths matching Perl’s platform, which is in this case:This is perl 5, version 30, subversion 0 (v5.30.0) built for darwin-thread-multi-2level.
elsif (/^[-+]/)
{
if (/^--prefix=(.*)$/)
{
$config{prefix}=$1;
die "Directory given with --prefix MUST be absolute\n"
unless file_name_is_absolute($config{prefix});
}
The original of this thread started here: https://github.com/openssl/openssl/pull/9400#issuecomment-517784572
/cc @levitte
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 1
- Comments: 22 (22 by maintainers)
Commits related to this issue
- Bug 31844: Fix unquoted paths in OpenSSL Windows build The default OPENSSLDIR on Windows builds contain spaces and parenthesis, which break the build as the unquoted path is used in several places. W... — committed to boklm/tor-browser-build by boklm 5 years ago
- Escape spaces and parenthesis in INSTALLTOP, OPENSSLDIR, ENGINESDIR Commit 54aa9d51b09d67e90db443f682cface795f5af9e changed the default installation prefix for mingw builds. However this new installa... — committed to boklm/openssl by boklm 5 years ago
- add flavour/branch using Schannel as its sole TLS backend [ci skip] Instead of using OpenSSL as a default backend, schannel builds will tap on the OS's TLS/SSL capabilities, meaning the exact feature... — committed to curl/curl-for-win by vszakats 3 years ago
- Configure: do not check for an absolute prefix in cross-builds The check is always made according to the host platform's rules, which may not be true for true when the target platform is different, e... — committed to t8m/openssl by vszakats 3 years ago
- Configure: do not check for an absolute prefix in cross-builds The check is always made according to the host platform's rules, which may not be true for true when the target platform is different, e... — committed to t8m/openssl by vszakats 3 years ago
- Configure: do not check for an absolute prefix in cross-builds The check is always made according to the host platform's rules, which may not be true for true when the target platform is different, e... — committed to openssl/openssl by vszakats 3 years ago
- Configure: do not check for an absolute prefix in cross-builds The check is always made according to the host platform's rules, which may not be true for true when the target platform is different, e... — committed to openssl/openssl by vszakats 3 years ago
- Configure: do not check for an absolute prefix in cross-builds The check is always made according to the host platform's rules, which may not be true for true when the target platform is different, e... — committed to openssl/openssl by vszakats 3 years ago
- Configure: do not check for an absolute prefix in cross-builds The check is always made according to the host platform's rules, which may not be true for true when the target platform is different, e... — committed to openssl/openssl by vszakats 3 years ago
- Configure: do not check for an absolute prefix in cross-builds The check is always made according to the host platform's rules, which may not be true for true when the target platform is different, e... — committed to openeuler-mirror/openssl by vszakats 3 years ago
- Configure: do not check for an absolute prefix in cross-builds The check is always made according to the host platform's rules, which may not be true for true when the target platform is different, e... — committed to openeuler-mirror/openssl by vszakats 3 years ago
- Configure: do not check for an absolute prefix in cross-builds The check is always made according to the host platform's rules, which may not be true for true when the target platform is different, e... — committed to openeuler-mirror/openssl by vszakats 3 years ago
- Configure: do not check for an absolute prefix in cross-builds The check is always made according to the host platform's rules, which may not be true for true when the target platform is different, e... — committed to openeuler-mirror/openssl by vszakats 3 years ago
I don’t see a reason why removing the
installoption would help here. In fact, it’d make the build job MUCH more cumbersome, effectively a manual picking process, all the while not fixing the core security issue where the prefix is hardcoded into the binaries anyway. (The latter could only be fully fixed by having a build option to not have any hardcoded prefix, short of a concept of a well-defined, stable, universal, admin-only path on Windows systems. Or, maybe/possibly by using a path relative to the runtime location ofopenssl.exe, OpenSSL DLLs, or runtime OpenSSL settings.)It may be nice to have an option to specify a different install path than the prefix that gets hardcoded inside the binaries. This way the current, awkward install path such as
.../pkg/C:/Windows/System32/OpenSSL/...could be replaced with a saner one. But,installworks just fine even with the oddly looking path, so this isn’t a showstopper by any means. [ Unless one is trying to use a prefix with backslashes or the defaultC:/Program Files(x86)/...value (with spaces, parenthesis) which may hit corner cases, making the build fail before reaching theinstallstep. ]IMO we could just skip the check if --cross-compile-prefix is set. Anyone doing cross-compile builds should be knowledgeable enough to know what he is doing with --prefix.