| /freebsd/crypto/openssl/doc/designs/quic-design/ |
| H A D | quic-requirements.md | 52 part of this activity - we can change major release numbers even if APIs remain
55 * PR#8797 will not be merged and compatibility with the APIs proposed in that PR
86 * The objective is to have APIs that allow applications to support any of our
91 treated separately by our APIs. In the context of QUIC, APIs to be able to
93 objective of being able to select which security protocol is used, APIs that
101 to work in a QUIC environment while expanding our APIs to enable future
114 * We will provide unified, consistent APIs to our users that work for all types
134 APIs; using custom network interaction BIOs in order to get the best performance
136 using fibres). Would prefer to use the existing APIs - they don’t want to throw
140 * New applications. Would be willing to use new APIs to achieve their goals.
[all …]
|
| H A D | quic-thread-assist.md | 11 At first glance, one could synchronise handshake layer public APIs by locking a
13 the handshake layer. Since we forward a very large number of APIs to the
18 applications existing usage of the HL APIs assumes exclusive access, and thus
97 APIs we think have safe semantics here; e.g. implement only getters and not
98 setters, focus on APIs which return data which doesn't change after
99 connection. The work required is proportional to the number of APIs to be
100 enabled. Some APIs may not have ways to indicate failure; for such APIs which
|
| H A D | quic-api.md | 5 the new and changed APIs, and the design constraints motivating those API
13 + [Existing APIs](#existing-apis)
32 + [New APIs for Single-Stream Operation](#new-apis-for-single-stream-operation)
46 + [New APIs for Multi-Stream Operation](#new-apis-for-multi-stream-operation)
60 + [Future APIs](#future-apis)
62 + [Existing APIs](#existing-apis-1)
67 + [New APIs](#new-apis)
81 A listing of all SSL object APIs and their implications for QUIC, including
85 Non-SSL object APIs which are new or changed, or otherwise discussed in this
87 APIs are not listed here; see [quic-api-ssl-funcs.md](./quic-api-ssl-funcs.md)
[all …]
|
| /freebsd/secure/lib/libcrypto/man/man7/ |
| H A D | openssl-quic.7 | 84 The changes to existing libssl APIs which are driven by QUIC-related
92 New, QUIC-specific APIs.
164 .SH "CHANGES TO EXISTING APIS"
165 .IX Header "CHANGES TO EXISTING APIS"
166 Most SSL APIs, such as \fBSSL_read\fR\|(3) and \fBSSL_write\fR\|(3), function as they do
168 changes to the semantics of existing APIs are as follows:
187 \&\fBBIO_sendmmsg\fR\|(3) and \fBBIO_recvmmsg\fR\|(3) APIs must be supported.
197 Traditionally, whether the application-level I/O APIs (such as \fBSSL_read\fR\|(3)
254 The \fBSSL_set_min_proto_version\fR\|(3) and \fBSSL_set_max_proto_version\fR\|(3) APIs are
319 address; see the \fBQUIC-SPECIFIC APIS\fR section for details.
[all …]
|
| H A D | ossl-guide-migration.7 | 127 "high level" APIs (for example those functions prefixed with \f(CW\*(C`EVP\*(C'\fR). They cannot
128 be accessed using the "Low Level APIs".
151 \fILow Level APIs\fR
152 .IX Subsection "Low Level APIs"
154 OpenSSL has historically provided two sets of APIs for invoking cryptographic
155 algorithms: the "high level" APIs (such as the \f(CW\*(C`EVP\*(C'\fR APIs) and the "low level"
156 APIs. The high level APIs are typically designed to work across all algorithm
157 types. The "low level" APIs are targeted at a specific algorithm implementation.
158 For example, the EVP APIs provide the functions \fBEVP_EncryptInit_ex\fR\|(3),
161 On the other hand, to do AES encryption using the low level APIs you would have
[all …]
|
| /freebsd/crypto/openssl/doc/man7/ |
| H A D | openssl-quic.pod | 32 The changes to existing libssl APIs which are driven by QUIC-related
46 New, QUIC-specific APIs.
124 =head1 CHANGES TO EXISTING APIS
126 Most SSL APIs, such as L<SSL_read(3)> and L<SSL_write(3)>, function as they do
128 changes to the semantics of existing APIs are as follows:
160 L<BIO_sendmmsg(3)> and L<BIO_recvmmsg(3)> APIs must be supported.
173 Traditionally, whether the application-level I/O APIs (such as L<SSL_read(3)>
246 The L<SSL_set_min_proto_version(3)> and L<SSL_set_max_proto_version(3)> APIs are
353 address; see the B<QUIC-SPECIFIC APIS> section for details.
401 An application must explicitly configure whether it wishes to use the SSL APIs
[all …]
|
| H A D | ossl-guide-migration.pod | 71 "high level" APIs (for example those functions prefixed with C<EVP>). They cannot
72 be accessed using the L</Low Level APIs>.
95 =head3 Low Level APIs
97 OpenSSL has historically provided two sets of APIs for invoking cryptographic
98 algorithms: the "high level" APIs (such as the C<EVP> APIs) and the "low level"
99 APIs. The high level APIs are typically designed to work across all algorithm
100 types. The "low level" APIs are targeted at a specific algorithm implementation.
101 For example, the EVP APIs provide the functions L<EVP_EncryptInit_ex(3)>,
104 On the other hand, to do AES encryption using the low level APIs you would have
107 Use of the low level APIs has been informally discouraged by the OpenSSL
[all …]
|
| /freebsd/lib/libc/posix1e/ |
| H A D | mac.3 | 153 These APIs are loosely based on the APIs described in POSIX.1e, as described
155 However, the resemblance of these APIs to the POSIX APIs is loose, as the
156 POSIX APIs were unable to express some notions required for flexible and
|
| /freebsd/contrib/libpcap/pcap/ |
| H A D | socket.h | 61 * On Windows, this shouldn't break any APIs, as any code using
62 * the two active-mode APIs that return a socket handle would
94 * active-mode APIs that return a socket handle if those programs
95 * were written to assign the return values of those APIs to a
97 * those APIs are only provided if libpcap is built with remote
|
| H A D | funcattrs.h | 152 * APIs to be designated as "first available in this release" to do so
155 * On macOS, Apple can tweak this to make various APIs "weakly exported
158 * new APIs when available. (Yes, such third-party software exists -
161 * come with a version compiled to use the APIs present in that release.)
164 * and installing libpcap on macOS yourself, the APIs will be available
201 * The remote capture APIs are, in 1.9 and 1.10, usually only
|
| /freebsd/crypto/openssl/ssl/ |
| H A D | tls_depr.c | 10 /* We need to use some engine and HMAC deprecated APIs */
18 * Engine APIs are only used to support applications that still use ENGINEs.
98 * The HMAC APIs below are only used to support the deprecated public API
153 /* Some deprecated public APIs pass DH objects */
172 /* Some deprecated public APIs pass EC_KEY objects */
|
| /freebsd/sys/contrib/openzfs/config/ |
| H A D | kernel-idmap_mnt_api.m4 | 4 dnl # Check if APIs for idmapped mount are available
16 AC_MSG_CHECKING([whether APIs for idmapped mount are present])
20 [APIs for idmapped mount are present])
|
| /freebsd/crypto/openssl/doc/designs/ |
| H A D | handling-some-max-defines.md | 79 further APIs depending on this value.
105 Deprecate the EVP_MAX_IV_LENGTH macro. Avoid adding further APIs depending
125 APIs depending on this value.
148 Deprecate the EVP_MAX_AEAD_TAG_LENGTH macro. Avoid adding APIs depending
|
| H A D | evp-cipher-pipeline.md | 1 EVP APIs for supporting cipher pipelining in provided ciphers
49 Proposal for EVP pipeline APIs
70 Multi-call APIs for init, update and final. Associated data for AEAD ciphers
180 With the introduction of this new API, there will be two APIs for
|
| /freebsd/lib/libc/locale/ |
| H A D | DESIGN.xlocale | 5 The xlocale APIs come from Darwin, although a subset is now part of POSIX 2008.
11 This document describes the implementation of these APIs for FreeBSD.
112 parameter. The old APIs are then reimplemented with a call to `__get_locale()`
114 APIs, but also simplifies the modifications to these functions. The
123 Differences to Darwin APIs
|
| /freebsd/contrib/llvm-project/llvm/include/llvm/Analysis/ |
| H A D | GenericDomTreeUpdater.h | 109 /// \name Mutation APIs
111 /// These methods provide APIs for submitting updates to the DomTreeT and
119 /// explicitly call Flush APIs. It is recommended to use this update strategy
127 /// it is not encouraged to use these APIs directly.
177 /// \name Flush APIs
179 /// CAUTION! By the moment these flush APIs are called, the current CFG needs
|
| H A D | DomTreeUpdater.h | 44 /// \name Mutation APIs
46 /// These methods provide APIs for submitting updates to the DominatorTree and
54 /// explicitly call Flush APIs. It is recommended to use this update strategy
62 /// it is not encouraged to use these APIs directly.
|
| /freebsd/crypto/openssl/doc/designs/ddd/ |
| H A D | README.md | 9 uses the APIs which exist today, as this determines the ways in which those
19 full spectrum of ways in which real-world applications use the OpenSSL APIs.
48 QUIC. For example, while many users of OpenSSL may make use of APIs for client
50 implications for these APIs and demos demonstrating such functionality are
|
| /freebsd/crypto/openssl/include/internal/ |
| H A D | deprecated.h | 11 * This header file should be included by internal code that needs to use APIs
14 * low level APIs that are otherwise deprecated.
|
| /freebsd/contrib/ntp/sntp/libevent/ |
| H A D | whatsnew-2.0.txt | 17 growing pile of APIs. As of this writing, it covers everything except the
21 2. New and Improved Event APIs
23 Many APIs are improved, refactored, or deprecated in Libevent 2.0.
29 or if you want to port old code, we strongly recommend using the new APIs
30 and avoiding deprecated APIs as much as possible.
78 2.2. New thread-safe, binary-compatible, harder-to-mess-up APIs
82 to no longer build with another. The problems with now-deprecated APIs
184 All APIs that formerly accepted int as a socket type now accept
576 The evhttp uriencoding and uridecoding APIs have updated versions
|
| /freebsd/contrib/libevent/ |
| H A D | whatsnew-2.0.txt | 17 growing pile of APIs. As of this writing, it covers everything except the
21 2. New and Improved Event APIs
23 Many APIs are improved, refactored, or deprecated in Libevent 2.0.
29 or if you want to port old code, we strongly recommend using the new APIs
30 and avoiding deprecated APIs as much as possible.
78 2.2. New thread-safe, binary-compatible, harder-to-mess-up APIs
82 to no longer build with another. The problems with now-deprecated APIs
184 All APIs that formerly accepted int as a socket type now accept
576 The evhttp uriencoding and uridecoding APIs have updated versions
|
| /freebsd/contrib/pam-krb5/portable/ |
| H A D | krb5.h | 9 * and Heimdal, it's not possible to write code to either one of the APIs and
17 * krb5_free_unparsed_name() for both APIs since it's the most specific call.
143 * krb5_{get,free}_error_message are the preferred APIs for both current MIT
144 * and current Heimdal, but there are tons of older APIs we may have to fall
|
| /freebsd/share/man/man4/ |
| H A D | capsicum.4 | 43 preserving existing UNIX APIs and performance, and presents application authors
115 requires use of alternatives to traditional POSIX APIs in order to name
131 limits the valid values of some parameters to traditional APIs in order to
|
| /freebsd/contrib/llvm-project/lldb/bindings/interface/ |
| H A D | SBCommandInterpreterDocstrings.i | 9 '''Test the SBCommandInterpreter APIs.'''
20 # Exercise some APIs....
|
| /freebsd/contrib/elftoolchain/libelf/ |
| H A D | elf_begin.3 | 43 archives for further processing by other APIs in the
52 APIs.
236 \&... create the ELF image using other elf(3) APIs ...
|