Result of nixpkgs-review pr 107599 run on x86_64-linux 1

Shouldn't this build on x86_64?

@SuperSandro2000 It currently uses requireFile since ovftool is from VMWare's website and requires a (free) account to download... if I can find a mirror that we can actually use I'll replace it

It also currently requires the (insecure) openssl_1_0_2, because ovftool depends on pre-1.1 OpenSSL

So, I at least tried forcing ovftool to use OpenSSL 1.1 and testing by signing a .ova file. It seems to specifically want to use 1.0.2 rather than 1.1. I can sign an OVA if it depends on OpenSSL 1.0.2, but bait-and-switch to 1.1 makes ovftool crash.

strace shows it looking for 1.0.2 - since our OpenSSL 1.0.2 is named 1.0.0, symlinking that into lib seemed to satisfy it. But lying it to it and symlinking 1.1 as 1.0.2 makes it look elsewhere and eventually give up/abort.

This gives us a couple options if we don't want to add new dependencies on insecure libraries:

• Use VMWare's OpenSSL. VMWare bundles an OpenSSL 1.0.2 .so with ovftool, but I deliberately didn't copy it into $out because we can provide one ourselves. It seemed better to warn users of using an old OpenSSL version by forcing them to use NIXPKGS_ALLOW_INSECURE or similar.
• Maybe try openssl-compat? Do we have any other packages that need to do this?

Result of nixpkgs-review pr 107599 run on x86_64-linux 1

@numinit still not able to test it as it is marked as broken

@numinit still not able to test it as it is marked as broken

This is because openssl_1_0_2 is insecure. If you allow insecure packages it will build.

Comments addressed.

Added ovftoolBundles param to facilitate use of the package with callPackage + VMWare .bundle file.

Any chance of seeing this merged for 21.05?

@ofborg eval

@ofborg eval

Changes addressed.