read OPENSSLDIR from registry #24450
Conversation
mattcaswell
added
branch: master
nhorman
force-pushed
the
read-openssldir-from-registry
branch
from
995c03b
to
d125bc4
Compare
github-actions
bot
added
the
severity: fips change
|
Also this needs a rebase |
|
I'm wondering whether the registry key look up should be a compile time option. Consider the example where someone installs OpenSSL on their machine using the installer. But they also have an application which has statically linked OpenSSL (or maybe just bundled its own version of OpenSSL). Suddenly that application will start getting its locations from the registry and maybe break. |
Maybe the compile time option could be set by setting an installer "context" define "-DINSTALLCONTEXT=blah", which could be included in the registry key and stop different builds of OpenSSL (maybe produced by different people) from interfering with each other. |
|
@mattcaswell I think adding a version prefix to the key would be the less confusing way to go, then each installation would just use their respective key. Ostensibly if someone has release installed via the installer, then builds openssl manually the version string should have been bumped, and there will be no conflict. the corner case there is if someone builds from an old tag against an already installed version, but at that point they have the environment variables to allow redirection. Presumably, it also seems unlikely that someone interested in using the windows installer will also be building locally that often, given that the installer is being created so that users don't have to build openssl themselves |
I disagree. I think it is very likely that people will end up a directly installed version of OpenSSL and a version of OpenSSL coming from somewhere else - quite possible of the same version (e.g. the static linking case where OpenSSL is being used in an application and maybe the end user is not even aware of it - plus a directly installed version). I think there is potential for huge confusion here and opportunity for things to be messed up. This is why I think having the registry keys thing being a build time option (off by default) is going to be essential. Having an installer specific context as an element in the key name in addition to the version would be a good thing too IMO to further reduce the possibility of problems. |
nhorman
force-pushed
the
read-openssldir-from-registry
branch
5 times, most recently
from
00241fa
to
7ea9aba
Compare
mattcaswell
added
approval: done
openssl-machine
added
approval: ready to merge
|
This pull request is ready to merge |
|
merged to master |
Build time defaults aren't great for windows, in which various macros
(like OPENSSLDIR) are selected at build time, but may be selected
differently at install time. Add an internal defaults api to return the
build time constants on unix systems, but instead query registry keys
for the form:
HLKM\SOFTWARE\OpenSSL-{version}-{wininstallcontext}
Such that each built version of openssl may maintain its own set of
registry keys to identify these locations, and be set administratiely as
appropriate at install or run time
Reviewed-by: Tomas Mraz <tomas@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from #24450)
Now that we can query for install time registry keys on windows, convert users of these macros to use the api instead Add a unit test to validate the functionality of our reg key lookups Add a test to check to make sure our registry key lookups work. note this test only runs on windows (clearly), but also only if the registry keys are set via an installer or some other manual process (to be done in the CI workflow) Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #24450)
Add a test to check to make sure our registry key lookups work. note this test only runs on windows (clearly), but also only if the registry keys are set via an installer or some other manual process (to be done in the CI workflow) Also add workflow steps to set registry keys for testing Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #24450)
On windows ci we're using powershell operations, need to follow those rules Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #24450)
to prevent security issues, don't fall back to build time default locations, instead return the string "UNDEFINED" Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #24450)
Make it more in line with other command line defines, and a bit shorter Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #24450)
Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #24450)
We don't want to allow windows systems on new installs to use OPENSSLDIR/MODULESDIR/ENGINESDIR at all, as it makes no sense to define paths at build time that have no meaning at install time. Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #24450)
Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #24450)
Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #24450)
Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #24450)
To prevent inadvertent use of insecure directories, we need to be able to detect and react when our new registry keys aren't set, which implies allowing the values for the dynamic representations of OPENSSLDIR/ENGINESDIR/MODULESDIR to return NULL. This in turn requires that we detect and handle NULL string in several call sites that previously assumed they would never be NULL. This commit fixes those up Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #24450)
Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #24450)
The behavior of windows with registry keys is somewhat confusing, and based on both build time defines, and reg key availablility. Add a table defining behavior in all cases Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #24450)
Don't need the -w option on non-windows builds Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #24450)
Fix up some indenting, and ensure that the run_once routines don't get defined if OSSL_WINCTX isn't defined to avoid compiler errors Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #24450)
we want patch level updates to use the same keys, so only create the key against the major.minor version Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #24450)
Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #24450)
Because openssl with -DOSSL_WINCTX no longer falls back to build time defines, we have a chicken and egg problem. CI needs to query openssl for its version string so registry keys can be set properly, but openssl version refuses to run because no configuration file can be found So we work around it by, for the purposes of setting the registry keys, we set OPENSSL_CONF to a know config file, so that openssl version runs properly. Once the version is extracted, we can set the registry keys, and openssl will function properly without OPENSSL_CONF set Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #24450)
The addition of sed and awk, while available in the windows vm's for CI in powershell, don't behave as I would expect (though the same commands work with a local installation on windows using GnuWin32). In trying to figure out what was going on I found it was far more stable and predictable to use the powershell -split and -replace commands instead of sed and awk Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #24450)
the openssl application attempts to load a config file on startup always, calling x509_get_default_cert_area() to locate the file. On Windows builds with -DOSSL_WINCTX set, this fails if the corresponding registry keys are unset. allow openssl to continue to function properly for applets that don't actually require a configuration file. Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from #24450)
The windows installer we have allows for targeting arbitrary locations when installing our software. But we have a build time defined default directory OPENSSLDIR which may not match that target, leading to missing configuration files/etc. Enhance openssl to query the registry for the key that our installer creates allowing for an installation to match the run time defaults. Back off to the build time directory only if the key is not defined