1 files changed, 71 insertions, 38 deletions
diff --git a/doc/man3/EVP_EncodeInit.pod b/doc/man3/EVP_EncodeInit.pod
index 03c6f4e60579..ab6b07bcdba8 100644
--- a/doc/man3/EVP_EncodeInit.pod
+++ b/doc/man3/EVP_EncodeInit.pod
@@ -5,7 +5,7 @@
 EVP_ENCODE_CTX_new, EVP_ENCODE_CTX_free, EVP_ENCODE_CTX_copy,
 EVP_ENCODE_CTX_num, EVP_EncodeInit, EVP_EncodeUpdate, EVP_EncodeFinal,
 EVP_EncodeBlock, EVP_DecodeInit, EVP_DecodeUpdate, EVP_DecodeFinal,
-EVP_DecodeBlock - EVP base 64 encode/decode routines
+EVP_DecodeBlock - EVP base64 encode/decode routines
 
 =head1 SYNOPSIS
 
@@ -29,10 +29,11 @@ EVP_DecodeBlock - EVP base 64 encode/decode routines
 
 =head1 DESCRIPTION
 
-The EVP encode routines provide a high-level interface to base 64 encoding and
-decoding. Base 64 encoding converts binary data into a printable form that uses
+The EVP encode routines provide a high-level interface to base64 encoding and
+decoding.
+Base64 encoding converts binary data into a printable form that uses
 the characters A-Z, a-z, 0-9, "+" and "/" to represent the data. For every 3
-bytes of binary data provided 4 bytes of base 64 encoded data will be produced
+bytes of binary data provided 4 bytes of base64 encoded data will be produced
 plus some occasional newlines (see below). If the input data length is not a
 multiple of 3 then the output data will be padded at the end using the "="
 character.
@@ -44,7 +45,8 @@ EVP_ENCODE_CTX_free() cleans up an encode/decode context B<ctx> and frees up the
 space allocated to it. If the argument is NULL, nothing is done.
 
 Encoding of binary data is performed in blocks of 48 input bytes (or less for
-the final block). For each 48 byte input block encoded 64 bytes of base 64 data
+the final block).
+For each 48 byte input block encoded 64 bytes of base64 data
 is output plus an additional newline character (i.e. 65 bytes in total). The
 final block (which may be less than 48 bytes) will output 4 bytes for every 3
 bytes of input. If the data length is not divisible by 3 then a full 4 bytes is
@@ -93,37 +95,62 @@ the data generated I<without> the NUL terminator is returned from the function.
 
 EVP_DecodeInit() initialises B<ctx> for the start of a new decoding operation.
 
