[openssl] OpenSSL_1_1_1-stable update

[Richard Levitte]

The branch OpenSSL_1_1_1-stable has been updated
       via  5daa28ad7041a0def79e14a0e845f407e6f04f7e (commit)
      from  cf3685393faa33496e447326069e83bd6bac6522 (commit)


- Log -----------------------------------------------------------------
commit 5daa28ad7041a0def79e14a0e845f407e6f04f7e
Author: Nan Xiao <nan at chinadtrace.org>
Date:   Tue Dec 8 12:35:31 2020 +0800

    Fix typo in OPENSSL_malloc.pod
    
    CLA: trivial
    
    Reviewed-by: Tomas Mraz <tmraz at fedoraproject.org>
    Reviewed-by: Matt Caswell <matt at openssl.org>
    (Merged from https://github.com/openssl/openssl/pull/13632)
    
    (cherry picked from commit 74c8dd1c516c7017477a205fd1f5f975cfa86722)

-----------------------------------------------------------------------

Summary of changes:
 doc/man3/OPENSSL_malloc.pod | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/man3/OPENSSL_malloc.pod b/doc/man3/OPENSSL_malloc.pod
index c60e038309..9834a8f131 100644
--- a/doc/man3/OPENSSL_malloc.pod
+++ b/doc/man3/OPENSSL_malloc.pod
@@ -104,7 +104,7 @@ before ultimately calling OPENSSL_free().
 
 OPENSSL_cleanse() fills B<ptr> of size B<len> with a string of 0's.
 Use OPENSSL_cleanse() with care if the memory is a mapping of a file.
-If the storage controller uses write compression, then its possible
+If the storage controller uses write compression, then it's possible
 that sensitive tail bytes will survive zeroization because the block of
 zeros will be compressed. If the storage controller uses wear leveling,
 then the old sensitive data will not be overwritten; rather, a block of