| /freebsd/crypto/openssl/doc/designs/ddd/ |
| H A D | README.md | 8 proposed API change is how a broad spectrum of real-world OpenSSL applications
10 applications will be affected by any proposed changes, the extent to which they
19 full spectrum of ways in which real-world applications use the OpenSSL APIs.
22 representative of a broad spectrum of real-world OpenSSL-based applications,
24 usage patterns and with reference to the impact on existing applications.
43 be relevant to QUIC and require changes; for example, how varied applications
44 have libssl perform network I/O, and how varied applications create sockets and
60 applications to determine libssl API usage patterns. The commonly occurring usage
62 the applications:
112 …g example demonstrating real-world OpenSSL API usage (corresponding to S-AOSF applications above) |
[all …]
|
| H A D | REPORT.md | 6 applications to be able to adapt their code to use QUIC. The demo-driven design
15 applications could be kept very small in many circumstances, with only minimal
41 The originally planned change to enable applications for QUIC amounted to just a
71 The originally planned changes to enable applications for QUIC amounted to:
103 to applications to determine I/O readiness has changed substantially since the
104 original DDD process. As such, applications now use `BIO_get_rpoll_descriptor`
130 still desirable for applications to remove this code.
143 The originally planned changes to enable applications for QUIC amounted to:
240 usage pattern for applications. Managing this pattern for QUIC is more elaborate
253 - Potential changes to buffer sizes used by applications to buffer
[all …]
|
| /freebsd/secure/lib/libcrypto/man/man7/ |
| H A D | openssl-quic.7 | 68 You can use OpenSSL's QUIC capabilities for both client and server applications.
69 This man page describes how to let applications use the QUIC protocol using the
74 are needed to existing applications which use libssl API to bring QUIC protocol
85 implementation requirements, which existing applications should bear in mind;
87 Aspects which must be considered by existing applications when adopting QUIC,
90 Recommended usage approaches for new applications.
103 Default stream mode is primarily for compatibility with existing applications.
104 For new applications utilizing QUIC, it's recommended to disable this mode and
105 instead adopt the multi-stream API. See the RECOMMENDATIONS FOR NEW APPLICATIONS
132 Default stream mode is intended to aid compatibility with legacy applications.
[all …]
|
| H A D | ossl-guide-migration.7 | 81 consequently the property query \f(CW\*(C`fips=yes\*(C'\fR is mandatory for applications that
103 of applications will work unchanged with OpenSSL 3.0 if those applications
106 applications need to take advantage of some of the new features available in
149 "Using the FIPS Module in applications".
167 your applications, but you may start to see deprecation warnings during
183 Applications using the EVP APIs to access these algorithms should instead use
184 more modern algorithms. If that is not possible then these applications
199 This is particularly relevant for applications written to use the OpenSSL 3.0
267 Existing applications that use KDF algorithms using EVP_PKEY
270 All new applications should use the new \fBEVP_KDF\fR\|(3) interface.
[all …]
|
| H A D | fips_module.7 | 80 Applications written to use the OpenSSL 3.0 FIPS module should not use any
94 .SS "Making all applications use the FIPS module by default"
95 .IX Subsection "Making all applications use the FIPS module by default"
96 One simple approach is to cause all applications that are using OpenSSL to only
99 This approach can be done purely via configuration. As long as applications are
158 Any applications that use OpenSSL 3.0 and are started after these changes are
159 made will start using only the FIPS module unless those applications take
167 are required in applications in order to benefit from the FIPS module. There are
170 You may not want all applications to use the FIPS module.
172 It may be the case that some applications should and some should not use the
[all …]
|
| H A D | ossl-guide-libraries-introduction.7 | 68 OpenSSL supplies two libraries that can be used by applications known as
86 \&\f(CW\*(C`libcrypto\*(C'\fR, and most applications that do this will directly use API functions
89 Applications may be written that only use \f(CW\*(C`libcrypto\*(C'\fR capabilities and do not
129 functions take a library context as a parameter. Applications can always pass
166 .SH "MULTI-THREADED APPLICATIONS"
167 .IX Header "MULTI-THREADED APPLICATIONS"
306 Applications that create their own library contexts may optionally configure
343 .SH "DEMO APPLICATIONS"
344 .IX Header "DEMO APPLICATIONS"
345 OpenSSL is distributed with a set of demo applications which provide some
[all …]
|
| /freebsd/share/man/man7/ |
| H A D | clocks.7 | 47 It is not available to applications.
51 It is not directly available to applications.
108 Applications should determine its actual frequency using
115 It is not available to applications.
121 and is exported to applications in
129 applications.
135 It is not available to applications.
154 It is not available to applications.
|
| /freebsd/crypto/openssl/doc/man7/ |
| H A D | openssl-quic.pod | 10 You can use OpenSSL's QUIC capabilities for both client and server applications.
11 This man page describes how to let applications use the QUIC protocol using the
16 are needed to existing applications which use libssl API to bring QUIC protocol
33 implementation requirements, which existing applications should bear in mind;
37 Aspects which must be considered by existing applications when adopting QUIC,
42 Recommended usage approaches for new applications.
60 Default stream mode is primarily for compatibility with existing applications.
61 For new applications utilizing QUIC, it's recommended to disable this mode and
62 instead adopt the multi-stream API. See the RECOMMENDATIONS FOR NEW APPLICATIONS
90 Default stream mode is intended to aid compatibility with legacy applications.
[all …]
|
| H A D | ossl-guide-migration.pod | 25 consequently the property query C<fips=yes> is mandatory for applications that
49 of applications will work unchanged with OpenSSL 3.0 if those applications
52 applications need to take advantage of some of the new features available in
93 L</Using the FIPS Module in applications>.
110 your applications, but you may start to see deprecation warnings during
125 Applications using the EVP APIs to access these algorithms should instead use
126 more modern algorithms. If that is not possible then these applications
140 This is particularly relevant for applications written to use the OpenSSL 3.0
202 Existing applications that use KDF algorithms using EVP_PKEY
205 All new applications should use the new L<EVP_KDF(3)> interface.
[all …]
|
| H A D | fips_module.pod | 23 Applications written to use the OpenSSL 3.0 FIPS module should not use any
48 =head2 Making all applications use the FIPS module by default
50 One simple approach is to cause all applications that are using OpenSSL to only
53 This approach can be done purely via configuration. As long as applications are
106 Any applications that use OpenSSL 3.0 and are started after these changes are
107 made will start using only the FIPS module unless those applications take
115 are required in applications in order to benefit from the FIPS module. There are
122 You may not want all applications to use the FIPS module.
124 It may be the case that some applications should and some should not use the
129 If applications take explicit steps to not load the default config file or
[all …]
|
| /freebsd/crypto/openssl/ |
| H A D | README-ENGINES.md | 58 applications when they use that ENGINE. Work is in progress (or at least
60 NCONF) code so that applications using OpenSSL's existing configuration
62 Presently however, applications must use the ENGINE API itself to provide
86 devices from common OpenSSL-based applications. Bugs and/or inexplicable
119 This way, applications do not need to know anything specific to any
135 applications. This could be because existing compiled-in implementations
141 The other use-case for "dynamic" is with applications that wish to
147 applications based on OpenSSL 0.9.7 or later. If you're using an
180 ENGINE's "id". For most applications, this isn't necessary - but some
216 Applications that support the ENGINE API and more specifically, the
[all …]
|
| /freebsd/secure/lib/libcrypto/man/man3/ |
| H A D | EVP_PKEY_set1_RSA.3 | 142 functions are deprecated. Applications should instead use
149 \&\fIpkey\fR is freed. These macros are deprecated. Applications should instead read
157 These functions are deprecated. Applications should instead use the EVP_PKEY
159 then applications should use \fBEVP_PKEY_get_params\fR\|(3) and other similar
168 are deprecated. Applications should instead use the EVP_PKEY directly where
170 applications should use \fBEVP_PKEY_get_params\fR\|(3) and other similar functions.
191 function is deprecated. Applications should use providers instead of engines
197 error occurs. This function is deprecated. Applications should use providers
219 in order that applications can "free" the return value. However applications
235 Most applications wishing to know a key type will simply call
|
| H A D | SSL_CTX_set_tmp_dh_callback.3 | 119 Typically applications should use well known DH parameters that have built-in
133 Applications may supply their own DH parameters instead of using the built-in
134 values. This approach is discouraged and applications should in preference use
135 the built-in parameter support described above. Applications wishing to supply
146 ownership of the \fBDH\fR object is retained by the application. Applications
153 functions are deprecated. Applications should instead use "auto" parameters, or
|
| /freebsd/contrib/ofed/librdmacm/man/ |
| H A D | rsocket.7.in | 11 for applications. Rsocket APIs are intended to match the behavior
109 applications which must mix rsocket fd's with standard socket fd's or
113 Existing applications can make use of rsockets through the use of a
122 Note that not all applications will work with rsockets. Support is
125 the preload library for applications that call fork, users must
128 supportable for server applications that accept a connection, then
156 Applications can override default values programmatically through the
|
| /freebsd/crypto/openssl/doc/man3/ |
| H A D | EVP_PKEY_set1_RSA.pod | 81 functions are deprecated. Applications should instead use
88 I<pkey> is freed. These macros are deprecated. Applications should instead read
96 These functions are deprecated. Applications should instead use the EVP_PKEY
98 then applications should use L<EVP_PKEY_get_params(3)> and other similar
107 are deprecated. Applications should instead use the EVP_PKEY directly where
109 applications should use L<EVP_PKEY_get_params(3)> and other similar functions.
130 function is deprecated. Applications should use providers instead of engines
136 error occurs. This function is deprecated. Applications should use providers
159 in order that applications can "free" the return value. However applications
176 Most applications wishing to know a key type will simply call
|
| H A D | SSL_CTX_set_tmp_dh_callback.pod | 58 Typically applications should use well known DH parameters that have built-in
72 Applications may supply their own DH parameters instead of using the built-in
73 values. This approach is discouraged and applications should in preference use
74 the built-in parameter support described above. Applications wishing to supply
85 ownership of the B<DH> object is retained by the application. Applications
92 functions are deprecated. Applications should instead use "auto" parameters, or
|
| /freebsd/crypto/heimdal/lib/wind/ |
| H A D | rfc3490.txt | 16 Internationalizing Domain Names in Applications (IDNA)
35 Internationalizing Domain Names in Applications (IDNA) for handling
68 6. Implications for typical applications using DNS............... 13
69 6.1 Entry and display in applications......................... 14
70 6.2 Applications and resolver libraries....................... 15
86 IDNA works by allowing applications to use certain ASCII name labels
94 This document does not require any applications to conform to IDNA,
95 but applications can elect to use IDNA in order to support IDN while
105 the IDN Working Group would depend on user applications, resolvers,
109 applications only; no changes are needed to the DNS protocol or any
[all …]
|
| /freebsd/crypto/krb5/src/windows/installer/wix/ |
| H A D | files.wxi | 85 …are\Microsoft\Windows NT\CurrentVersion\Terminal Server\Compatibility\Applications\gss-client" Act…
86 …are\Microsoft\Windows NT\CurrentVersion\Terminal Server\Compatibility\Applications\gss-client" Nam…
90 …are\Microsoft\Windows NT\CurrentVersion\Terminal Server\Compatibility\Applications\gss-server" Act…
91 …are\Microsoft\Windows NT\CurrentVersion\Terminal Server\Compatibility\Applications\gss-server" Nam…
95 …are\Microsoft\Windows NT\CurrentVersion\Terminal Server\Compatibility\Applications\kdestroy" Actio…
96 …are\Microsoft\Windows NT\CurrentVersion\Terminal Server\Compatibility\Applications\kdestroy" Name=…
100 …are\Microsoft\Windows NT\CurrentVersion\Terminal Server\Compatibility\Applications\kcpytkt" Action…
101 …are\Microsoft\Windows NT\CurrentVersion\Terminal Server\Compatibility\Applications\kcpytkt" Name="…
105 …are\Microsoft\Windows NT\CurrentVersion\Terminal Server\Compatibility\Applications\kdeltkt" Action…
106 …are\Microsoft\Windows NT\CurrentVersion\Terminal Server\Compatibility\Applications\kdeltkt" Name="…
[all …]
|
| /freebsd/crypto/openssl/doc/designs/quic-design/ |
| H A D | quic-io-arch.md | 7 It also identifies potential hazards to existing applications, and identifies
20 - High performance applications (primarily server based) using existing libssl
33 - In the case of non-blocking applications, it must be possible
48 over TCP. This will require applications using custom BIOs on the network side
147 able to support blocking semantics at the application level. Applications
198 Even if this approach were successfully implemented, applications will still
199 need to change to using network BIOs with datagram semantics. For applications
203 accommodating applications using custom network BIOs in a blocking mode, these
204 applications would still have to completely rework their implementation of those
206 applications implementing their own custom BIOs will do so in a blocking mode.
[all …]
|
| H A D | quic-requirements.md | 86 * The objective is to have APIs that allow applications to support any of our
92 handle a collection of streams will be necessary for many applications. With the
96 * The majority of existing applications operate using a single connection (i.e.
100 * We need to enable the majority of our existing user’s applications to be able
115 of applications ranging from simple single stream clients up to optimised high
133 * High performance applications (primarily server based) using existing libssl
140 * New applications. Would be willing to use new APIs to achieve their goals.
150 applications should be able to pick whatever protocol they want to use
|
| /freebsd/contrib/ofed/libmlx5/ |
| H A D | mlx5dv.7 | 14 of user applications portability it has a performance penalty. For some
15 applications optimizing performance is more important than portability.
17 The mlx5 direct verbs API is intended for such applications.
35 thus using the mlx5 direct verbs does not limit the applications
|
| /freebsd/contrib/libpcap/doc/ |
| H A D | README.linux | 11 will probably be used by other applications in the future) won't work
20 can replace that older version without breaking applications built with
22 procedure for applications whose configure script doesn't use the
24 procedure for applications whose configure scripts use the pcap-config
|
| /freebsd/share/man/man4/ |
| H A D | vmci.4 | 32 User level applications in a virtual machine can use VMCI through vSockets
39 applications, where network access of the virtual machine is restricted
42 hardware running as host applications and automated testing of applications
|
| /freebsd/lib/librss/ |
| H A D | librss.3 | 7 .Nd Provide Receive-side scaling awareness to userland applications
33 Applications will typically call
52 Applications will typically use the
63 Typically applications will wish to just query for
|
| /freebsd/crypto/krb5/src/plugins/kdb/db2/libdb2/man/ |
| H A D | db_log.3 | 112 Applications cannot create LSN's, and all LSN's provided to functions
118 To provide a distinguished value for applications, it is guaranteed that
121 Applications can compare LSN's using the
125 Applications can associate LSN's with specific log files.
136 Applications can truncate the log file up to a specific LSN using the
167 A pointer to a function which is provided to permit applications to
|