Am 20.10.21 um 20:19 schrieb Selva Nair: > Hi, > > Not a code review but a general comment as this is a new option that > warrants some discussion. > > On Tue, Oct 19, 2021 at 2:32 PM Arne Schwabe <a...@rfc2549.org > <mailto:a...@rfc2549.org>> wrote: > > This allows OpenVPN to load non-default providers. This is mainly > useful for loading the legacy provider with --provider legacy:default > > > While this format looks okay, we need to consider a few things to get > this option right and possibly extensible in future without causing a > regression. > > (i) Provider name may not be a simple word like legacy -- could also be > the path to a shared object with possible embedded space in the path > name. A single option with optional quotes, picked apart using ":" as > separator can still work. > > Ideally I would have preferred space separated provider names with > each quoted if needed, but the format proposed here may be easier to > parse. Need clear documentation, though.
Yeah using : was easier to parse since I need otherwise to setup an array or a list to store the parameter but it is doable. I was just hoping that nobody would use a : in the provider name. > (ii) We may want to attach some meaning to the order in which providers > are specified. That would be mostly a documentation thing to explain that the providers are loaded the in order specified with that option. Here is why: > > When multiple providers implement the same method (say, KEYEXCH), there > is no guarantee in OpenSSL as to which will get used. Unless a property > query like "?provider=my-fast-aes" is also used. Here the prefix "?" to > mean preferred but not exclusive. In cases like an pkcs11 token > provider, one would need to say the opposite like "?provider=default" to > ensure default is preferred and the token provider is to be used only > when required -- say when the key is in a token. Same would be the case > with our proposed built-in "external-key provider" which should be used > only for certain operations that handle the external key. > > How this relates to the --provider option is like this: in some cases we > want to know which provider the user prefers. Instead of hard-coding the > preferred provider to "default" which the user may not even want to > load. We could state that the first provider specified will become the > preferred one when there are multiple choices for a method or when a > preferred fallback is required. In that case the option for legacy would be > > --provider default:legacy > > And, if this option is absent, we take it to mean that the "default" > provider should be loaded. I would not explicitly load the default provider then but rather inherit what the system gives us. If the system wide config loads fips we should not load default instead. > This explicit loading of providers takes away > some ambiguity regarding which one's are made available. However, this > could conflict with what is in the OpenSSL config file. Which is not a > bad thing as we probably should not use the config file to load > providers (which we currently do) -- it's not supported on some > platforms (Windows as of now) and can lead to broken setups due to user > error. Yeah. I agree on that. I needed this for ANdroid where I also don't have a OpenSSL and adding one is not something I really want to do. > At the same time, provider paths and their names could be set up in > OpenSSL config files, so loading them through config has some > advantages. So, an alternate option is to not add this option at all and > require the use of a config file to load additional providers like > "legacy + default". Loading a custom config file is possible with > OpenSSL 3.0 and could be enabled on Windows in a safe manner. > > Or always load providers from OPENSSL config and use the "--provider > foo" on top of that. > > We could also consider a separate option to specify a preferred property > query ("?provider=myprov") that could be added later and not rely on any > ordering here. > > The above is just meant for further discussion -- I'm not entirely sure > what the best approach is. No, me neither. Arne _______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel