sync code with last improvements from OpenBSD

etc/examples/radiusd.conf

@@ -1,4 +1,4 @@
-#	$OpenBSD: radiusd.conf,v 1.3 2023/08/18 06:45:15 yasuoka Exp $
+#	$OpenBSD: radiusd.conf,v 1.4 2023/09/18 14:44:21 sobrado Exp $
 
 listen on 0.0.0.0
 #listen on ::
@@ -13,16 +13,16 @@ client 192.168.0.0/24 {
 	secret "secret"
 }
 
-module load "bsdauth" "/usr/libexec/radiusd/radiusd_bsdauth"
+module load bsdauth "/usr/libexec/radiusd/radiusd_bsdauth"
-#module set "bsdauth" "restrict-group" "users"
+#module set bsdauth restrict-group users
 
-module load "radius"  "/usr/libexec/radiusd/radiusd_radius"
+module load radius "/usr/libexec/radiusd/radiusd_radius"
-module set "radius" "secret" "testing123"
+module set radius secret "testing123"
-module set "radius" "server" "127.0.0.1"
+module set radius server "127.0.0.1"
 
 authenticate *@local {
-	authenticate-by "bsdauth"
+	authenticate-by bsdauth
 }
 authenticate *@example.com {
-	authenticate-by "radius"
+	authenticate-by radius
 }

etc/root/root.mail

@@ -1,9 +1,9 @@
-From purplerain@secbsd.org Fri Aug 11 00:00:00 UTC 2023
+From purplerain@secbsd.org Mon Oct 27 00:00:00 UTC 2023
 Return-Path: root
-Date: Aug 11 00:00:00 UTC 2023
+Date: Oct 27 00:00:00 UTC 2023
 From: purplerain@secbsd.org (Purple Rain)
 To: root
-Subject: Welcome to SecBSD 1.3!
+Subject: Welcome to SecBSD 1.4!
 
 This message attempts to describe the most basic initial questions that a
 system administrator of an SecBSD box might have.  You are urged to save

etc/skel/dot.version

@@ -1 +1 @@
-# SecBSD 1.3-88c72e05f8: Thu Sep 14 00:00:00 UTC 2023 (Tezcatlipoca)
+# SecBSD 1.4-58d3272: Tue Sep 19 00:00:00 UTC 2023 (Tezcatlipoca)

lib/libcrypto/man/CRYPTO_set_ex_data.3

@@ -1,70 +1,32 @@
-.\" $OpenBSD: CRYPTO_set_ex_data.3,v 1.14 2023/07/28 14:34:54 tb Exp $
+.\" $OpenBSD: CRYPTO_set_ex_data.3,v 1.15 2023/09/18 14:49:43 schwarze Exp $
-.\" full merge up to:
-.\" OpenSSL CRYPTO_get_ex_new_index 9e183d22 Mar 11 08:56:44 2017 -0500
-.\" selective merge up to: 72a7a702 Feb 26 14:05:09 2019 +0000
 .\"
-.\" This file was written by Dr. Stephen Henson <steve@openssl.org>
+.\" Copyright (c) 2023 Ingo Schwarze <schwarze@openbsd.org>
-.\" and by Rich Salz <rsalz@akamai.com>.
-.\" Copyright (c) 2000, 2006, 2015, 2016 The OpenSSL Project.
-.\" All rights reserved.
 .\"
-.\" Redistribution and use in source and binary forms, with or without
+.\" Permission to use, copy, modify, and distribute this software for any
-.\" modification, are permitted provided that the following conditions
+.\" purpose with or without fee is hereby granted, provided that the above
-.\" are met:
+.\" copyright notice and this permission notice appear in all copies.
 .\"
-.\" 1. Redistributions of source code must retain the above copyright
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
-.\"    notice, this list of conditions and the following disclaimer.
+.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" 2. Redistributions in binary form must reproduce the above copyright
+.Dd $Mdocdate: September 18 2023 $
-.\"    notice, this list of conditions and the following disclaimer in
-.\"    the documentation and/or other materials provided with the
-.\"    distribution.
-.\"
-.\" 3. All advertising materials mentioning features or use of this
-.\"    software must display the following acknowledgment:
-.\"    "This product includes software developed by the OpenSSL Project
-.\"    for use in the OpenSSL Toolkit. (http://www.openssl.org/)"
-.\"
-.\" 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to
-.\"    endorse or promote products derived from this software without
-.\"    prior written permission. For written permission, please contact
-.\"    openssl-core@openssl.org.
-.\"
-.\" 5. Products derived from this software may not be called "OpenSSL"
-.\"    nor may "OpenSSL" appear in their names without prior written
-.\"    permission of the OpenSSL Project.
-.\"
-.\" 6. Redistributions of any form whatsoever must retain the following
-.\"    acknowledgment:
-.\"    "This product includes software developed by the OpenSSL Project
-.\"    for use in the OpenSSL Toolkit (http://www.openssl.org/)"
-.\"
-.\" THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY
-.\" EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
-.\" PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE OpenSSL PROJECT OR
-.\" ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
-.\" SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
-.\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
-.\" LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
-.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
-.\" STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
-.\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
-.\" OF THE POSSIBILITY OF SUCH DAMAGE.
-.\"
-.Dd $Mdocdate: July 28 2023 $
 .Dt CRYPTO_SET_EX_DATA 3
 .Os
 .Sh NAME
+.Nm CRYPTO_get_ex_new_index ,
 .Nm CRYPTO_EX_new ,
 .Nm CRYPTO_EX_free ,
 .Nm CRYPTO_EX_dup ,
-.Nm CRYPTO_get_ex_new_index ,
+.Nm CRYPTO_new_ex_data ,
 .Nm CRYPTO_set_ex_data ,
 .Nm CRYPTO_get_ex_data ,
-.Nm CRYPTO_free_ex_data ,
+.Nm CRYPTO_free_ex_data
-.Nm CRYPTO_new_ex_data
+.Nd low-level functions for application specific data
-.Nd functions supporting application-specific data
 .Sh SYNOPSIS
 .In openssl/crypto.h
 .Ft int
@@ -79,7 +41,7 @@
 .Ft typedef int
 .Fo CRYPTO_EX_new
 .Fa "void *parent"
-.Fa "void *ptr"
+.Fa "void *data"
 .Fa "CRYPTO_EX_DATA *ad"
 .Fa "int idx"
 .Fa "long argl"
@@ -88,7 +50,7 @@
 .Ft typedef void
 .Fo CRYPTO_EX_free
 .Fa "void *parent"
-.Fa "void *ptr"
+.Fa "void *data"
 .Fa "CRYPTO_EX_DATA *ad"
 .Fa "int idx"
 .Fa "long argl"
@@ -98,7 +60,7 @@
 .Fo CRYPTO_EX_dup
 .Fa "CRYPTO_EX_DATA *to"
 .Fa "const CRYPTO_EX_DATA *from"
-.Fa "void *from_d"
+.Fa "void *datap"
 .Fa "int idx"
 .Fa "long argl"
 .Fa "void *argp"
@@ -106,238 +68,336 @@
 .Ft int
 .Fo CRYPTO_new_ex_data
 .Fa "int class_index"
-.Fa "void *obj"
+.Fa "void *parent"
 .Fa "CRYPTO_EX_DATA *ad"
 .Fc
 .Ft int
 .Fo CRYPTO_set_ex_data
-.Fa "CRYPTO_EX_DATA *r"
+.Fa "CRYPTO_EX_DATA *ad"
 .Fa "int idx"
-.Fa "void *arg"
+.Fa "void *data"
 .Fc
 .Ft void *
 .Fo CRYPTO_get_ex_data
-.Fa "CRYPTO_EX_DATA *r"
+.Fa "CRYPTO_EX_DATA *ad"
 .Fa "int idx"
 .Fc
 .Ft void
 .Fo CRYPTO_free_ex_data
 .Fa "int class_index"
-.Fa "void *obj"
+.Fa "void *parent"
-.Fa "CRYPTO_EX_DATA *r"
+.Fa "CRYPTO_EX_DATA *ad"
 .Fc
 .Sh DESCRIPTION