-EVP_DecodeUpdate() decodes B<inl> characters of data found in the buffer pointed
-to by B<in>. The output is stored in the buffer B<out> and the number of bytes
-output is stored in B<*outl>. It is the caller's responsibility to ensure that
-the buffer at B<out> is sufficiently large to accommodate the output data. This
-function will attempt to decode as much data as possible in 4 byte chunks. Any
-whitespace, newline or carriage return characters are ignored. Any partial chunk
-of unprocessed data (1, 2 or 3 bytes) that remains at the end will be held in
-the B<ctx> object and processed by a subsequent call to EVP_DecodeUpdate(). If
-any illegal base 64 characters are encountered or if the base 64 padding
-character "=" is encountered in the middle of the data then the function returns
--1 to indicate an error. A return value of 0 or 1 indicates successful
-processing of the data. A return value of 0 additionally indicates that the last
-input data characters processed included the base 64 padding character "=" and
-therefore no more non-padding character data is expected to be processed. For
-every 4 valid base 64 bytes processed (ignoring whitespace, carriage returns and
-line feeds), 3 bytes of binary output data will be produced (or less at the end
-of the data where the padding character "=" has been used).
-
-EVP_DecodeFinal() must be called at the end of a decoding operation. If there
-is any unprocessed data still in B<ctx> then the input data must not have been
-a multiple of 4 and therefore an error has occurred. The function will return -1
-in this case. Otherwise the function returns 1 on success.
-
-EVP_DecodeBlock() will decode the block of B<n> characters of base 64 data
-contained in B<f> and store the result in B<t>. Any leading whitespace will be
-trimmed as will any trailing whitespace, newlines, carriage returns or EOF
-characters. After such trimming the length of the data in B<f> must be divisible
-by 4. For every 4 input bytes exactly 3 output bytes will be produced. The
-output will be padded with 0 bits if necessary to ensure that the output is
-always 3 bytes for every 4 input bytes. This function will return the length of
-the data decoded or -1 on error.
+EVP_DecodeUpdate() decodes B<inl> characters of data found in the buffer
+pointed to by B<in>.
+The output is stored in the buffer B<out> and the number of bytes output is
+stored in B<*outl>.
+It is the caller's responsibility to ensure that the buffer at B<out> is
+sufficiently large to accommodate the output data.
+This function will attempt to decode as much data as possible in chunks of up
+to 80 base64 characters at a time.
+Residual input shorter than the internal chunk size will be buffered in B<ctx>
+if its length is not a multiple of 4 (including any padding), to be processed
+in future calls to EVP_DecodeUpdate() or EVP_DecodeFinal().
+If the final chunk length is a multiple of 4, it is decoded immediately and
+not buffered.
+
+Any whitespace, newline or carriage return characters are ignored.
+For compatibility with B<PEM>, the B<-> (hyphen) character is treated as a soft
+end-of-input, subsequent bytes are not buffered, and the return value will be
+0 to indicate that the end of the base64 input has been detected.
+The soft end-of-input, if present, MUST occur after a multiple of 4 valid base64
+input bytes.
+The soft end-of-input condition is not remembered in B<ctx>, it is up to the
+caller to avoid further calls to EVP_DecodeUpdate() after a 0 or negative
+(error) return.
+
+If any invalid base64 characters are encountered or if the base64 padding
+character (B<=>) is encountered in the middle of the data then
+EVP_DecodeUpdate() returns -1 to indicate an error.
+A return value of 0 or 1 indicates successful processing of the data.
+A return value of 0 additionally indicates that the last 4 bytes processed
+ended with base64 padding (B<=>), or that the next 4 byte group starts with the
+soft end-of-input (B<->) character, and therefore no more input data is
+expected to be processed.
+
+For every 4 valid base64 bytes processed (ignoring whitespace, carriage returns
+and line feeds), 3 bytes of binary output data will be produced (except at the
+end of data terminated with one or two padding characters).
+
+EVP_DecodeFinal() should be called at the end of a decoding operation,
+but it will never decode additional data.  If there is no residual data
+it will return 1 to indicate success.  If there is residual data, its
+length is not a multiple of 4, i.e. it was not properly padded, -1 is
+is returned in that case to indicate an error.
+
+EVP_DecodeBlock() will decode the block of B<n> characters of base64 data
+contained in B<f> and store the result in B<t>.
+Any leading whitespace will be trimmed as will any trailing whitespace,
+newlines, carriage returns or EOF characters.
+Internal whitespace MUST NOT be present.
+After trimming the data in B<f> MUST consist entirely of valid base64
+characters or padding (only at the tail of the input) and its length MUST be
+divisible by 4.
+For every 4 input bytes exactly 3 output bytes will be produced.
+Padding bytes (B<=>) (even if internal) are decoded to 6 zero bits, the caller
+is responsible for taking trailing padding into account, by ignoring as many
+bytes at the tail of the returned output.
+EVP_DecodeBlock() will return the length of the data decoded or -1 on error.
 
 =head1 RETURN VALUES
 
@@ -139,7 +166,7 @@ EVP_EncodeBlock() returns the number of bytes encoded excluding the NUL
 terminator.
 
 EVP_DecodeUpdate() returns -1 on error and 0 or 1 on success. If 0 is returned
-then no more non-padding base 64 characters are expected.
+then no more non-padding base64 characters are expected.
 
 EVP_DecodeFinal() returns -1 on error or 1 on success.
 
@@ -149,9 +176,15 @@ EVP_DecodeBlock() returns the length of the data decoded or -1 on error.
 
 L<evp(7)>
 
+=head1 HISTORY
+
+The EVP_DecodeUpdate() function was fixed in OpenSSL 3.5,
+so now it produces the number of bytes specified in B<outl*>
+and does not decode padding bytes (B<=>) to 6 zero bits.
+
 =head1 COPYRIGHT
 
-Copyright 2016-2024 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2016-2025 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the Apache License 2.0 (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy