On Wed, 2016-06-22 at 11:26 +0100, David Woodhouse wrote: > On Wed, 2016-06-22 at 11:53 +0200, Nikos Mavrogiannopoulos wrote: > > > > > > On second view we may not need any gnutls changes for module-path. > > If > > that module is already initialized (e.g., already registered via > > p11- > > kit), then only p11_kit_uri_match_module_info() need to consider > > that > > information. > That isn't the interesting use case for module-path. The use case we > were discussing here would be to load p11-kit-remote.so when it > *wouldn't* otherwise have been loaded. > And we really do want it to be explicitly requested by module-path or > some other means, rather than *only* by an environment variable that > anyone can set before invoking a program. I'd be *really* wary of > that.
Correct, we need module-path explicit support to load any additional modules not already loaded. But still we would require some kind of registration of these modules via p11-kit, or pkcs11 URLs will not be usable from from privileged processes if they are acquired from an unprivileged one. > > For remote-fd, it would require changes to every application using > > p11- > > kit (engine_pkcs11, etc). I don't see how it could work without > > hard- > > coding it to every application. > Not application, surely? Only in GnuTLS, engine_pkcs11 and NSS. And > the > latter doesn't have *any* modern PKCS#11 URI support or p11-kit > integration anyway; right now the best advice for distribution > packages > is "Do Not Build Against NSS". But we *can* fix them all. We could, but the error surface is quite large. I don't believe we can sufficiently expect to add such a code path in three+ libraries and expect it to work the same way everywhere. The solution with getenv() requires support only in the newly introduced module thus I find it much cleaner. regards, Nikos _______________________________________________ p11-glue mailing list p11-glue@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/p11-glue