-Several OpenSSL structures can have application specific data attached
+The library implements the functions documented in the
-to them, known as "exdata".
+.Xr RSA_get_ex_new_index 3
-The specific structures are:
+manual page and similar functions for other parent object types
-.Bd -literal
+using the functions documented in the present manual page.
-    BIO
+Application programs almost never need
-    DH
+to call the functions documented here directly.
-    DSA
+.Pp
-    EC_KEY
+.Fn CRYPTO_get_ex_new_index
-    ECDH
+behaves in the same way as
-    ECDSA
+.Xr RSA_get_ex_new_index 3
-    ENGINE
+except that the parent object type that the new
-    RSA
+.Fa idx
-    SSL
+is reserved for is not part of the function name
-    SSL_CTX
+but instead specified by the additional
-    SSL_SESSION
+.Fa class_index
-    UI
+argument receiving one of the
-    X509
+.Dv CRYPTO_EX_INDEX_*
-    X509_STORE
+constants defined in
-    X509_STORE_CTX
+.In openssl/crypto.h .
+The recommendation given in
+.Xr RSA_get_ex_new_index 3
+to set the
+.Fa argl
+argument to 0 and the last four arguments all to
+.Dv NULL
+applies.
+The library passes the
+.Fa argl
+and
+.Fa argp
+arguments through to the callback functions for the respective
+.Fa idx ,
+but ignores them otherwise.
+.Pp
+If a function pointer is passed for the
+.Fa new_func
+argument, that function is called for the returned
+.Fa idx
+whenever a new parent object is allocated with
+.Xr RSA_new 3
+or a similar function.
+.Pp
+If a function pointer is passed for the
+.Fa free_func
+argument, that function is called for the returned
+.Fa idx
+when a parent object is freed with
+.Xr RSA_free 3
+or a similar function.
+.Pp
+The arguments of
+.Fa new_func
+and
+.Fa free_func
+are as follows:
+.Pp
+.Bl -tag -width Ds -compact
+.It Fa parent
+the parent object that contains the
+.Fa data
+.It Fa data
+the
+.Fa data
+previously set by
+.Fn CRYPTO_set_ex_data
+at
+.Fa idx
+in
+.Fa parent
+.It Fa ad
+the
+.Vt CRYPTO_EX_DATA
+subobject of the
+.Fa parent
+object
+.It Fa idx
+return value of
+.Fn CRYPTO_get_ex_new_index
+that set this callback
+.It Fa argl
+the
+.Fa argl
+passed to
+.Fn CRYPTO_get_ex_new_index
+for this
+.Fa idx
+.It Fa argp
+the
+.Fa argp
+passed to
+.Fn CRYPTO_get_ex_new_index
+for this
+.Fa idx
+.El
+.Pp
+If a function pointer is passed for the
+.Fa dup_func ,
+that function is supposed to be called for the returned
+.Fa idx
+whenever a parent object of the respective type is copied.
+Actually, the only functions doing that are
+.Xr BIO_dup_chain 3 ,
+.Xr EC_KEY_copy 3 ,
+and
+.Xr SSL_dup 3 ,
+and the TLS 1.3 network stack does it internally when duplicating a
+.Vt SSL_SESSION
+object after receiving a new session ticket message.
+Most other object types supporting ex_data do not support
+copying in the first place, whereas
+.Xr DSA_dup_DH 3
+and
+.Xr X509_dup 3
+simply ignore
+.Fa dup_func .
+.Pp
+The arguments of
+.Fa dup_func
+are as follows:
+.Pp
+.Bl -tag -width Ds -compact
+.It Fa to
+the
+.Vt CRYPTO_EX_DATA
+subobject of the new parent object
+.It Fa from
+the
+.Vt CRYPTO_EX_DATA
+subobject of the original parent object
+.It Fa datap
+a pointer to a copy of the pointer to the original ex_data
+.It Fa idx
+return value of
+.Fn CRYPTO_get_ex_new_index
+that set this callback
+.It Fa argl
+the
+.Fa argl
+passed to
+.Fn CRYPTO_get_ex_new_index
+for this
+.Fa idx
+.It Fa argp
+the
+.Fa argp
+passed to
+.Fn CRYPTO_get_ex_new_index
+for this
+.Fa idx
+.El
+.Pp
+Inside
+.Fa dup_func ,
+the
+.Fa data
+pointer contained in the original parent object being copied
+can be accessed by casting and dereferencing
+.Fa datap ,
+for example:
+.Pp
+.Dl char *orig_data = *(char **)datap;
+.Pp
+If the original data is copied, for example in a manner similar to
+.Bd -literal -offset indent
+char *new_data;
+if ((new_data = strdup(orig_data)) == NULL)
+	return 0;
 .Ed
 .Pp
-Each is identified by a
+then the pointer to the newly allocated memory needs to be passed
-.Dv CRYPTO_EX_INDEX_*
+back to the caller in the
-constant defined in the
+.Fa datap
-.In openssl/crypto.h
+argument, for example:
-header file.
+.Bd -literal -offset indent
+*(char **)datap = new_data;
+return 1;
+.Ed
 .Pp
-The API described here is used by OpenSSL to manipulate exdata for
+Calling
-specific structures.
+.Fn CRYPTO_set_ex_data to idx new_data
-Since the application data can be anything at all, it is passed and
+from inside
-retrieved as a
+.Fa dup_func
-.Vt void *
+has no effect because the code calling
-type.
+.Fa dup_func
+unconditionally calls
+.Fn CRYPTO_set_ex_data to idx *datap
+after
+.Fa dup_func
+returns successfully.
+Consequently, if
+.Fa dup_func
+does not change
+.Pf * Fa datap ,
+the new parent object ends up containing a pointer to the same memory
+as the original parent object and any memory allocated in
+.Fa dup_func
+is leaked.
 .Pp
-To initialize the exdata part of a structure, call
+When multiple callback functions are called,
-.Fn CRYPTO_new_ex_data .
+they are called in increasing order of their
-.Pp
-Exdata types are identified by an index, an integer guaranteed to
-be unique within structures for the lifetime of the program.
-Applications using exdata typically call
-.Fn CRYPTO_get_ex_new_index
-at startup and store the result in a global variable, or write a
-wrapper function to provide lazy evaluation.
-The
-.Fa class_index
-should be one of the
-.Dv CRYPTO_EX_INDEX_*
-values.
-The
-.Fa argl
-and
-.Fa argp
-parameters are saved to be passed to the callbacks but are otherwise not
-used.
-In order to transparently manipulate exdata, three callbacks must be
-provided.
-The semantics of those callbacks are described below.
-.Pp
-When copying or releasing objects with exdata, the callback functions
-are called in increasing order of their index value.
-.Pp
-To set or get the exdata on an object, the appropriate type-specific
-routine must be used.
-This is because the containing structure is opaque and the
-.Vt CRYPTO_EX_DATA
-field is not accessible.
-In both APIs, the
 .Fa idx
-parameter should be an already-created index value.
+value.
 .Pp
-When setting exdata, the pointer specified with a particular index is
+.Fn CRYPTO_new_ex_data
-saved, and returned on a subsequent "get" call.
+is an internal function that initializes the
-If the application is going to release the data, it must make sure to
+.Fa ad
-set a
+subobject of the
-.Dv NULL
-value at the index, to avoid likely double-free crashes.
-.Pp
-The function
-.Fn CRYPTO_free_ex_data
-is used to free all exdata attached to a structure.
-The appropriate type-specific routine must be used.
-The
-.Fa class_index
-identifies the structure type, the
-.Fa obj
-is a pointer to the actual structure, and
-.Fa r
-is a pointer to the structure's exdata field.
-.Pp
-The callback functions are used as follows.
-.Pp
-When a structure is initially allocated (such as by
-.Xr RSA_new 3 ) ,
-then
-.Fa new_func
-is called for every defined index.
-There is no requirement that the entire parent, or containing, structure
-has been set up.
-The
-.Fa new_func
-is typically used only to allocate memory to store the
-exdata, and perhaps an "initialized" flag within that memory.
-The exdata value should be set by calling
-.Fn CRYPTO_set_ex_data .
-.Pp
-When a structure is free'd (such as by
-.Xr SSL_CTX_free 3 ) ,
-then the
-.Fa free_func
-is called for every defined index.
-Again, the state of the parent structure is not guaranteed.
-The
-.Fa free_func
-may be called with a
-.Dv NULL
-pointer.
-.Pp
-Both
-.Fa new_func
-and
-.Fa free_func
-take the same parameters.
-The
 .Fa parent
