Selecting wrong openssl.cnf in tests

[DomiNic5787]

Following line in tests sserver.sh and sclient.sh sometimes does not work as expected: export OPENSSL_CONF=$(find $(dirname $(which openssl))/../../ -name openssl.cnf | head -n 1)

For example in my case OPENSSL_CONF was set to /usr/lib/shim/mok/openssl.cnf.

This leads to error "No template, please set one up."

[DomiNic5787]

@AndreasFuchsSIT: Is #103 fixing this problem?

[AndreasFuchsTPM]

Nope, #103 was just about a sample. FWIW, we are looking for openssl.cnf that is currently installed. If we don't set it, then the CSR is not produced correctly. The libcrypto.pc and libssl.pc also do not help. On my Ubuntu, the file is under /usr/lib/ssl... Do you know how to get to it ?

Take libssl's ${prefix}/lib/ssl as first search target and only if [[ ! - e ]] we choose find ?

[PeterHuewe]

Take libssl's ${prefix}/lib/ssl as first search target and only if [[ ! - e ]] we choose find ?

Yes, go through /usr/lib/ssl , /usr/local/lib/ssland maybe one more and otherwise try the find.

[AndreasFuchsTPM]

/usr would be bad, if you're testing with an custom-prefixed OpenSSL; e.g. travis tests different versions of OpenSSL installed to a prefix, so we'll have to check either for the libssl.pc prefix/lib/ssl or for the $(which openssl)/../lib/ssl paths...

[joholl]

Would something like this work? It works for my Ubuntu.

export OPENSSL_CONF=$(ls $(dirname $(which openssl))/../lib/ssl/openssl.cnf)

Note: if there is no such file, ls will produce an error which is probably what we want.

[AndreasFuchsTPM]

Do you know where it's put on vanilla-build, arch, fedora and SuSE though ? That's the biggest one...

[joholl]

Unfortunately I don't. I also do not know how to find out without setting up a VM for each of those distros. Apparently, travis only supports Ubuntu and is not of use here, either.

[joholl]

I had a look at some of the bigger distros. Here are the paths.

• Ubuntu:
  /etc/ssl/openssl.cnf
/usr/lib/ssl/openssl.cnf -> /etc/ssl/openssl.cnf
• Arch:
  /etc/ssl/openssl.cnf
• Fedora (openssl-libs):
  /etc/pki/tls/openssl.cnf
• Suse:
  /etc/ssl/openssl.cnf

@diabonas This means if openssl is installed correctly, it knows the path to openssl.cnf and has not to be configured via the env variable OPENSSL_CONF? For me (Ubuntu) your PR works just fine.

[diabonas]

@diabonas This means if openssl is installed correctly, it knows the path to openssl.cnf and has not to be configured via the env variable OPENSSL_CONF? For me (Ubuntu) your PR works just fine.

@joholl Thank you for testing this! Exactly, if OPENSSL_CONF is not specified, it looks for the configuration file in the directory setup during configuration with --openssldir. The problem with the current CI build is that OpenSSL is installed to a different location than the configured one using DESTDIR. Using DESTDIR is meant only for package creation, the final installation location should be the configured one, see e.g. the GNU Coding Standards:

Prepending the variable DESTDIR to each target in this way provides for staged installs, where the installed files are not placed directly into their expected location but are instead copied into a temporary location (DESTDIR). [...] DESTDIR support is commonly used in package creation. It is also helpful to users who want to understand what a given package will install where, and to allow users who don’t normally have permissions to install into protected areas to build and install before gaining those permissions.

Setting the correct --openssldir should hopefully work out of the box for all distributions.

[joholl]

Cool, this should fix the problem. Thank you @diabonas!