Restoring authorship annotation for <heretic@yandex-team.ru>. Commit 1 of 2.

1 files changed, 209 insertions, 209 deletions

diff --git a/contrib/libs/openssl/CHANGES b/contrib/libs/openssl/CHANGES
index 824f421b8d..09e381a1d6 100644
--- a/contrib/libs/openssl/CHANGES
+++ b/contrib/libs/openssl/CHANGES
@@ -7,215 +7,215 @@
  https://github.com/openssl/openssl/commits/ and pick the appropriate
  release branch.
 
- Changes between 1.1.1k and 1.1.1l [24 Aug 2021]
-
-  *) Fixed an SM2 Decryption Buffer Overflow.
-
-     In order to decrypt SM2 encrypted data an application is expected to call the
-     API function EVP_PKEY_decrypt(). Typically an application will call this
-     function twice. The first time, on entry, the "out" parameter can be NULL and,
-     on exit, the "outlen" parameter is populated with the buffer size required to
-     hold the decrypted plaintext. The application can then allocate a sufficiently
-     sized buffer and call EVP_PKEY_decrypt() again, but this time passing a non-NULL
-     value for the "out" parameter.
-
-     A bug in the implementation of the SM2 decryption code means that the
-     calculation of the buffer size required to hold the plaintext returned by the
-     first call to EVP_PKEY_decrypt() can be smaller than the actual size required by
-     the second call. This can lead to a buffer overflow when EVP_PKEY_decrypt() is
-     called by the application a second time with a buffer that is too small.
-
-     A malicious attacker who is able present SM2 content for decryption to an
-     application could cause attacker chosen data to overflow the buffer by up to a
-     maximum of 62 bytes altering the contents of other data held after the
-     buffer, possibly changing application behaviour or causing the application to
-     crash. The location of the buffer is application dependent but is typically
-     heap allocated.
-     (CVE-2021-3711)
-     [Matt Caswell]
-
-  *) Fixed various read buffer overruns processing ASN.1 strings
-
-     ASN.1 strings are represented internally within OpenSSL as an ASN1_STRING
-     structure which contains a buffer holding the string data and a field holding
-     the buffer length. This contrasts with normal C strings which are repesented as
-     a buffer for the string data which is terminated with a NUL (0) byte.
-
-     Although not a strict requirement, ASN.1 strings that are parsed using OpenSSL's
-     own "d2i" functions (and other similar parsing functions) as well as any string
-     whose value has been set with the ASN1_STRING_set() function will additionally
-     NUL terminate the byte array in the ASN1_STRING structure.
-
-     However, it is possible for applications to directly construct valid ASN1_STRING
-     structures which do not NUL terminate the byte array by directly setting the
-     "data" and "length" fields in the ASN1_STRING array. This can also happen by
-     using the ASN1_STRING_set0() function.
-
-     Numerous OpenSSL functions that print ASN.1 data have been found to assume that
-     the ASN1_STRING byte array will be NUL terminated, even though this is not
-     guaranteed for strings that have been directly constructed. Where an application
-     requests an ASN.1 structure to be printed, and where that ASN.1 structure
-     contains ASN1_STRINGs that have been directly constructed by the application
-     without NUL terminating the "data" field, then a read buffer overrun can occur.
-
-     The same thing can also occur during name constraints processing of certificates
-     (for example if a certificate has been directly constructed by the application
-     instead of loading it via the OpenSSL parsing functions, and the certificate
-     contains non NUL terminated ASN1_STRING structures). It can also occur in the
-     X509_get1_email(), X509_REQ_get1_email() and X509_get1_ocsp() functions.
-
-     If a malicious actor can cause an application to directly construct an
-     ASN1_STRING and then process it through one of the affected OpenSSL functions
-     then this issue could be hit. This might result in a crash (causing a Denial of
-     Service attack). It could also result in the disclosure of private memory
-     contents (such as private keys, or sensitive plaintext).
-     (CVE-2021-3712)
-     [Matt Caswell]
-
- Changes between 1.1.1j and 1.1.1k [25 Mar 2021]
-
-  *) Fixed a problem with verifying a certificate chain when using the
-     X509_V_FLAG_X509_STRICT flag. This flag enables additional security checks
-     of the certificates present in a certificate chain. It is not set by
-     default.
-
-     Starting from OpenSSL version 1.1.1h a check to disallow certificates in
-     the chain that have explicitly encoded elliptic curve parameters was added
-     as an additional strict check.
-
-     An error in the implementation of this check meant that the result of a
-     previous check to confirm that certificates in the chain are valid CA
-     certificates was overwritten. This effectively bypasses the check
-     that non-CA certificates must not be able to issue other certificates.
-
-     If a "purpose" has been configured then there is a subsequent opportunity
-     for checks that the certificate is a valid CA.  All of the named "purpose"
-     values implemented in libcrypto perform this check.  Therefore, where
-     a purpose is set the certificate chain will still be rejected even when the
-     strict flag has been used. A purpose is set by default in libssl client and
-     server certificate verification routines, but it can be overridden or
-     removed by an application.
-
-     In order to be affected, an application must explicitly set the
-     X509_V_FLAG_X509_STRICT verification flag and either not set a purpose
-     for the certificate verification or, in the case of TLS client or server
-     applications, override the default purpose.
-     (CVE-2021-3450)
-     [Tomáš Mráz]
-
-  *) Fixed an issue where an OpenSSL TLS server may crash if sent a maliciously
-     crafted renegotiation ClientHello message from a client. If a TLSv1.2
-     renegotiation ClientHello omits the signature_algorithms extension (where
-     it was present in the initial ClientHello), but includes a
-     signature_algorithms_cert extension then a NULL pointer dereference will
-     result, leading to a crash and a denial of service attack.
-
-     A server is only vulnerable if it has TLSv1.2 and renegotiation enabled
-     (which is the default configuration). OpenSSL TLS clients are not impacted
-     by this issue.
-     (CVE-2021-3449)
-     [Peter Kästle and Samuel Sapalski]
-
- Changes between 1.1.1i and 1.1.1j [16 Feb 2021]
-
-  *) Fixed the X509_issuer_and_serial_hash() function. It attempts to
-     create a unique hash value based on the issuer and serial number data
-     contained within an X509 certificate. However it was failing to correctly
-     handle any errors that may occur while parsing the issuer field (which might
-     occur if the issuer field is maliciously constructed). This may subsequently
-     result in a NULL pointer deref and a crash leading to a potential denial of
-     service attack.
-     (CVE-2021-23841)
-     [Matt Caswell]
-
-  *) Fixed the RSA_padding_check_SSLv23() function and the RSA_SSLV23_PADDING
-     padding mode to correctly check for rollback attacks. This is considered a
-     bug in OpenSSL 1.1.1 because it does not support SSLv2. In 1.0.2 this is
-     CVE-2021-23839.
-     [Matt Caswell]
-
-  *) Fixed the EVP_CipherUpdate, EVP_EncryptUpdate and EVP_DecryptUpdate
-     functions. Previously they could overflow the output length argument in some
-     cases where the input length is close to the maximum permissable length for
-     an integer on the platform. In such cases the return value from the function
-     call would be 1 (indicating success), but the output length value would be
-     negative. This could cause applications to behave incorrectly or crash.
-     (CVE-2021-23840)
-     [Matt Caswell]
-
-  *) Fixed SRP_Calc_client_key so that it runs in constant time. The previous
-     implementation called BN_mod_exp without setting BN_FLG_CONSTTIME. This
-     could be exploited in a side channel attack to recover the password. Since
-     the attack is local host only this is outside of the current OpenSSL
-     threat model and therefore no CVE is assigned.
-
-     Thanks to Mohammed Sabt and Daniel De Almeida Braga for reporting this
-     issue.
-     [Matt Caswell]
-
- Changes between 1.1.1h and 1.1.1i [8 Dec 2020]
-
-  *) Fixed NULL pointer deref in the GENERAL_NAME_cmp function
-     This function could crash if both GENERAL_NAMEs contain an EDIPARTYNAME.
-     If an attacker can control both items being compared  then this could lead
-     to a possible denial of service attack. OpenSSL itself uses the
-     GENERAL_NAME_cmp function for two purposes:
-     1) Comparing CRL distribution point names between an available CRL and a
-        CRL distribution point embedded in an X509 certificate
-     2) When verifying that a timestamp response token signer matches the
-        timestamp authority name (exposed via the API functions
-        TS_RESP_verify_response and TS_RESP_verify_token)
-     (CVE-2020-1971)
-     [Matt Caswell]
-
-  *) Add support for Apple Silicon M1 Macs with the darwin64-arm64-cc target.
-     [Stuart Carnie]
-
-  *) The security callback, which can be customised by application code, supports
-     the security operation SSL_SECOP_TMP_DH. This is defined to take an EVP_PKEY
-     in the "other" parameter. In most places this is what is passed. All these
-     places occur server side. However there was one client side call of this
-     security operation and it passed a DH object instead. This is incorrect
-     according to the definition of SSL_SECOP_TMP_DH, and is inconsistent with all
-     of the other locations. Therefore this client side call has been changed to
-     pass an EVP_PKEY instead.
-     [Matt Caswell]
-
-  *) In 1.1.1h, an expired trusted (root) certificate was not anymore rejected
-     when validating a certificate path. This check is restored in 1.1.1i.
-     [David von Oheimb]
-
- Changes between 1.1.1g and 1.1.1h [22 Sep 2020]
-
-  *) Certificates with explicit curve parameters are now disallowed in
-     verification chains if the X509_V_FLAG_X509_STRICT flag is used.
-     [Tomas Mraz]
-
-  *) The 'MinProtocol' and 'MaxProtocol' configuration commands now silently
-     ignore TLS protocol version bounds when configuring DTLS-based contexts, and
-     conversely, silently ignore DTLS protocol version bounds when configuring
-     TLS-based contexts.  The commands can be repeated to set bounds of both
-     types.  The same applies with the corresponding "min_protocol" and
-     "max_protocol" command-line switches, in case some application uses both TLS
-     and DTLS.
-  
-     SSL_CTX instances that are created for a fixed protocol version (e.g.
-     TLSv1_server_method()) also silently ignore version bounds.  Previously
-     attempts to apply bounds to these protocol versions would result in an
-     error.  Now only the "version-flexible" SSL_CTX instances are subject to
-     limits in configuration files in command-line options.
-     [Viktor Dukhovni]
-
-  *) Handshake now fails if Extended Master Secret extension is dropped
-     on renegotiation.
-     [Tomas Mraz]
-
-  *) Accidentally, an expired trusted (root) certificate is not anymore rejected
-     when validating a certificate path.
-     [David von Oheimb]
-
-  *) The Oracle Developer Studio compiler will start reporting deprecated APIs
-
+ Changes between 1.1.1k and 1.1.1l [24 Aug 2021] 
+ 
+  *) Fixed an SM2 Decryption Buffer Overflow. 
+ 
+     In order to decrypt SM2 encrypted data an application is expected to call the 
+     API function EVP_PKEY_decrypt(). Typically an application will call this 
+     function twice. The first time, on entry, the "out" parameter can be NULL and, 
+     on exit, the "outlen" parameter is populated with the buffer size required to 
+     hold the decrypted plaintext. The application can then allocate a sufficiently 
+     sized buffer and call EVP_PKEY_decrypt() again, but this time passing a non-NULL 
+     value for the "out" parameter. 
+ 
+     A bug in the implementation of the SM2 decryption code means that the 
+     calculation of the buffer size required to hold the plaintext returned by the 
+     first call to EVP_PKEY_decrypt() can be smaller than the actual size required by 
+     the second call. This can lead to a buffer overflow when EVP_PKEY_decrypt() is 
+     called by the application a second time with a buffer that is too small. 
+ 
+     A malicious attacker who is able present SM2 content for decryption to an 
+     application could cause attacker chosen data to overflow the buffer by up to a 
+     maximum of 62 bytes altering the contents of other data held after the 
+     buffer, possibly changing application behaviour or causing the application to 
+     crash. The location of the buffer is application dependent but is typically 
+     heap allocated. 
+     (CVE-2021-3711) 
+     [Matt Caswell] 
+ 
+  *) Fixed various read buffer overruns processing ASN.1 strings 
+ 
+     ASN.1 strings are represented internally within OpenSSL as an ASN1_STRING 
+     structure which contains a buffer holding the string data and a field holding 
+     the buffer length. This contrasts with normal C strings which are repesented as 
+     a buffer for the string data which is terminated with a NUL (0) byte. 
+ 
+     Although not a strict requirement, ASN.1 strings that are parsed using OpenSSL's 
+     own "d2i" functions (and other similar parsing functions) as well as any string 
+     whose value has been set with the ASN1_STRING_set() function will additionally 
+     NUL terminate the byte array in the ASN1_STRING structure. 
+ 
+     However, it is possible for applications to directly construct valid ASN1_STRING 
+     structures which do not NUL terminate the byte array by directly setting the 
+     "data" and "length" fields in the ASN1_STRING array. This can also happen by 
+     using the ASN1_STRING_set0() function. 
+ 
+     Numerous OpenSSL functions that print ASN.1 data have been found to assume that 
+     the ASN1_STRING byte array will be NUL terminated, even though this is not 
+     guaranteed for strings that have been directly constructed. Where an application 
+     requests an ASN.1 structure to be printed, and where that ASN.1 structure 
+     contains ASN1_STRINGs that have been directly constructed by the application 
+     without NUL terminating the "data" field, then a read buffer overrun can occur. 
+ 
+     The same thing can also occur during name constraints processing of certificates 
+     (for example if a certificate has been directly constructed by the application 
+     instead of loading it via the OpenSSL parsing functions, and the certificate 
+     contains non NUL terminated ASN1_STRING structures). It can also occur in the 
+     X509_get1_email(), X509_REQ_get1_email() and X509_get1_ocsp() functions. 
+ 
+     If a malicious actor can cause an application to directly construct an 
+     ASN1_STRING and then process it through one of the affected OpenSSL functions 
+     then this issue could be hit. This might result in a crash (causing a Denial of 
+     Service attack). It could also result in the disclosure of private memory 
+     contents (such as private keys, or sensitive plaintext). 
+     (CVE-2021-3712) 
+     [Matt Caswell] 
+ 
+ Changes between 1.1.1j and 1.1.1k [25 Mar 2021] 
+ 
+  *) Fixed a problem with verifying a certificate chain when using the 
+     X509_V_FLAG_X509_STRICT flag. This flag enables additional security checks 
+     of the certificates present in a certificate chain. It is not set by 
+     default. 
+ 
+     Starting from OpenSSL version 1.1.1h a check to disallow certificates in 
+     the chain that have explicitly encoded elliptic curve parameters was added 
+     as an additional strict check. 
+ 
+     An error in the implementation of this check meant that the result of a 
+     previous check to confirm that certificates in the chain are valid CA 
+     certificates was overwritten. This effectively bypasses the check 
+     that non-CA certificates must not be able to issue other certificates. 
+ 
+     If a "purpose" has been configured then there is a subsequent opportunity 
+     for checks that the certificate is a valid CA.  All of the named "purpose" 
+     values implemented in libcrypto perform this check.  Therefore, where 
+     a purpose is set the certificate chain will still be rejected even when the 
+     strict flag has been used. A purpose is set by default in libssl client and 
+     server certificate verification routines, but it can be overridden or 
+     removed by an application. 
+ 
+     In order to be affected, an application must explicitly set the 
+     X509_V_FLAG_X509_STRICT verification flag and either not set a purpose 
+     for the certificate verification or, in the case of TLS client or server 
+     applications, override the default purpose. 
+     (CVE-2021-3450) 
+     [Tomáš Mráz] 
+ 
+  *) Fixed an issue where an OpenSSL TLS server may crash if sent a maliciously 
+     crafted renegotiation ClientHello message from a client. If a TLSv1.2 
+     renegotiation ClientHello omits the signature_algorithms extension (where 
+     it was present in the initial ClientHello), but includes a 
+     signature_algorithms_cert extension then a NULL pointer dereference will 
+     result, leading to a crash and a denial of service attack. 
+ 
+     A server is only vulnerable if it has TLSv1.2 and renegotiation enabled 
+     (which is the default configuration). OpenSSL TLS clients are not impacted 
+     by this issue. 
+     (CVE-2021-3449) 
+     [Peter Kästle and Samuel Sapalski] 
+ 
+ Changes between 1.1.1i and 1.1.1j [16 Feb 2021] 
+ 
+  *) Fixed the X509_issuer_and_serial_hash() function. It attempts to 
+     create a unique hash value based on the issuer and serial number data 
+     contained within an X509 certificate. However it was failing to correctly 
+     handle any errors that may occur while parsing the issuer field (which might 
+     occur if the issuer field is maliciously constructed). This may subsequently 
+     result in a NULL pointer deref and a crash leading to a potential denial of 
+     service attack. 
+     (CVE-2021-23841) 
+     [Matt Caswell] 
+ 
+  *) Fixed the RSA_padding_check_SSLv23() function and the RSA_SSLV23_PADDING 
+     padding mode to correctly check for rollback attacks. This is considered a 
+     bug in OpenSSL 1.1.1 because it does not support SSLv2. In 1.0.2 this is 
+     CVE-2021-23839. 
+     [Matt Caswell] 
+ 
+  *) Fixed the EVP_CipherUpdate, EVP_EncryptUpdate and EVP_DecryptUpdate 
+     functions. Previously they could overflow the output length argument in some 
+     cases where the input length is close to the maximum permissable length for 
+     an integer on the platform. In such cases the return value from the function 
+     call would be 1 (indicating success), but the output length value would be 
+     negative. This could cause applications to behave incorrectly or crash. 
+     (CVE-2021-23840) 
+     [Matt Caswell] 
+ 
+  *) Fixed SRP_Calc_client_key so that it runs in constant time. The previous 
+     implementation called BN_mod_exp without setting BN_FLG_CONSTTIME. This 
+     could be exploited in a side channel attack to recover the password. Since 
+     the attack is local host only this is outside of the current OpenSSL 
+     threat model and therefore no CVE is assigned. 
+ 
+     Thanks to Mohammed Sabt and Daniel De Almeida Braga for reporting this 
+     issue. 
+     [Matt Caswell] 
+ 
+ Changes between 1.1.1h and 1.1.1i [8 Dec 2020] 
+ 
+  *) Fixed NULL pointer deref in the GENERAL_NAME_cmp function 
+     This function could crash if both GENERAL_NAMEs contain an EDIPARTYNAME. 
+     If an attacker can control both items being compared  then this could lead 
+     to a possible denial of service attack. OpenSSL itself uses the 
+     GENERAL_NAME_cmp function for two purposes: 
+     1) Comparing CRL distribution point names between an available CRL and a 
+        CRL distribution point embedded in an X509 certificate 
+     2) When verifying that a timestamp response token signer matches the 
+        timestamp authority name (exposed via the API functions 
+        TS_RESP_verify_response and TS_RESP_verify_token) 
+     (CVE-2020-1971) 
+     [Matt Caswell] 
+ 
+  *) Add support for Apple Silicon M1 Macs with the darwin64-arm64-cc target. 
+     [Stuart Carnie] 
+ 
+  *) The security callback, which can be customised by application code, supports 
+     the security operation SSL_SECOP_TMP_DH. This is defined to take an EVP_PKEY 
+     in the "other" parameter. In most places this is what is passed. All these 
+     places occur server side. However there was one client side call of this 
+     security operation and it passed a DH object instead. This is incorrect 
+     according to the definition of SSL_SECOP_TMP_DH, and is inconsistent with all 
+     of the other locations. Therefore this client side call has been changed to 
+     pass an EVP_PKEY instead. 
+     [Matt Caswell] 
+ 
+  *) In 1.1.1h, an expired trusted (root) certificate was not anymore rejected 
+     when validating a certificate path. This check is restored in 1.1.1i. 
+     [David von Oheimb] 
+ 
+ Changes between 1.1.1g and 1.1.1h [22 Sep 2020] 
+ 
+  *) Certificates with explicit curve parameters are now disallowed in 
+     verification chains if the X509_V_FLAG_X509_STRICT flag is used. 
+     [Tomas Mraz] 
+ 
+  *) The 'MinProtocol' and 'MaxProtocol' configuration commands now silently 
+     ignore TLS protocol version bounds when configuring DTLS-based contexts, and 
+     conversely, silently ignore DTLS protocol version bounds when configuring 
+     TLS-based contexts.  The commands can be repeated to set bounds of both 
+     types.  The same applies with the corresponding "min_protocol" and 
+     "max_protocol" command-line switches, in case some application uses both TLS 
+     and DTLS. 
+   
+     SSL_CTX instances that are created for a fixed protocol version (e.g. 
+     TLSv1_server_method()) also silently ignore version bounds.  Previously 
+     attempts to apply bounds to these protocol versions would result in an 
+     error.  Now only the "version-flexible" SSL_CTX instances are subject to 
+     limits in configuration files in command-line options. 
+     [Viktor Dukhovni] 
+ 
+  *) Handshake now fails if Extended Master Secret extension is dropped 
+     on renegotiation. 
+     [Tomas Mraz] 
+ 
+  *) Accidentally, an expired trusted (root) certificate is not anymore rejected 
+     when validating a certificate path. 
+     [David von Oheimb] 
+ 
+  *) The Oracle Developer Studio compiler will start reporting deprecated APIs 
+ 
  Changes between 1.1.1f and 1.1.1g [21 Apr 2020]
 
   *) Fixed segmentation fault in SSL_check_chain()