-is the pointer to the structure that contains the exdata.
+object, with the type of the parent object specified by the
-The
+.Fa class_index
-.Fa ptr
+argument.
-is the current exdata item; for
+Initialization includes calling the respective
 .Fa new_func
-this will typically be
+callbacks for all reserved
-.Dv NULL .
-The
-.Fa r
-parameter is a pointer to the exdata field of the object.
-The
 .Fa idx
-is the index and is the value returned when the callbacks were initially
+values that have such callbacks configured.
-registered via
+Despite its name,
-.Fn CRYPTO_get_ex_new_index
+.Fn CRYPTO_new_ex_data
-and can be used if the same callback handles different types of exdata.
+does not create a new object but requires that
-.Pp
+.Fa ad
-.Fa dup_func
+points to an already allocated but still uninitialized object.
-is called when a structure is being copied.
-This is only done for
-.Vt SSL
-and
-.Vt SSL_SESSION
-objects.
-The
-.Fa to
-and
-.Fa from
-parameters are pointers to the destination and source
-.Vt CRYPTO_EX_DATA
-structures, respectively.
-The
-.Fa from_d
-parameter is a pointer to the source exdata.
-When
-.Fa dup_func
-returns, the value in
-.Fa from_d
-is copied to the destination ex_data.
-If the pointer contained in
-.Fa from_d
-is not modified by the
-.Fa dup_func ,
-then both
-.Fa to
-and
-.Fa from
-will point to the same data.
-The
-.Fa idx ,
-.Fa argl
-and
-.Fa argp
-parameters are as described for the other two callbacks.
 .Pp
 .Fn CRYPTO_set_ex_data
-is used to set application specific data.
+and
-The data is supplied in the
-.Fa arg
-parameter and its precise meaning is up to the application.
-.Pp
 .Fn CRYPTO_get_ex_data
-is used to retrieve application specific data.
+behave in the same way as
-The data is returned to the application; this will be the same value as
+.Xr RSA_set_ex_data 3
-supplied to a previous
+and
-.Fn CRYPTO_set_ex_data
+.Xr RSA_get_ex_data 3 ,
-call.
+respectively, except that they do not accept a pointer
+to the parent object but instead require a pointer to the
+.Vt CRYPTO_EX_DATA
+subobject of that parent object.
+.Pp
+.Fn CRYPTO_free_ex_data
+is an internal function that frees any memory used inside the
+.Fa ad
+subobject of the
+.Fa parent
+object, with the type of the parent object specified by the
+.Fa class_index
+argument.
+This includes calling the respective
+.Fa free_func
+callbacks for all reserved
+.Fa idx
+values that have such callbacks configured.
+Despite its name,
+.Fn CRYPTO_free_ex_data
+does not free
+.Fa ad
+itself.
 .Sh RETURN VALUES
 .Fn CRYPTO_get_ex_new_index
-returns a new index or -1 on failure; the value 0 is reserved for
+returns a new index equal to or greater than 1
-the legacy "app_data" APIs.
+or \-1 if memory allocation fails.
 .Pp
+.Fn CRYPTO_EX_new
+and
+.Fn CRYPTO_EX_dup
+functions are supposed to return 1 on success or 0 on failure.
+.Pp
+.Fn CRYPTO_new_ex_data
+and
 .Fn CRYPTO_set_ex_data
-returns 1 on success or 0 on failure.
+return 1 on success or 0 if memory allocation fails.
 .Pp
 .Fn CRYPTO_get_ex_data
-returns the application data or
+returns the application specific data or
 .Dv NULL
-on failure; note that
+if the parent object that contains
-.Dv NULL
+.Fa ad
-may be a valid value.
+does not contain application specific data at the given
+.Fa idx .
+.Sh ERRORS
+After failure of
+.Fn CRYPTO_get_ex_new_index ,
+.Fn CRYPTO_new_ex_data ,
+or
+.Fn CRYPTO_set_ex_data ,
+the following diagnostic can be retrieved with
+.Xr ERR_get_error 3 ,
+.Xr ERR_GET_REASON 3 ,
+and
+.Xr ERR_reason_error_string 3 :
+.Bl -tag -width Ds
+.It Dv ERR_R_MALLOC_FAILURE Qq "malloc failure"
+Memory allocation failed.
+.El
 .Pp
-.Fa dup_func
+In a few unusual failure cases,
-should return 0 for failure and 1 for success.
+.Xr ERR_get_error 3
+may report different errors caused by
+.Xr OPENSSL_init_crypto 3
+or even none at all.
 .Pp
-On failure an error code can be obtained from
+Even though it cannot indicate failure,
+.Fn CRYPTO_free_ex_data
+may occasionally also set an error code that can be retrieved with
 .Xr ERR_get_error 3 .
+.Pp
+.Fn CRYPTO_get_ex_data
+does not distinguish success from failure.
+Consequently, after
+.Fn CRYPTO_get_ex_data
+returns
+.Dv NULL ,
+.Xr ERR_get_error 3
+returns 0 unless there is still an earlier error in the queue.
 .Sh SEE ALSO
 .Xr BIO_get_ex_new_index 3 ,
 .Xr DH_get_ex_new_index 3 ,
@@ -350,11 +410,11 @@ On failure an error code can be obtained from
 .Xr X509_STORE_get_ex_new_index 3
 .Sh HISTORY
 .Fn CRYPTO_get_ex_new_index ,
+.Fn CRYPTO_new_ex_data ,
 .Fn CRYPTO_set_ex_data ,
 .Fn CRYPTO_get_ex_data ,
-.Fn CRYPTO_free_ex_data ,
 and
-.Fn CRYPTO_new_ex_data
+.Fn CRYPTO_free_ex_data
 first appeared in SSLeay 0.9.0 and have been available since
 .Ox 2.4 .
 .Pp
@@ -364,3 +424,141 @@ and
 .Fn CRYPTO_EX_dup
 first appeared in OpenSSL 0.9.5 and have been available since
 .Ox 2.7 .
+.Sh CAVEATS
+If an program installs callback functions, the last call to
+.Fn CRYPTO_get_ex_new_index
+installing a function of a certain type for a certain
+.Fa class_index
+needs to be complete before the first object of that
+.Fa class_index
+can be created, freed, or copied, respectively.
+Otherwise, incomplete initialization or cleanup will result.
+.Pp
+At the time
+.Fa new_func
+is called, the
+.Fa parent
+object is only partially initialized,
+so trying to access any data in it is strongly discouraged.
+The
+.Fa data
+argument is typically
+.Dv NULL
+in
+.Fa new_func .
+.Pp
+At the time
+.Fa free_func
+is called, the
+.Fa parent
+object is already mostly deconstructed
+and part of its content may have been cleared and freed.
+Consequently, trying to access any data in
+.Fa parent
+is strongly discouraged.
+According to the OpenSSL API documentation, the library code calling
+.Fa free_func
+would even be permitted to pass a
+.Dv NULL
+pointer for the
+.Fa parent
+argument.
+.Pp
+.Fn CRYPTO_set_ex_data
+and
+.Fn CRYPTO_get_ex_data
+cannot reasonably be used outside the callback functions
+because no API function provides access to any pointers of the type
+.Vt CRYPTO_EX_DATA * .
+.Pp
+Inside
+.Fa new_func ,
+calling
+.Fn CRYPTO_get_ex_data
+makes no sense because it always returns
+.Dv NULL ,
+and calling
+.Fn CRYPTO_set_ex_data
+makes no sense because
+.Fa new_func
+does not have access to any meaningful
+.Fa data
+it could store, and the absence of application specific data at any given
+.Fa idx
+is already sufficiently indicated by the default return value
+.Dv NULL
+of
+.Fn CRYPTO_get_ex_data ,
+.Xr RSA_get_ex_data 3 ,
+and similar functions.
+.Pp
+Inside
+.Fa free_func ,
+calling
+.Fn CRYPTO_get_ex_data
+makes no sense because the return value is already available in
+.Fa data ,
+and calling
+.Fn CRYPTO_set_ex_data
+makes no sense because the parent object, including any ex_data
+contained in it, is already being deconstructed and will no longer
+exist by the time application code regains control.
+.Pp
+Inside
+.Fa dup_func ,
+calling
+.Fn CRYPTO_get_ex_data
+makes no sense because the return value for
+.Fa from
+is already available as
+.Pf * Fa datap ,
+and the return value for
+.Fa to
+is
+.Dv NULL .
+Calling
+.Fn CRYPTO_set_ex_data
+makes no sense because changing
+.Fa from
+would cause an undesirable side effect in this context
+and trying to change
+.Fa to
+is ineffective as explained above.
+.Pp
+Consequently, application code can never use
+.Fn CRYPTO_set_ex_data
+or
+.Fn CRYPTO_get_ex_data
+in a meaningful way.
+.Pp
+The fact that the functions documented in the present manual page
+are part of the public API might create the impression
+that application programs could add ex_data support
+to additional object types not offering it by default.
+However, for built-in object types not offering ex_support, this
+is not possible because such objects do not contain the required
+.Vt CRYPTO_EX_DATA
+subobject.
+.Pp
+It is theoretically possible to add ex_data support to an
+application-defined object type by adding a
+.Vt CRYPTO_EX_DATA
+field to the struct declaration, a call to
+.Fn CRYPTO_new_ex_data
+to the object constructor, and a call to
+.Fn CRYPTO_free_ex_data
+to the object destructor.
+The OpenSSL documentation mentions that the constant
+.Dv CRYPTO_EX_INDEX_APP
+is reserved for this very purpose.
+However, doing this would hardly be useful.
+It is much more straightforward to just add
+all the required data fields to the struct declaration itself.
+.Sh BUGS
+If
+.Fa new_func
+or
+.Fa dup_func
+fails, the failure is silently ignored by the library, potentially
+resulting in an incompletely initialized object.
+The application program cannot detect this kind of failure.

