Lines Matching refs:provider
5 provider-base
6 - The basic OpenSSL library E<lt>-E<gt> provider functions
94 int (*create_cb)(const OSSL_CORE_HANDLE *provider,
96 int (*remove_cb)(const OSSL_CORE_HANDLE *provider,
107 /* Functions offered by the provider to libcrypto */
124 F<libcrypto> and the provider in B<OSSL_DISPATCH> arrays, in the call
125 of the provider initialization function. See L<provider(7)/Provider>
143 provider):
193 For I<*out> (the B<OSSL_DISPATCH> array passed from the provider to
214 The core_thread_start() function informs the core that the provider has stated
215 an interest in the current thread. The core will inform the provider when the
216 thread eventually stops. It must be passed the I<handle> for this provider, as
219 the thread that is stopping and gets passed the provider context as an
224 object for the current provider is stored, accessible through the I<handle>.
226 provider. Never cast this to OSSL_LIB_CTX in a provider that is not
227 built-in as the OSSL_LIB_CTX of the library loading the provider might be
229 provider is linked to. Use L<OSSL_LIB_CTX_new_child(3)> instead to obtain
256 The I<reason> is a number defined by the provider and used to index
303 type. This is to ensure that a provider does not mix BIOs from the core
304 with BIOs used on the provider side (the two are not compatible).
306 passed into a provider. This may be ignored by a provider.
332 I<handle> is this provider's handle and I<cbdata> is this provider's data
338 I<create_cb> is a callback that will be called when a new provider is loaded
341 is passed the handle being used for the new provider being loadded and this
342 provider's data in I<cbdata>. It should return 1 on success or 0 on failure.
344 I<remove_cb> is a callback that will be called when a new provider is unloaded
346 the provider being unloaded and this provider's data in I<cbdata>. It should
356 this provider's teardown function is called.
358 provider_name() returns a string giving the name of the provider identified by
361 provider_get0_provider_ctx() returns the provider context that is associated
362 with the provider identified by I<prov>.
364 provider_get0_dispatch() gets the dispatch table registered by the provider
367 provider_up_ref() increments the reference count on the provider I<prov>. If
368 I<activate> is nonzero then the provider is also loaded if it is not already
371 provider_free() decrements the reference count on the provider I<prov>. If
372 I<deactivate> is nonzero then the provider is also unloaded if it is not
377 provider_teardown() is called when a provider is shut down and removed
378 from the core's provider store.
394 provider_unquery_operation() informs the provider that the result of a
400 array that provides reason strings for reason codes the provider may
406 in the I<capability> argument relevant for the provider context I<provctx>. If a
407 provider supports multiple capabilities with the given name then it may call the
409 describing the services that a provider can offer. For further details see the
414 provider module. It should return 1 on success or 0 on error. It will return 1
417 None of these functions are mandatory, but a provider is fairly
424 provider_get_params() can return the following provider parameters to the core:
430 This points to a string that should give a unique name for the provider.
434 This points to a string that is a version number associated with this provider.
436 for any third party provider. This string is for informational purposes only.
440 This points to a string that is a build information associated with this provider.
442 different for any third party provider.
446 This returns 0 if the provider has entered an error state, otherwise it returns
456 core_get_params() can retrieve the following core parameters for each provider:
465 =item "provider-name" (B<OSSL_PROV_PARAM_CORE_PROV_NAME>) <UTF8 string ptr>
467 This points to the OpenSSL libraries' idea of what the calling provider is named.
476 Additionally, provider specific configuration parameters from the
501 The provider will have these additional parameters available:
528 Capabilities describe some of the services that a provider can offer.
534 TLS groups that a provider can support. Each group supported can be used for
539 list that they also support. In this way a provider can add to the list of
542 Each TLS group that a provider supports should be described via the callback
556 The name of the group as known by the provider. This could be the same as the
565 The name of a Key Management algorithm that the provider offers and that should
590 implementation must support the provider functions as described in
591 L<provider-keyexch(7)>.
597 in KEM mode, the group implementation must support the provider functions as
598 described in L<provider-kem(7)>.
626 This is an example of a simple provider made available as a
635 /* Errors used in this provider */
724 { "FOO", "provider=chumbawamba", foo_fns },
815 L<provider(7)>