Lines Matching full:provider
133 .IX Title "PROVIDER-BASE 7ossl"
134 .TH PROVIDER-BASE 7ossl "2023-09-19" "3.0.11" "OpenSSL"
140 provider\-base
141 \&\- The basic OpenSSL library <\-> provider functions
224 \& int (*create_cb)(const OSSL_CORE_HANDLE *provider,
226 \& int (*remove_cb)(const OSSL_CORE_HANDLE *provider,
237 \& /* Functions offered by the provider to libcrypto */
254 \&\fIlibcrypto\fR and the provider in \s-1\fBOSSL_DISPATCH\s0\fR\|(3) arrays, in the call
255 of the provider initialization function. See \*(L"Provider\*(R" in \fBprovider\fR\|(7)
275 provider):
324 For \fI*out\fR (the \s-1\fBOSSL_DISPATCH\s0\fR\|(3) array passed from the provider to
346 The \fBcore_thread_start()\fR function informs the core that the provider has stated
347 an interest in the current thread. The core will inform the provider when the
348 thread eventually stops. It must be passed the \fIhandle\fR for this provider, as
351 the thread that is stopping and gets passed the provider context as an
356 object for the current provider is stored, accessible through the \fIhandle\fR.
358 provider. Never cast this to \s-1OSSL_LIB_CTX\s0 in a provider that is not
359 built-in as the \s-1OSSL_LIB_CTX\s0 of the library loading the provider might be
361 provider is linked to. Use \fBOSSL_LIB_CTX_new_child\fR\|(3) instead to obtain
383 The \fIreason\fR is a number defined by the provider and used to index
429 type. This is to ensure that a provider does not mix BIOs from the core
430 with BIOs used on the provider side (the two are not compatible).
432 passed into a provider. This may be ignored by a provider.
458 \&\fIhandle\fR is this provider's handle and \fIcbdata\fR is this provider's data
464 \&\fIcreate_cb\fR is a callback that will be called when a new provider is loaded
467 is passed the handle being used for the new provider being loadded and this
468 provider's data in \fIcbdata\fR. It should return 1 on success or 0 on failure.
470 \&\fIremove_cb\fR is a callback that will be called when a new provider is unloaded
472 the provider being unloaded and this provider's data in \fIcbdata\fR. It should
482 this provider's teardown function is called.
484 \&\fBprovider_name()\fR returns a string giving the name of the provider identified by
487 \&\fBprovider_get0_provider_ctx()\fR returns the provider context that is associated
488 with the provider identified by \fIprov\fR.
490 \&\fBprovider_get0_dispatch()\fR gets the dispatch table registered by the provider
493 \&\fBprovider_up_ref()\fR increments the reference count on the provider \fIprov\fR. If
494 \&\fIactivate\fR is nonzero then the provider is also loaded if it is not already
497 \&\fBprovider_free()\fR decrements the reference count on the provider \fIprov\fR. If
498 \&\fIdeactivate\fR is nonzero then the provider is also unloaded if it is not
500 .SS "Provider functions"
501 .IX Subsection "Provider functions"
502 \&\fBprovider_teardown()\fR is called when a provider is shut down and removed
503 from the core's provider store.
519 \&\fBprovider_unquery_operation()\fR informs the provider that the result of a
525 array that provides reason strings for reason codes the provider may
531 in the \fIcapability\fR argument relevant for the provider context \fIprovctx\fR. If a
532 provider supports multiple capabilities with the given name then it may call the
534 describing the services that a provider can offer. For further details see the
539 provider module. It should return 1 on success or 0 on error. It will return 1
542 None of these functions are mandatory, but a provider is fairly
546 .SS "Provider parameters"
547 .IX Subsection "Provider parameters"
548 \&\fBprovider_get_params()\fR can return the following provider parameters to the core:
552 This points to a string that should give a unique name for the provider.
556 This points to a string that is a version number associated with this provider.
558 for any third party provider. This string is for informational purposes only.
562 This points to a string that is a build information associated with this provider.
564 different for any third party provider.
568 This returns 0 if the provider has entered an error state, otherwise it returns
574 \&\fBcore_get_params()\fR can retrieve the following core parameters for each provider:
582 .IX Item "provider-name (OSSL_PROV_PARAM_CORE_PROV_NAME) <UTF8 string ptr>"
583 This points to the OpenSSL libraries' idea of what the calling provider is named.
590 Additionally, provider specific configuration parameters from the
617 The provider will have these additional parameters available:
639 Capabilities describe some of the services that a provider can offer.
646 \&\s-1TLS\s0 groups that a provider can support. Each group supported can be used for
651 list that they also support. In this way a provider can add to the list of
654 Each \s-1TLS\s0 group that a provider supports should be described via the callback
666 The name of the group as known by the provider. This could be the same as the
675 The name of a Key Management algorithm that the provider offers and that should
700 implementation must support the provider functions as described in
707 in \s-1KEM\s0 mode, the group implementation must support the provider functions as
708 described in \fBprovider\-kem\fR\|(7).
733 This is an example of a simple provider made available as a
743 \& /* Errors used in this provider */
769 \& /* Provider context */
832 \& { "FOO", "provider=chumbawamba", foo_fns },