lib/libcrypto/man/PEM_read.3

@@ -1,4 +1,4 @@
-.\" $OpenBSD: PEM_read.3,v 1.14 2022/01/15 23:38:50 jsg Exp $
+.\" $OpenBSD: PEM_read.3,v 1.15 2023/09/18 15:26:46 schwarze Exp $
 .\" full merge up to: OpenSSL 83cf7abf May 29 13:07:08 2018 +0100
 .\"
 .\" This file is a derived work.
@@ -66,7 +66,7 @@
 .\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
 .\" OF THE POSSIBILITY OF SUCH DAMAGE.
 .\"
-.Dd $Mdocdate: January 15 2022 $
+.Dd $Mdocdate: September 18 2023 $
 .Dt PEM_READ 3
 .Os
 .Sh NAME
@@ -124,21 +124,21 @@
 .Fa "unsigned char *data"
 .Fa "long *len"
 .Fa "pem_password_cb *cb"
-.Fa "void *u"
+.Fa "void *userdata"
 .Fc
 .Ft int
 .Fo PEM_def_callback
 .Fa "char *password"
 .Fa "int size"
 .Fa "int verify"
-.Fa "void *u"
+.Fa "void *userdata"
 .Fc
 .Ft typedef int
 .Fo pem_password_cb
 .Fa "char *password"
 .Fa "int size"
 .Fa "int verify"
-.Fa "void *u"
+.Fa "void *userdata"
 .Fc
 .Sh DESCRIPTION
 These functions read and write PEM-encoded objects, using the PEM type
@@ -289,16 +289,22 @@ The
 buffer needs to be at least
 .Fa size
 bytes long.
+Unless
+.Fa userdata
+is
+.Dv NULL ,
 .Fn PEM_def_callback
-silently truncates the NUL-terminated byte string
+ignores the
-.Fa u
+.Fa verify
-to at most
+argument and copies the NUL-terminated byte string
-.Fa num
+.Fa userdata
-bytes and copies it into
+to
 .Fa password
-without a terminating NUL byte.
+without a terminating NUL byte, silently truncating the copy to at most
+.Fa size
+bytes.
 If
-.Fa u
+.Fa userdata
 is
 .Dv NULL ,
 .Fn PEM_def_callback
@@ -317,7 +323,7 @@ bytes are accepted from the user and copied into the byte string buffer
 A callback function
 .Fa cb
 supplied by the application may use
-.Fa u
+.Fa userdata
 for a different purpose than
 .Fn PEM_def_callback
 does, e.g., as auxiliary data to use while acquiring the password.
@@ -328,7 +334,7 @@ flag is non-zero, the user is prompted twice for the password to
 make typos less likely and it is checked that both inputs agree.
 This flag is not set by
 .Fn PEM_do_header
-nor by other read functions.
+nor by other read functions, but it is typically set by write functions.
 .Pp
 If the data is a priori known to not be encrypted, then neither
 .Fn PEM_get_EVP_CIPHER_INFO
@@ -366,7 +372,7 @@ or a negative value on failure, and
 .Fa cb
 is expected to behave in the same way.
 If
-.Fa u
+.Fa userdata
 is
 .Dv NULL ,
 .Fn PEM_def_callback

lib/libcrypto/man/RSA_get_ex_new_index.3

@@ -1,65 +1,27 @@
-.\"	$OpenBSD: RSA_get_ex_new_index.3,v 1.11 2022/03/31 17:27:17 naddy Exp $
+.\" $OpenBSD: RSA_get_ex_new_index.3,v 1.12 2023/09/18 14:49:43 schwarze Exp $
-.\"	OpenSSL 35cb565a Nov 19 15:49:30 2015 -0500
 .\"
-.\" This file was written by Ulf Moeller <ulf@openssl.org> and
+.\" Copyright (c) 2023 Ingo Schwarze <schwarze@openbsd.org>
-.\" Dr. Stephen Henson <steve@openssl.org>.
-.\" Copyright (c) 2000, 2006 The OpenSSL Project.  All rights reserved.
 .\"
-.\" Redistribution and use in source and binary forms, with or without
+.\" Permission to use, copy, modify, and distribute this software for any
-.\" modification, are permitted provided that the following conditions
+.\" purpose with or without fee is hereby granted, provided that the above
-.\" are met:
+.\" copyright notice and this permission notice appear in all copies.
 .\"
-.\" 1. Redistributions of source code must retain the above copyright
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
-.\"    notice, this list of conditions and the following disclaimer.
+.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
 .\"
-.\" 2. Redistributions in binary form must reproduce the above copyright
+.Dd $Mdocdate: September 18 2023 $
-.\"    notice, this list of conditions and the following disclaimer in
-.\"    the documentation and/or other materials provided with the
-.\"    distribution.
-.\"
-.\" 3. All advertising materials mentioning features or use of this
-.\"    software must display the following acknowledgment:
-.\"    "This product includes software developed by the OpenSSL Project
-.\"    for use in the OpenSSL Toolkit. (http://www.openssl.org/)"
-.\"
-.\" 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to
-.\"    endorse or promote products derived from this software without
-.\"    prior written permission. For written permission, please contact
-.\"    openssl-core@openssl.org.
-.\"
-.\" 5. Products derived from this software may not be called "OpenSSL"
-.\"    nor may "OpenSSL" appear in their names without prior written
-.\"    permission of the OpenSSL Project.
-.\"
-.\" 6. Redistributions of any form whatsoever must retain the following
-.\"    acknowledgment:
-.\"    "This product includes software developed by the OpenSSL Project
-.\"    for use in the OpenSSL Toolkit (http://www.openssl.org/)"
-.\"
-.\" THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY
-.\" EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
-.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
-.\" PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE OpenSSL PROJECT OR
-.\" ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
-.\" SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
-.\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
-.\" LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
-.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
-.\" STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
-.\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
-.\" OF THE POSSIBILITY OF SUCH DAMAGE.
-.\"
-.Dd $Mdocdate: March 31 2022 $
 .Dt RSA_GET_EX_NEW_INDEX 3
 .Os
 .Sh NAME
 .Nm RSA_get_ex_new_index ,
 .Nm RSA_set_ex_data ,
