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

Most upvoted comments

I don’t see a reason why removing the install option 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 of openssl.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, install works 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 default C:/Program Files(x86)/... value (with spaces, parenthesis) which may hit corner cases, making the build fail before reaching the install step. ]

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.