Hi, On Thu, May 6, 2021 at 6:12 AM Jan Just Keijser <janj...@nikhef.nl> wrote: > > Hi Selva, > > Maybe I'll have to resurrect that idea or require --script-security 2 > > for this? In either case the core code will stay the same -- will wait > > for a review and/or more comments before changing anything. > > > wouldn't it make more sense to use the (existing) "--engine" parameter > for this? this is closely related to OpenSSL engines (even though the > pkcs11 module is not loaded directly) .
The existing engine option supports only one engine and would need to be extended and also require some non-trivial changes for this use case. But taking your cue, it would be easier and cleaner to introduce a new --use-pkcs11-engine option to specify the engine and module and keep the file uri as pure pkcs11. Like: --use-pkcs11-engine [engine_id] [module_path] where the optional engine_id could be just an id if installed in a location where OpenSSL can load from, else a full path. module_path also could be relative or absolute as required. > That way it will be fairly easy for tools like NetworkManager-openvpn to > filter out any unwanted stuff. > > Also, another option would be to allow the loading of a pkcs11 module > but *only* from predefined locations (e.g. /usr/lib or /usr/lib64) . > This predefined location would then need to be configured at compile time. That could work though quite limiting especially on Windows. On unix-clones, one could just require engines and modules to be in standard path and strip the so-path to its basename before use. I would prefer the --pkcs11-engine option. We anyway have a million options, one more is a drop in the bucket :) Selva _______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
