Lines Matching full:provider
5 provider-base
6 - The basic OpenSSL library E<lt>-E<gt> provider functions
89 int (*create_cb)(const OSSL_CORE_HANDLE *provider,
91 int (*remove_cb)(const OSSL_CORE_HANDLE *provider,
102 /* Functions offered by the provider to libcrypto */
119 F<libcrypto> and the provider in L<OSSL_DISPATCH(3)> arrays, in the call
120 of the provider initialization function. See L<provider(7)/Provider>
138 provider):
185 For I<*out> (the L<OSSL_DISPATCH(3)> array passed from the provider to
206 The core_thread_start() function informs the core that the provider has stated
207 an interest in the current thread. The core will inform the provider when the
208 thread eventually stops. It must be passed the I<handle> for this provider, as
211 the thread that is stopping and gets passed the provider context as an
216 object for the current provider is stored, accessible through the I<handle>.
218 provider. Never cast this to OSSL_LIB_CTX in a provider that is not
219 built-in as the OSSL_LIB_CTX of the library loading the provider might be
221 provider is linked to. Use L<OSSL_LIB_CTX_new_child(3)> instead to obtain
248 The I<reason> is a number defined by the provider and used to index
296 type. This is to ensure that a provider does not mix BIOs from the core
297 with BIOs used on the provider side (the two are not compatible).
299 passed into a provider. This may be ignored by a provider.
325 I<handle> is this provider's handle and I<cbdata> is this provider's data
331 I<create_cb> is a callback that will be called when a new provider is loaded
334 is passed the handle being used for the new provider being loadded and this
335 provider's data in I<cbdata>. It should return 1 on success or 0 on failure.
337 I<remove_cb> is a callback that will be called when a new provider is unloaded
339 the provider being unloaded and this provider's data in I<cbdata>. It should
349 this provider's teardown function is called.
351 provider_name() returns a string giving the name of the provider identified by
354 provider_get0_provider_ctx() returns the provider context that is associated
355 with the provider identified by I<prov>.
357 provider_get0_dispatch() gets the dispatch table registered by the provider
360 provider_up_ref() increments the reference count on the provider I<prov>. If
361 I<activate> is nonzero then the provider is also loaded if it is not already
364 provider_free() decrements the reference count on the provider I<prov>. If
365 I<deactivate> is nonzero then the provider is also unloaded if it is not
368 =head2 Provider functions
370 provider_teardown() is called when a provider is shut down and removed
371 from the core's provider store.
387 provider_unquery_operation() informs the provider that the result of a
393 array that provides reason strings for reason codes the provider may
399 in the I<capability> argument relevant for the provider context I<provctx>. If a
400 provider supports multiple capabilities with the given name then it may call the
402 describing the services that a provider can offer. For further details see the
407 provider module. It should return 1 on success or 0 on error. It will return 1
410 None of these functions are mandatory, but a provider is fairly
415 =head2 Provider parameters
417 provider_get_params() can return the following provider parameters to the core:
423 This points to a string that should give a unique name for the provider.
427 This points to a string that is a version number associated with this provider.
429 for any third party provider. This string is for informational purposes only.
433 This points to a string that is a build information associated with this provider.
435 different for any third party provider.
439 This returns 0 if the provider has entered an error state, otherwise it returns
449 core_get_params() can retrieve the following core parameters for each provider:
458 =item "provider-name" (B<OSSL_PROV_PARAM_CORE_PROV_NAME>) <UTF8 string ptr>
460 This points to the OpenSSL libraries' idea of what the calling provider is named.
469 Additionally, provider specific configuration parameters from the
494 The provider will have these additional parameters available:
521 Capabilities describe some of the services that a provider can offer.
527 TLS groups that a provider can support. Each group supported can be used for
532 list that they also support. In this way a provider can add to the list of
535 Each TLS group that a provider supports should be described via the callback
549 The name of the group as known by the provider. This could be the same as the
558 The name of a Key Management algorithm that the provider offers and that should
583 implementation must support the provider functions as described in
584 L<provider-keyexch(7)>.
590 in KEM mode, the group implementation must support the provider functions as
591 described in L<provider-kem(7)>.
614 This is an example of a simple provider made available as a
623 /* Errors used in this provider */
649 /* Provider context */
712 { "FOO", "provider=chumbawamba", foo_fns },
803 L<provider(7)>