-.Nm RSA_get_ex_data ,
+.Nm RSA_get_ex_data
-.Nm CRYPTO_EX_new ,
+.Nd add application specific data to RSA objects
-.Nm CRYPTO_EX_dup ,
-.Nm CRYPTO_EX_free
-.Nd add application specific data to RSA structures
 .Sh SYNOPSIS
 .In openssl/rsa.h
 .Ft int
@@ -72,194 +34,157 @@
 .Fc
 .Ft int
 .Fo RSA_set_ex_data
-.Fa "RSA *r"
+.Fa "RSA *rsa"
 .Fa "int idx"
-.Fa "void *arg"
+.Fa "void *data"
 .Fc
 .Ft void *
 .Fo RSA_get_ex_data
-.Fa "RSA *r"
+.Fa "RSA *rsa"
 .Fa "int idx"
 .Fc
-.In openssl/crypto.h
-.Ft typedef int
-.Fo CRYPTO_EX_new
-.Fa "void *parent"
-.Fa "void *ptr"
-.Fa "CRYPTO_EX_DATA *ad"
-.Fa "int idx"
-.Fa "long argl"
-.Fa "void *argp"
-.Fc
-.Ft typedef void
-.Fo CRYPTO_EX_free
-.Fa "void *parent"
-.Fa "void *ptr"
-.Fa "CRYPTO_EX_DATA *ad"
-.Fa "int idx"
-.Fa "long argl"
-.Fa "void *argp"
-.Fc
-.Ft typedef int
-.Fo CRYPTO_EX_dup
-.Fa "CRYPTO_EX_DATA *to"
-.Fa "CRYPTO_EX_DATA *from"
-.Fa "void *from_d"
-.Fa "int idx"
-.Fa "long argl"
-.Fa "void *argp"
-.Fc
 .Sh DESCRIPTION
-Several OpenSSL structures can have application specific data attached
+The following parent objects can have application specific data called
-to them.
+.Dq ex_data
-This has several potential uses: it can be used to cache data associated
+attached to them:
-with a structure (for example the hash of some part of the structure) or
+.Vt BIO , DH , DSA , EC_KEY , ENGINE , RSA ,
-some additional data (for example a handle to the data in an external
+.Vt SSL , SSL_CTX , SSL_SESSION , UI , X509 , X509_STORE ,
-library).
+and
+.Vt X509_STORE_CTX .
+.\" CRYPTO_EX_INDEX_APP and CRYPTO_EX_INDEX_UI_METHOD are unused.
+The present manual page documents the related API functions taking the
+.Vt RSA
+object type as an example.
+The functions for the other object types work in exactly the same way:
+just replace the string
+.Qq RSA
+with the name of the respective object type
+throughout the rest of this manual page.
 .Pp
-Since the application data can be anything at all, it is passed and
+By default, each individual
-retrieved as a
+.Vt RSA
+object can store one
 .Vt void *
-type.
+pointing to application specific data.
-.Pp
+That specific pointer is identified by an
-The
-.Fn RSA_get_ex_new_index
-function is initially called to "register" some new application specific
-data.
-It takes three optional function pointers which are called when the
-parent structure (in this case an RSA structure) is initially created,
-when it is copied and when it is freed up.
-If any or all of these function pointer arguments are not used, they
-should be set to
-.Dv NULL .
-The precise manner in which these function pointers are called is
-described in more detail below.
-.Fn RSA_get_ex_new_index
-also takes additional long and pointer parameters which will be passed
-to the supplied functions but which otherwise have no special meaning.
-It returns an index which should be stored (typically in a static
-variable) and passed as the
 .Fa idx
-parameter in the remaining functions.
+argument of 0.
-Each successful call to
+.Pp
 .Fn RSA_get_ex_new_index
-will return an index greater than any previously returned.
+reserves the next consecutive
-This is
-important because the optional functions are called in order of
-increasing index value.
-.Pp
-.Fn RSA_set_ex_data
-is used to set application specific data.
-The data is supplied in the
-.Fa arg
-parameter and its precise meaning is up to the application.
-.Pp
-.Fn RSA_get_ex_data
-is used to retrieve application specific data.
-The data is returned to the application, which will be the same value as
-supplied to a previous
-.Fn RSA_set_ex_data
-call.
-.Pp
-.Fa new_func
-is called when a structure is initially allocated (for example with
-.Xr RSA_new 3 .
-The parent structure members will not have any meaningful values at this
-point.
-This function will typically be used to allocate any application
-specific structure.
-.Pp
-.Fa free_func
-is called when a structure is being freed up.
-The dynamic parent structure members should not be accessed because they
-will be freed up when this function is called.
-.Pp
-.Fa new_func
-and
-.Fa free_func
-take the same parameters.
-.Fa parent
-is a pointer to the parent
-.Vt RSA
-structure.
-.Fa ptr
-is the application specific data (this won't be of much use in
-.Fa new_func ) .
-.Fa ad
-is a pointer to the
-.Vt CRYPTO_EX_DATA
-structure from the parent
-.Vt RSA
-structure: the functions
-.Fn CRYPTO_get_ex_data
-and
-.Fn CRYPTO_set_ex_data
-can be called to manipulate it.
-The
 .Fa idx
-parameter is the index: this will be the same value returned by
+argument, enabling storage of one additional
-.Fn RSA_get_ex_new_index
+.Vt void *
-when the functions were initially registered.
+per
-Finally the
+.Vt RSA
+object.
+It is typically called at program startup.
+It can be called more than once if some
+.Vt RSA
+objects need to store more than two application specific pointers.
+Reserving an additional index for one parent object type, for example for
+.Vt RSA ,
+does not change the numbers of indices that can be used
+with any other parent object type.
+.Pp
+It is strongly recommended to always pass three
+.Dv NULL
+pointers for the arguments
+.Fa new_func ,
+.Fa dup_func ,
+and
+.Fa free_func .
+When following this recommendation, the arguments
 .Fa argl
 and
 .Fa argp
-parameters are the values originally passed to the same corresponding
+are ignored; conventionally, passing 0 and
-parameters when
+.Dv NULL
-.Fn RSA_get_ex_new_index
+is recommended.
-was called.
+Because using them is discouraged, the three function callback types
-.Pp
+are only documented in the low-level
-.Fa dup_func
+.Xr CRYPTO_EX_new 3
-is called when a structure is being copied.
+manual page.
-Pointers to the destination and source
-.Vt CRYPTO_EX_DATA
-structures are passed in the
-.Fa to
-and
-.Fa from
-parameters, respectively.
-The
-.Fa from_d
-parameter is passed a pointer to the source application data when the
-function is called.
-When the function returns, the value is copied to the destination:
-the application can thus modify the data pointed to by
-.Fa from_d
-and have different values in the source and destination.
-The
-.Fa idx ,
-.Fa argl ,
-and
-.Fa argp
-parameters are the same as those in
-.Fa new_func
-and
-.Fa free_func .
-.Sh RETURN VALUES
-.Fn RSA_get_ex_new_index
-returns a new index or -1 on failure.
-Note that 0 is a valid index value.
 .Pp
 .Fn RSA_set_ex_data
-returns 1 on success or 0 on failure.
+stores the
+.Fa data
+pointer as application specific data at the given
+.Fa idx
+in the given
+.Fa rsa
+object.
+The meaning of the data pointed to is up to the application.
+The caller retains ownership of the
+.Fa data
+and is responsible for freeing it when neither the caller nor the
+.Fa rsa
+object need it any longer.
+Any other pointer that was previously stored at the same
+.Fa idx
+in the same
+.Fa rsa
+object is silently overwritten.
+Passing a
+.Dv NULL
+pointer for the
+.Fa data
+argument is valid and indicates that no application specific data
+currently needs to be stored at the given
+.Fa idx .
 .Pp
 .Fn RSA_get_ex_data
-returns the application data or
+retrieves the last pointer that was stored using
-.Dv NULL
+.Fn RSA_set_ex_data
-on failure.
+at the given
-.Dv NULL
-may also be valid application data, but currently it can only fail if
-given an invalid
 .Fa idx
-parameter.
+in the given
+.Fa rsa
+object.
+.Sh RETURN VALUES
+.Fn RSA_get_ex_new_index
+returns a new index equal to or greater than 1
+or \-1 if memory allocation fails.
 .Pp
-.Fa new_func
+.Fn RSA_set_ex_data
+returns 1 on success or 0 if memory allocation fails.
+.Pp
+.Fn RSA_get_ex_data
+returns the application specific data or
+.Dv NULL
+if
+.Fa rsa
+does not contain application specific data at the given
+.Fa idx .
+.Sh ERRORS
+After failure of
+.Fn RSA_get_ex_new_index
+or
+.Fn RSA_set_ex_data ,
+the following diagnostic can be retrieved with
+.Xr ERR_get_error 3 ,
+.Xr ERR_GET_REASON 3 ,
 and
-.Fa dup_func
+.Xr ERR_reason_error_string 3 :
-should return 0 for failure and 1 for success.
+.Bl -tag -width Ds
+.It Dv ERR_R_MALLOC_FAILURE Qq "malloc failure"
+Memory allocation failed.
+.El
 .Pp
-On failure an error code can be obtained from
+In a few unusual failure cases,
-.Xr ERR_get_error 3 .
+.Xr ERR_get_error 3
+may report different errors caused by
+.Xr OPENSSL_init_crypto 3
+or even none at all.
+.Pp
+.Fn RSA_get_ex_data
+does not distinguish success from failure.
+Consequently, after
+.Fn RSA_get_ex_data
+returns
+.Dv NULL ,
+.Xr ERR_get_error 3
+returns 0 unless there is still an earlier error in the queue.
 .Sh SEE ALSO
 .Xr BIO_set_ex_data 3 ,
 .Xr CRYPTO_set_ex_data 3 ,
@@ -275,15 +200,183 @@ On failure an error code can be obtained from
 These functions first appeared in SSLeay 0.9.0
 and have been available since
 .Ox 2.4 .
-.Sh BUGS
+.Sh CAVEATS
+A relatively small minority of application programs
+attempt to change the API contract such that
+.Fn RSA_set_ex_data
+transfers ownership of the
+.Fa data
+to the
+.Fa rsa
+object.
+They do this by providing a
+.Fa free_func
+that calls
+.Xr free 3
+or higher-level
+.Fn *_free
+functions on the
+.Fa data
+and sometimes also attempt additional cleanup work as a side effect.
+.Pp
+This practice is discouraged for several reasons:
+.Bl -enum
+.It
+Due to a massive design mistake in the low-level API function
+.Xr CRYPTO_free_ex_data 3 ,
+this practice creates a possibility that
+.Xr RSA_free 3
+may fail due to memory allocation failure, consequently leaking the
+memory containing the application specific data and silently skipping
+any additional cleanup work the
+.Fa free_func
+was supposed to do, leaving the application in an undetectably
+inconsistent state.
+Arguably, leaking additional memory while trying to free some
+is most unfortunate especially when the program
+is already starved for memory.
+.It
+This practice introduces a risk of use-after-free and double-free
+bugs in case the
+.Fa rsa
+object gets destructed while a caller of
+.Fn RSA_set_ex_data
+or
+.Fn RSA_get_ex_data
+still holds a
+.Fa data
+pointer.
+No such risk exists when no
+.Fa free_func
+is installed.
+.It
+Attempting additional cleanup work in
+.Fa free_func
+is an even worse idea because
+.Fa free_func
+is unable to report any issues it might detect while doing that work.
+Instead, if any additional cleanup work is needed, it is recommended
+that the calling code takes care of that before calling
+.Xr RSA_free 3 .
+.El
+.Pp
+Even fewer application programs install a
+.Fa new_func
+that allocates memory and stores a pointer to it in the
+.Fa rsa
+object by calling
+.Xr CRYPTO_set_ex_data 3 .
+That is useless because
+.Fa new_func
+does not have access to any useful information it could store in such memory
+and because the default return value of
+.Dv NULL
+from
+.Fn RSA_get_ex_data
+is sufficient to indicate
+that no application specific data has been stored yet.
+In addition, allocating memory in
+.Fa new_func
+is also inadvisable because it introduces an additional responsibility
+for callers of
+.Fn RSA_set_ex_data
+to always call
+.Fn RSA_get_ex_data
+first, even when it is the first time the application wants to set
+application specific data in a particular
+.Fa rsa
+object, and to either modify whatever
+.Fn RSA_get_ex_data
+returns or to free it before calling
+.Fn RSA_set_ex_data .
+If that is forgotten, a memory leak results.
+.Pp
+Consequently, allocating any required memory
+is better left to the application code that calls
+.Fn RSA_set_ex_data .
+.Pp
+Installing a
 .Fa dup_func
-is currently never called.
+is often seen in combination with installing a
+.Fa free_func ,
+for obvious reasons.
+It is rarely useful because for most parent object types
+that support ex_data, including for
+.Vt RSA ,
+the library does not provide a copying API function in the first place, and
+even where copying functions exist, they tend to be fragile and error-prone.
+When a new object is needed, it is usually advisable to construct it from
+scratch whenever possible, rather than attempting a copy operation.
 .Pp
-The return value of
+On top of that, if
-.Fa new_func
+.Fa dup_func
-is ignored.
+fails, for example because of a memory allocation failure, the
+failure is neither reported nor detectable in any way, leaving the
+new parent object with incomplete data and potentially in an
+inconsistent state.
+.Sh BUGS
+If
+.Fn RSA_set_ex_data
+fails, recovery is very difficult.
+In particular, calling
+.Xr RSA_free 3
+on the parent
+.Fa rsa
+object right afterwards is likely to also hit a memory allocation
+failure, leaking all memory internally allocated by all earlier calls of
+.Fn RSA_set_ex_data
+on
+.Fa rsa
+rather than freeing that memory.
+In order to recover, the application program
+would have to free a sufficient amount of
+.Em other
+memory before calling
+.Xr RSA_free 3 ,
+which will rarely be feasible.
+Consequently, after a failure of
+.Fn RSA_set_ex_data ,
+terminating the program is likely the only reasonable option.
 .Pp
-The
+If
-.Fa new_func
+.Fn RSA_set_ex_data
-function isn't very useful because no meaningful values are present in
+is called with an
-the parent RSA structure when it is called.
+.Fa idx
+argument greater than the last one previously returned from
+.Fn RSA_get_ex_new_index ,
+it may still succeed, and though that is not guaranteed by the API,
+retrieving the
+.Fa data
+from such a bogus
+.Fa idx
+may even be possible with
+.Fn RSA_get_ex_data ,
+hiding the bug in the application program that caused passing the bogus
+.Fa idx
+to
+.Fn RSA_set_ex_data
+in the first place.
+.Pp
+If the bogus
+.Fa idx
+argument is large,
+.Fn RSA_set_ex_data
+may uselessly allocate a large amount of memory.
+Calling
+.Xr RSA_free 3
+on the parent
+.Fa rsa
+object is the only way to recover that memory.
+.Pp
+If the bogus
+.Fa idx
+argument is very large,
+.Fn RSA_set_ex_data
+is likely to cause a significant delay before eventually failing
+due to memory exhaustion.
+It is likely to return without releasing the memory already
+allocated, causing any subsequent attempt to allocate memory
+for other purposes to fail, too.
+In this situation, what was said above about failure of
+.Fn RSA_set_ex_data
+applies, so terminating the program is likely the only reasonable option.

lib/libtls/man/tls_read.3

@@ -1,4 +1,4 @@
-.\" $OpenBSD: tls_read.3,v 1.7 2019/07/09 17:58:33 jsing Exp $
+.\" $OpenBSD: tls_read.3,v 1.8 2023/09/18 17:25:15 schwarze Exp $
 .\"
 .\" Copyright (c) 2014, 2015 Ted Unangst <tedu@openbsd.org>
 .\" Copyright (c) 2015 Doug Hogan <doug@openbsd.org>
@@ -18,7 +18,7 @@
 .\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
 .\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
 .\"
-.Dd $Mdocdate: July 9 2019 $
+.Dd $Mdocdate: September 18 2023 $
 .Dt TLS_READ 3
 .Os
 .Sh NAME
@@ -26,8 +26,7 @@
 .Nm tls_write ,
 .Nm tls_handshake ,
 .Nm tls_error ,
-.Nm tls_close ,
+.Nm tls_close
-.Nm tls_reset
 .Nd use a TLS connection
 .Sh SYNOPSIS
 .In tls.h
@@ -49,8 +48,6 @@
 .Fn tls_error "struct tls *ctx"
 .Ft int
 .Fn tls_close "struct tls *ctx"
-.Ft void
-.Fn tls_reset "struct tls *ctx"
 .Sh DESCRIPTION
 .Fn tls_read
 reads
@@ -92,7 +89,6 @@ After closing the connection,
 .Fa ctx
 can be passed to
 .Xr tls_free 3 .
-.\" XXX Fn tls_reset does what?
 .Sh RETURN VALUES
 .Fn tls_read
 and
@@ -146,7 +142,7 @@ during or since the last call to
 .Fn tls_write ,
 .Fn tls_close ,
 or
-.Fn tls_reset
+.Xr tls_reset 3
 involving
 .Fa ctx ,
 or if memory allocation failed while trying to assemble the string
@@ -213,9 +209,8 @@ while (len > 0) {
 .Fn tls_read ,
 .Fn tls_write ,
 .Fn tls_error ,
-.Fn tls_close ,
 and
-.Fn tls_reset
+.Fn tls_close
 appeared in
 .Ox 5.6
 and got their final names in

share/mk/sys.mk

@@ -1,4 +1,4 @@
-#	$OpenBSD: sys.mk,v 1.93 2023/03/04 14:49:37 deraadt Exp $
+#	$OpenBSD: sys.mk,v 1.94 2023/09/18 13:16:13 deraadt Exp $
 #	$NetBSD: sys.mk,v 1.27 1996/04/10 05:47:19 mycroft Exp $
 #	@(#)sys.mk	5.11 (Berkeley) 3/13/91
 
@@ -10,7 +10,7 @@
 
 unix=		We run SecBSD.
 OSMAJOR=	1
-OSMINOR=	3
+OSMINOR=	4
 OSREV=		$(OSMAJOR).$(OSMINOR)
 OSrev=		$(OSMAJOR)$(OSMINOR)
 

sys/conf/newvers.sh

@@ -1,6 +1,6 @@
 #!/bin/sh -
 #
-#	$OpenBSD: newvers.sh,v 1.195 2023/03/25 05:49:50 deraadt Exp $
+#	$OpenBSD: newvers.sh,v 1.196 2023/09/18 13:16:13 deraadt Exp $
 #	$NetBSD: newvers.sh,v 1.17.2.1 1995/10/12 05:17:11 jtc Exp $
 #
 # Copyright (c) 1984, 1986, 1990, 1993
@@ -68,13 +68,13 @@ id=`basename "${d}"`
 #	and disable POOL_DEBUG in sys/conf/GENERIC
 
 ost="SecBSD"
-osr="1.3"
+osr="1.4"
 
 cat >vers.c <<eof
-#define STATUS "-current"		/* just after a release */
-#if 0
-#define STATUS ""			/* release */
 #define STATUS "-beta"			/* just before a release */
+#if 0
+#define STATUS "-current"		/* just after a release */
+#define STATUS ""			/* release */
 #define STATUS "-stable"		/* stable branch */
 #endif
 

sys/dev/pci/if_mcx.c

@@ -1,4 +1,4 @@
-/*	$OpenBSD: if_mcx.c,v 1.109 2023/09/07 01:43:46 jsg Exp $ */
+/*	$OpenBSD: if_mcx.c,v 1.110 2023/09/18 06:47:21 jmatthew Exp $ */
 
 /*
  * Copyright (c) 2017 David Gwynne <dlg@openbsd.org>
@@ -192,6 +192,7 @@ CTASSERT(MCX_MAX_QUEUES * MCX_WQ_DOORBELL_STRIDE <
 #define MCX_ETHER_CAP_100G_CR4		20
 #define MCX_ETHER_CAP_100G_SR4		21
 #define MCX_ETHER_CAP_100G_KR4		22
+#define MCX_ETHER_CAP_100G_LR4		23
 #define MCX_ETHER_CAP_25G_CR		27
 #define MCX_ETHER_CAP_25G_KR		28
 #define MCX_ETHER_CAP_25G_SR		29
@@ -2682,6 +2683,7 @@ static const struct mcx_eth_proto_capability mcx_eth_cap_map[] = {
 	[MCX_ETHER_CAP_100G_CR4]	= { IFM_100G_CR4,	IF_Gbps(100) },
 	[MCX_ETHER_CAP_100G_SR4]	= { IFM_100G_SR4,	IF_Gbps(100) },
 	[MCX_ETHER_CAP_100G_KR4]	= { IFM_100G_KR4,	IF_Gbps(100) },
+	[MCX_ETHER_CAP_100G_LR4]	= { IFM_100G_LR4,	IF_Gbps(100) },
 	[MCX_ETHER_CAP_25G_CR]		= { IFM_25G_CR,		IF_Gbps(25) },
 	[MCX_ETHER_CAP_25G_KR]		= { IFM_25G_KR,		IF_Gbps(25) },
 	[MCX_ETHER_CAP_25G_SR]		= { IFM_25G_SR,		IF_Gbps(25) },

sys/sys/param.h

@@ -1,4 +1,4 @@
-/*	$OpenBSD: param.h,v 1.140 2023/03/04 14:49:37 deraadt Exp $	*/
+/*	$OpenBSD: param.h,v 1.141 2023/09/18 13:18:24 deraadt Exp $	*/
 
 /*-
  * Copyright (c) 1982, 1986, 1989, 1993
@@ -41,8 +41,8 @@
 #define BSD4_3	1
 #define BSD4_4	1
 
-#define SecBSD	202308		/* SecBSD version (year & month). */
+#define SecBSD	202310		/* SecBSD version (year & month). */
-#define SecBSD1_3 1		/* SecBSD 1.3 */
+#define SecBSD1_4 1		/* SecBSD 1.4 */
 
 #include <sys/_null.h>
 

sys/sys/videoio.h

@@ -1,4 +1,4 @@
-/*	$OpenBSD: videoio.h,v 1.18 2023/08/15 08:27:30 miod Exp $	*/
+/*	$OpenBSD: videoio.h,v 1.19 2023/09/18 13:29:00 robert Exp $	*/
 /*
  *  Video for Linux Two header file
  *
@@ -1214,8 +1214,8 @@ enum v4l2_colorspace {
 	/* For RGB colorspaces such as produces by most webcams. */
 	V4L2_COLORSPACE_SRGB          = 8,
 
-	/* AdobeRGB colorspace */
+	/* opRGB colorspace */
-	V4L2_COLORSPACE_ADOBERGB      = 9,
+	V4L2_COLORSPACE_OPRGB         = 9,
 
 	/* BT.2020 colorspace, used for UHDTV. */
 	V4L2_COLORSPACE_BT2020        = 10,
@@ -1247,7 +1247,7 @@ enum v4l2_xfer_func {
 	 *
 	 * V4L2_COLORSPACE_SRGB, V4L2_COLORSPACE_JPEG: V4L2_XFER_FUNC_SRGB
 	 *
-	 * V4L2_COLORSPACE_ADOBERGB: V4L2_XFER_FUNC_ADOBERGB
+	 * V4L2_COLORSPACE_OPRGB: V4L2_XFER_FUNC_OPRGB
 	 *
 	 * V4L2_COLORSPACE_SMPTE240M: V4L2_XFER_FUNC_SMPTE240M
 	 *
@@ -1258,7 +1258,7 @@ enum v4l2_xfer_func {
 	V4L2_XFER_FUNC_DEFAULT     = 0,
 	V4L2_XFER_FUNC_709         = 1,
 	V4L2_XFER_FUNC_SRGB        = 2,
-	V4L2_XFER_FUNC_ADOBERGB    = 3,
+	V4L2_XFER_FUNC_OPRGB       = 3,
 	V4L2_XFER_FUNC_SMPTE240M   = 4,
 	V4L2_XFER_FUNC_NONE        = 5,
 	V4L2_XFER_FUNC_DCI_P3      = 6,
@@ -1270,7 +1270,7 @@ enum v4l2_xfer_func {
  * This depends on the colorspace.
  */
 #define V4L2_MAP_XFER_FUNC_DEFAULT(colsp) \
-	((colsp) == V4L2_COLORSPACE_ADOBERGB ? V4L2_XFER_FUNC_ADOBERGB : \
+	((colsp) == V4L2_COLORSPACE_OPRGB ? V4L2_XFER_FUNC_OPRGB : \
 	 ((colsp) == V4L2_COLORSPACE_SMPTE240M ? V4L2_XFER_FUNC_SMPTE240M : \
 	  ((colsp) == V4L2_COLORSPACE_DCI_P3 ? V4L2_XFER_FUNC_DCI_P3 : \
 	   ((colsp) == V4L2_COLORSPACE_RAW ? V4L2_XFER_FUNC_NONE : \
@@ -1284,7 +1284,7 @@ enum v4l2_ycbcr_encoding {
 	 *
 	 * V4L2_COLORSPACE_SMPTE170M, V4L2_COLORSPACE_470_SYSTEM_M,
 	 * V4L2_COLORSPACE_470_SYSTEM_BG, V4L2_COLORSPACE_SRGB,
-	 * V4L2_COLORSPACE_ADOBERGB and V4L2_COLORSPACE_JPEG: V4L2_YCBCR_ENC_601
+	 * V4L2_COLORSPACE_OPRGB and V4L2_COLORSPACE_JPEG: V4L2_YCBCR_ENC_601
 	 *
 	 * V4L2_COLORSPACE_REC709 and V4L2_COLORSPACE_DCI_P3: V4L2_YCBCR_ENC_709
 	 *
@@ -1353,7 +1353,7 @@ enum v4l2_quantization {
 	/*
 	 * The default for R'G'B' quantization is always full range, except
 	 * for the BT2020 colorspace. For Y'CbCr the quantization is always
-	 * limited range, except for COLORSPACE_JPEG, SRGB, ADOBERGB,
+	 * limited range, except for COLORSPACE_JPEG, SRGB, OPRGB,
 	 * XV601 or XV709: those are full range.
 	 */
 	V4L2_QUANTIZATION_DEFAULT     = 0,
@@ -1371,9 +1371,20 @@ enum v4l2_quantization {
 	 V4L2_QUANTIZATION_LIM_RANGE : \
 	 (((is_rgb_or_hsv) || (ycbcr_enc) == V4L2_YCBCR_ENC_XV601 || \
 	  (ycbcr_enc) == V4L2_YCBCR_ENC_XV709 || (colsp) == V4L2_COLORSPACE_JPEG) || \
-	  (colsp) == V4L2_COLORSPACE_ADOBERGB || (colsp) == V4L2_COLORSPACE_SRGB ? \
+	  (colsp) == V4L2_COLORSPACE_OPRGB || (colsp) == V4L2_COLORSPACE_SRGB ? \
 	 V4L2_QUANTIZATION_FULL_RANGE : V4L2_QUANTIZATION_LIM_RANGE))
 
+/*
+ * Deprecated names for opRGB colorspace (IEC 61966-2-5)
+ *
+ * WARNING: Please don't use these deprecated defines in your code, as
+ * there is a chance we have to remove them in the future.
+ */
+#ifndef _KERNEL
+#define V4L2_COLORSPACE_ADOBERGB V4L2_COLORSPACE_OPRGB
+#define V4L2_XFER_FUNC_ADOBERGB  V4L2_XFER_FUNC_OPRGB
+#endif
+
 enum v4l2_priority {
 	V4L2_PRIORITY_UNSET       = 0,  /* not initialized */
 	V4L2_PRIORITY_BACKGROUND  = 1,

usr.bin/awk/awk.1

@@ -1,4 +1,4 @@
-.\"	$OpenBSD: awk.1,v 1.65 2023/09/17 14:49:44 millert Exp $
+.\"	$OpenBSD: awk.1,v 1.66 2023/09/18 15:20:48 jmc Exp $
 .\"
 .\" Copyright (C) Lucent Technologies 1997
 .\" All Rights Reserved
@@ -22,7 +22,7 @@
 .\" ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
 .\" THIS SOFTWARE.
 .\"
-.Dd $Mdocdate: September 17 2023 $
+.Dd $Mdocdate: September 18 2023 $
 .Dt AWK 1
 .Os
 .Sh NAME
@@ -350,8 +350,8 @@ and
 .Pf / Ar re Ns /
 is a constant regular expression;
 any string (constant or variable) may be used
-as a regular expression, except in the position of an isolated regular expression
+as a regular expression,
-in a pattern.
+except in the position of an isolated regular expression in a pattern.
 .Pp
 A pattern may consist of two patterns separated by a comma;
 in this case, the action is performed for all lines

usr.bin/awk/main.c

@@ -1,4 +1,4 @@
-/*	$OpenBSD: main.c,v 1.59 2023/09/17 14:49:44 millert Exp $	*/
+/*	$OpenBSD: main.c,v 1.60 2023/09/18 15:20:48 jmc Exp $	*/
 /****************************************************************
 Copyright (C) Lucent Technologies 1997
 All Rights Reserved
@@ -144,8 +144,9 @@ int main(int argc, char *argv[])
 	}
 
 	if (argc == 1) {
-		fprintf(stderr, "usage: %s [-safe] [-V] [-d[n]] [-F fs] "
+		fprintf(stderr, "usage: %s [-safe] [-V] [-d[n]] "
-		    "[-v var=value] [prog | -f progfile]\n\tfile ...\n",
+		    "[-f fs | --csv] [-v var=value]\n"
+		    "\t   [prog | -f progfile] file ...\n",
 		    cmdname);
 		exit(1);
 	}

usr.bin/awk/run.c

@@ -1,4 +1,4 @@
-/*	$OpenBSD: run.c,v 1.75 2023/09/17 14:49:44 millert Exp $	*/
+/*	$OpenBSD: run.c,v 1.76 2023/09/18 15:16:22 deraadt Exp $	*/
 /****************************************************************
 Copyright (C) Lucent Technologies 1997
 All Rights Reserved
@@ -1350,7 +1350,7 @@ int format(char **pbuf, int *pbufsize, const char *s, Node *a)	/* printf-like co
 			int i;
 
 			if (ljust) { // print one char from t, then pad blanks
-				for (int i = 0; i < n; i++)
+				for (i = 0; i < n; i++)
 					*p++ = t[i];
 				for (i = 0; i < pad; i++) {
 					//printf(" ");
@@ -1361,7 +1361,7 @@ int format(char **pbuf, int *pbufsize, const char *s, Node *a)	/* printf-like co
 					//printf(" ");
 					*p++ = ' ';
 				}
-				for (int i = 0; i < n; i++)
+				for (i = 0; i < n; i++)
 					*p++ = t[i];
 			}
 			*p = 0;

usr.bin/signify/signify.1

@@ -1,4 +1,4 @@
-.\" $OpenBSD: signify.1,v 1.56 2022/07/20 15:12:39 deraadt Exp $
+.\" $OpenBSD: signify.1,v 1.57 2023/09/18 13:16:13 deraadt Exp $
 .\"
 .\"Copyright (c) 2013 Marc Espie <espie@openbsd.org>
 .\"Copyright (c) 2013 Ted Unangst <tedu@openbsd.org>
@@ -14,7 +14,7 @@
 .\"WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
 .\"ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
 .\"OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
-.Dd $Mdocdate: July 20 2022 $
+.Dd $Mdocdate: September 18 2023 $
 .Dt SIGNIFY 1
 .Os
 .Sh NAME
@@ -171,12 +171,12 @@ Verify a release directory containing
 .Pa SHA256.sig
 and a full set of release files:
 .Bd -literal -offset indent -compact
-$ signify -C -p /etc/signify/secbsd-13-base.pub -x SHA256.sig
+$ signify -C -p /etc/signify/secbsd-14-base.pub -x SHA256.sig
 .Ed
 .Pp
 Verify a bsd.rd before an upgrade:
 .Bd -literal -offset indent -compact
-$ signify -C -p /etc/signify/secbsd-13-base.pub -x SHA256.sig bsd.rd
+$ signify -C -p /etc/signify/secbsd-14-base.pub -x SHA256.sig bsd.rd
 .Ed
 .Pp
 Sign a gzip archive: