From amitshil at rocketmail.com  Thu Jul  2 14:57:53 2015
From: amitshil at rocketmail.com (Amit Shil)
Date: Thu, 2 Jul 2015 14:57:53 +0000 (UTC)
Subject: openssl version 1.0.2c compilation error for 32 bit
Message-ID: <534471932.1258481.1435849073970.JavaMail.yahoo@mail.yahoo.com>

? Hello OpenSSL,
I can compile openssl version 1.0.2c for ?64 bits successfully but getting following error while compiling for 32 bits.Could you please help me in the issue.
? ? ? ??ml /nologo /Cp /coff /c /Cx /Zi /Fotmp32dll\sha1-586.obj tmp32dll\sha1-586.asm?Assembling: tmp32dll\sha1-586.asmtmp32dll\sha1-586.asm(1427) : error A2070:invalid instruction operandstmp32dll\sha1-586.asm(1571) : error A2070:invalid instruction operandsNMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\ml.EXE"' : return code '0x1'Stop.
Please find below my Compiling Environment:

1. Compiler VS20082.Windows 7 64 Bit SP13.?ActivePerl-5.20.2.2001
Is there any specific steps I need to follow for compiling for 32 bits.
Thanks in advance!!
Best RegardsAmit?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150702/f26b1283/attachment.html>

From praveen at viptela.com  Tue Jul  7 05:45:01 2015
From: praveen at viptela.com (Praveen Kariyanahalli)
Date: Mon, 6 Jul 2015 22:45:01 -0700
Subject: Crash in EVP_PKEY_CTX_free in the client code ..
Message-ID: <CAHwXwXQ_9DaE2ZFNzbSJEV8=P_AV5kN4Dcf0=ZjxsyQoJ=MyMg@mail.gmail.com>

Version : 1.0.1m
Platform: mips64

Client code crashed while timing out the peer (Freeing the SSL ctx). We are
trying to reproduce the problem, will let you know if this happens again.
Is this a known issue?

Please let me know if you need any more info.

Thanks in Advance
-Praveen Kariyanahalli



Program terminated with signal 10, Bus error.
#0  EVP_PKEY_CTX_free (ctx=0xffffffff00000000) at pmeth_lib.c:360
360    *if (ctx->pmeth && ctx->pmeth->cleanup)*
(gdb) bt
#0  EVP_PKEY_CTX_free (ctx=0xffffffff00000000) at pmeth_lib.c:360
#1  0x000000fff5f1efd8 in EVP_MD_CTX_cleanup (ctx=0xfff4be5c20) at
digest.c:379
#2  0x000000fff5f1f470 in EVP_MD_CTX_destroy (ctx=0xfff4be5c20) at
digest.c:356
#3  0x000000fff6061708 in ssl_clear_hash_ctx (hash=0xfff4bde4e8) at
ssl_lib.c:3291
#4  0x000000fff6061a38 in SSL_free (s=0xfff4bde410) at ssl_lib.c:562
#5  0x0000000120032db0 in client_peer_delete (p_global_ctx=0x1200c9b90
<g_ctx>, p_peerdb_hash=0xfff56dea10, p_peerdb_dll=0x1200cab50 <g_ctx+4032>,
p_peer=0xfff47c6010, conn_flag=<optimized out>)
    at client_peer.c:1342
#6  0x0000000120033940 in peer_timer_expiry_cb (p_timer=<optimized out>,
peer=0xfff47c6010, p_ctx=0x1200c9b90 <g_ctx>, arg3=<optimized out>,
arg4=<optimized out>) at client_peer.c:270
#7  0x0000000120079c58 in timer_exec_pri (p_mgr=0xfff3658010,
p_pri=0xfff3658080, p_starttime=<optimized out>, msecs=<optimized out>) at
timer.c:638
#8  0x000000012007a1e0 in timer_exec (p_mgr=0xfff3658010,
pri_mask=<optimized out>, msecs=<optimized out>) at timer.c:524
#9  0x0000000120012800 in client_base_timer_cb (base_timer_fd=<optimized
out>, what=<optimized out>, p_ctx=0x1200c9b90 <g_ctx>) at client.c:5086
#10 0x000000fff611e054 in event_process_active_single_queue
(activeq=0xfff4bff0d0, base=0xfff4becc10) at
/usr/src/debug/libevent/2.0.21-r1/libevent-2.0.21-stable/event.c:1350
#11 event_process_active (base=<optimized out>) at
/usr/src/debug/libevent/2.0.21-r1/libevent-2.0.21-stable/event.c:1420
#12 event_base_loop (base=0xfff4becc10, flags=<optimized out>) at
/usr/src/debug/libevent/2.0.21-r1/libevent-2.0.21-stable/event.c:1621
#13 0x000000012002376c in client_main (p_cfg=0xffffaca440) at client.c:5835
#14 0x0000000120023ebc in main (argc=<optimized out>, argv=<optimized out>)
at client.c:6541
(gdb)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150706/209067c7/attachment.html>

From michal.bozon at gmail.com  Wed Jul  8 15:59:19 2015
From: michal.bozon at gmail.com (Michal Bozon)
Date: Wed, 8 Jul 2015 17:59:19 +0200
Subject: DOCUMENTATION: dgst.pod: duplicate -hmac
Message-ID: <CAJ-1OcJF9UhTMN9vKAbkyzLmpgczMr=TFq9K=UP0tPCxGdKNVA@mail.gmail.com>

In dgst man page (doc/apps/dgst.pod),
there's duplicate -hmac option documentation:

       -hmac arg
           set the HMAC key to "arg".
...
       -hmac key
           create a hashed MAC using "key".


Michal Bozon


From richard.puckett at ngc.com  Thu Jul  9 21:20:31 2015
From: richard.puckett at ngc.com (Puckett, Rick (IS))
Date: Thu, 9 Jul 2015 21:20:31 +0000
Subject: OpenSSL 1.0.2(c,d) hangs on Sun T3 in OPENSSL_cpuid_setup()
Message-ID: <d76680556e60419995dc1f03c40d7e6e@XCGVAG22.northgrum.com>

Request: Bug Report

Hello,

I recently compiled OpenSSL 1.0.2(c,d) for Solaris 5.10 using GCC 4.8.2 on an UltraSPARC 45 and our group tested it on several different types of other systems (V245, T4, T3, etc...) and it runs as expected on all systems except the T3 where it hangs - even for a simple call like "openssl version".  The process continues normally when sent either a SIGBUS or SIGILL.

I believe I've tracked it down to the function "OPENSSL_cpuid_setup" in the file "crypto/sparcv9cap.c" after the initial sigaction calls to set the signal handlers for SIGILL and SIGBUS and before the trailing sigaction calls to reset the handlers for SIGILL and SIGBUS.  There's a partial dtrace listing below, generated by my colleague Carolyn, with the last output lines showing the sigaction calls for SIGILL then SIGBUS (the trailing sigaction calls are in the reverse order in the code).

The "OPENSSL_cpuid_setup" function supports reading the environment variable "OPENSSL_sparcv9cap" to skip further processing and setting this variable (to anything) prevents the process from hanging, so I'm also encouraged that the issue resides within this function, but am, obviously, hesitant to rely on this as an operational solution ...

Is there any other information I can provide you and/or anything I can do on my side to investigate and resolve this.

Thank you,
- Rick


4503:   lwp_sigmask(SIG_SETMASK, 0xFFBFF827, 0x0000FFF7) = 0xFFBFFEFF [0x0000FFFF]

4503:   sigaction(SIGILL, 0xFFBFEC10, 0xFFBFECF0)       = 0

4503:       new: hand = 0xFEF4F824 mask = 0xFFBFFEFF 0x0000FFFF 0 0 flags = 0x0000

4503:       old: hand = 0x00000000 mask = 0 0 0 0 flags = 0x0000

4503:   sigaction(SIGBUS, 0xFFBFEC10, 0xFFBFED10)       = 0

4503:       new: hand = 0xFEF4F824 mask = 0xFFBFFEFF 0x0000FFFF 0 0 flags = 0x0000

4503:       old: hand = 0x00000000 mask = 0 0 0 0 flags = 0x0000


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150709/1ffe25ef/attachment.html>

From actionmystique at gmail.com  Fri Jul 10 07:56:37 2015
From: actionmystique at gmail.com (jean-christophe manciot)
Date: Fri, 10 Jul 2015 09:56:37 +0200
Subject: Compilation Bug Report
Message-ID: <CAKcFC3YfEvKgYhnPRt6udSPbC9-UTrB1wHWwtT8FV1rhCvBDJA@mail.gmail.com>

*Ubuntu Server 15.04*
*OpenSSL 1.0.2d sources from https://github.com/openssl/openssl
<https://github.com/openssl/openssl>*

root at msi-ge60
:/home/actionmystique/Program-Files/Ubuntu/OpenSSL/git-open-ssl#* ./config*
Operating system: x86_64-whatever-linux2
Configuring for linux-x86_64
Configuring for linux-x86_64
    no-deprecated   [default]  OPENSSL_NO_DEPRECATED (skip dir)
    no-ec_nistp_64_gcc_128 [default]  OPENSSL_NO_EC_NISTP_64_GCC_128 (skip
dir)
    no-gmp          [default]  OPENSSL_NO_GMP (skip dir)
    no-jpake        [experimental] OPENSSL_NO_JPAKE (skip dir)
    no-md2          [default]  OPENSSL_NO_MD2 (skip dir)
    no-rc5          [default]  OPENSSL_NO_RC5 (skip dir)
    no-rfc3779      [default]  OPENSSL_NO_RFC3779 (skip dir)
    no-sctp         [default]  OPENSSL_NO_SCTP (skip dir)
    no-shared       [default]
    no-ssl-trace    [default]  OPENSSL_NO_SSL_TRACE (skip dir)
    no-store        [experimental] OPENSSL_NO_STORE (skip dir)
    no-unit-test    [default]  OPENSSL_NO_UNIT_TEST (skip dir)
    no-zlib         [default]
    no-zlib-dynamic [default]
IsMK1MF=0
CC            =gcc
CFLAG         =-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H
-Wa,--noexecstack -m64 -DL_ENDIAN -Wall -O3 -DOPENSSL_IA32_SSE2
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM
-DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
EX_LIBS       =-ldl
CPUID_OBJ     =x86_64cpuid.o
BN_ASM        =x86_64-gcc.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o
rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o
EC_ASM        =ecp_nistz256.o ecp_nistz256-x86_64.o
DES_ENC       =des_enc.o fcrypt_b.o
AES_ENC       =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-x86_64.o
aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o
BF_ENC        =bf_enc.o
CAST_ENC      =c_enc.o
RC4_ENC       =rc4-x86_64.o rc4-md5-x86_64.o
RC5_ENC       =rc5_enc.o
MD5_OBJ_ASM   =md5-x86_64.o
SHA1_OBJ_ASM  =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o
sha1-mb-x86_64.o sha256-mb-x86_64.o
RMD160_OBJ_ASM=
CMLL_ENC      =cmll-x86_64.o cmll_misc.o
MODES_OBJ     =ghash-x86_64.o aesni-gcm-x86_64.o
ENGINES_OBJ   =e_padlock-x86_64.o
PROCESSOR     =
RANLIB        =/usr/bin/ranlib
ARFLAGS       =
PERL          =/usr/bin/perl
SIXTY_FOUR_BIT_LONG mode
DES_UNROLL used
DES_INT used
RC4_CHUNK is unsigned long

Configured for linux-x86_64.

root at msi-ge60:/home/actionmystique/Program-Files/Ubuntu/OpenSSL/git-open-ssl#
*make*
making all in crypto...
...
ake[2]: Entering directory
'/home/actionmystique/Program-Files/Ubuntu/OpenSSL/git-open-ssl/apps'
( :; LIBDEPS="${LIBDEPS:--L.. -lssl -L.. -lcrypto -ldl}";
LDCMD="${LDCMD:-gcc}"; LDFLAGS="${LDFLAGS:--DOPENSSL_THREADS -D_REENTRANT
-DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -m64 -DL_ENDIAN -Wall -O3
-DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM
-DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
-DECP_NISTZ256_ASM}"; LIBPATH=`for x in $LIBDEPS; do echo $x; done | sed -e
's/^ *-L//;t' -e d | uniq`; LIBPATH=`echo $LIBPATH | sed -e 's/ /:/g'`;
LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH ${LDCMD} ${LDFLAGS} -o
${APPNAME:=openssl} openssl.o asn1pars.o ca.o ciphers.o cms.o crl.o
crl2p7.o dgst.o dhparam.o dsa.o dsaparam.o ec.o ecparam.o enc.o engine.o
errstr.o gendsa.o genpkey.o genrsa.o nseq.o ocsp.o passwd.o pkcs12.o
pkcs7.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o prime.o rand.o req.o rsa.o
rsautl.o s_client.o s_server.o s_time.o sess_id.o smime.o speed.o spkac.o
srp.o ts.o verify.o version.o x509.o apps.o opt.o s_cb.o s_socket.o
app_rand.o ${LIBDEPS} )
speed.o: In function `speed_main':
*speed.c:(.text+0x980): undefined reference to `RC4_set_key'*
*speed.c:(.text+0x15d3): undefined reference to `RC4'*
*speed.c:(.text+0x4f80): undefined reference to `RC4_options'*
version.o: In function `version_main':
version.c:(.text+0x228): undefined reference to `RC4_options'
../libcrypto.a(e_rc4.o): In function `rc4_cipher':
e_rc4.c:(.text+0x12): undefined reference to `RC4'
../libcrypto.a(e_rc4.o): In function `rc4_init_key':
e_rc4.c:(.text+0x3b): undefined reference to `RC4_set_key'
../libcrypto.a(e_rc4_hmac_md5.o): In function `rc4_hmac_md5_cipher':
e_rc4_hmac_md5.c:(.text+0x1eb): undefined reference to `RC4'
e_rc4_hmac_md5.c:(.text+0x273): undefined reference to `RC4'
e_rc4_hmac_md5.c:(.text+0x3fd): undefined reference to `RC4'
e_rc4_hmac_md5.c:(.text+0x41e): undefined reference to `rc4_md5_enc'
e_rc4_hmac_md5.c:(.text+0x4be): undefined reference to `RC4'
e_rc4_hmac_md5.c:(.text+0x4ed): undefined reference to `rc4_md5_enc'
e_rc4_hmac_md5.c:(.text+0x54a): undefined reference to `RC4'
../libcrypto.a(e_rc4_hmac_md5.o): In function `rc4_hmac_md5_init_key':
e_rc4_hmac_md5.c:(.text+0x58f): undefined reference to `RC4_set_key'
collect2: error: ld returned 1 exit status
../Makefile.shared:164: recipe for target 'link_app.' failed
make[2]: *** [link_app.] Error 1
make[2]: Leaving directory
'/home/actionmystique/Program-Files/Ubuntu/OpenSSL/git-open-ssl/apps'
Makefile:148: recipe for target 'openssl' failed
make[1]: *** [openssl] Error 2
make[1]: Leaving directory
'/home/actionmystique/Program-Files/Ubuntu/OpenSSL/git-open-ssl/apps'
Makefile:290: recipe for target 'build_apps' failed
make: *** [build_apps] Error 1

Regards.
-- 
Jean-Christophe Manciot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150710/351c5c53/attachment.html>

From beat.bolli at isc-ejpd.admin.ch  Fri Jul 10 09:03:21 2015
From: beat.bolli at isc-ejpd.admin.ch (beat.bolli at isc-ejpd.admin.ch)
Date: Fri, 10 Jul 2015 09:03:21 +0000
Subject: [PATCH] 1.0.2d engines/e_capi: enable the SHA-2 message digests
Message-ID: <97BC6CBC9E7318469CA3C1DB0C06D05BA9DA0287@SB00110A.adb.intra.admin.ch>

Hi

This patch is needed to support the modern TLSv1.2 cipher suites
with the Windows CryptoAPI. In ticket #3366, it has been submitted
earlier as part of someone else's patch but abandoned by its author.

I have tested it with 1.0.2d, but it should apply to all branches.

Thanks,
Beat Bolli
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-engines-e_capi-enable-the-SHA-2-message-digests.patch
Type: text/x-patch
Size: 1423 bytes
Desc: 0001-engines-e_capi-enable-the-SHA-2-message-digests.patch
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150710/53c67f27/attachment-0001.bin>

From vapier at gentoo.org  Fri Jul 10 05:55:46 2015
From: vapier at gentoo.org (Mike Frysinger)
Date: Fri, 10 Jul 2015 01:55:46 -0400
Subject: [PATCH] test: use _DEFAULT_SOURCE with newer glibc versions
Message-ID: <1436507746-2476-1-git-send-email-vapier@gentoo.org>

The _BSD_SOURCE macro is replaced by the _DEFAULT_SOURCE macro.  Using
just the former with newer versions leads to a build time warning, so
make sure to use the new macro too.
---
 test/ssltest.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/test/ssltest.c b/test/ssltest.c
index 26cf96c..b36f667 100644
--- a/test/ssltest.c
+++ b/test/ssltest.c
@@ -141,6 +141,7 @@
  */
 
 /* Or gethostname won't be declared properly on Linux and GNU platforms. */
+#define _DEFAULT_SOURCE 1
 #define _BSD_SOURCE 1
 
 #include <assert.h>
-- 
2.4.4


From William.Freeman at dealertrack.com  Fri Jul 10 19:53:10 2015
From: William.Freeman at dealertrack.com (William Freeman)
Date: Fri, 10 Jul 2015 19:53:10 +0000
Subject: TTY echo flag not correctly restored after reading pass phrase
Message-ID: <0525DE5B0D26F54C8D514CE0EFA18F6FA172740C@NHPDAG005.dt.inc>

I use openssl inside an emacs shell window.  Emacs runs the tty with echo off, collects the line I'm typing (letting me edit it with emacs commands), then sends the whole line when I hit enter.  Since the line as I typed it is already on the screen, I don't need the tty to echo it, or I'll see two copies.

When openssl reads a pass phrase, it turns off echo.  That's a good thing, in general.  (Emacs recognizes the password prompt, and collects the password in a separate window, masking by echoing asterisk for each character, and sends the pass phrase to the tty when collected.)

But then, since, without, apparently, checking, it believes that it turned echo off, openssl unconditionally turns echo on.  This means my subsequent commands (or inputs) appear twice, until I run "stty -echo".

A user of a half duplex terminal (if one can still find any) would be similarly offended.

What is needed is for openssl to record the state of the echo flag before turning it off, and then, after the pass phrase is read, only turn it back on if it was on before.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150710/bb468fdf/attachment.html>

From William.Freeman at dealertrack.com  Fri Jul 10 19:39:53 2015
From: William.Freeman at dealertrack.com (William Freeman)
Date: Fri, 10 Jul 2015 19:39:53 +0000
Subject: Bug (maybe) report
Message-ID: <0525DE5B0D26F54C8D514CE0EFA18F6FA17273EE@NHPDAG005.dt.inc>

This could be a real bug, a doc bug, or I'm just not getting it.

I'm using "-config" with "openssl req" and "openssl ca" to use an alternate openssl.cnf file.  The command bombs because (being run as non-root) it can't read the default /etc/pki/tls/openssl.cnf file, since it is owned by root and mode 600 (CentOS 6.2, openssl 1.0.1e from RPM), and the command is not being run as root.

My alternate openssl.cnf file is in the current working directory, and I have tried making the -config argument each of "openssl.cnf", "./openssl.cnf", and the full absolute path to the file.  My file is mode 600 and owned by the user running the command and has mode 600.

In no case does it complain of not being able to read my file (but maybe it never gets that far).  It complains of not being able to read the default file.

So, does -config *NOT* suppress reading of the default file (the man page implies that it does)?  Have I missed an option for suppressing it?

Is this a bug, a local installation problem, or could the documentation use improvement.

Here's an example of a failing command:

(imposter)[ imposter at imposter_bill ~/imposter/non-git/CA ]
$ openssl req -config /home/imposter/imposter/non-git/CA/openssl.cnf  -newkey rsa -nodes -keyout localhost.key -out localhost.csr
140615126005576:error:0200100D:system library:fopen:Permission denied:bss_file.c:169:fopen('/etc/pki/tls/openssl.cnf','rb')
140615126005576:error:2006D002:BIO routines:BIO_new_file:system lib:bss_file.c:174:
140615126005576:error:0E078002:configuration file routines:DEF_LOAD:system lib:conf_def.c:199:
(imposter)[ imposter at imposter_bill ~/imposter/non-git/CA ]
$
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150710/8b9f1a67/attachment.html>

From noloader at gmail.com  Sat Jul 11 01:57:01 2015
From: noloader at gmail.com (Jeffrey Walton)
Date: Fri, 10 Jul 2015 21:57:01 -0400
Subject: OpenSSL and s_client behavior when default CA certificates are
 available
Message-ID: <CAH8yC8n8evDOxs_39ZqtHkVp5cACAAhxQjSUx4FGgNq2U_dg+A@mail.gmail.com>

When s_client is well configured, meaning the library user has placed
something like cacerts.cpem (http://curl.haxx.se/docs/caextract.html)
in the proper place so s_client has them available by default, then...

The following produces unexpected results:

     #!/bin/bash
    wget -O Google-CA.der --no-check-certificate
https://pki.google.com/GIAG2.crt
     openssl x509 -in Google-CA.der -inform DER -out Google-CA.pem -outform PEM

     # Intuitively, this should fail, but it does not.
     openssl s_client -connect www.microsoft.com:443 -tls1 -servername
www.microsoft.com -CAfile Google-CA.pem

The oddity above is it appears Google is certifying Microsoft sites.

**********

This also does not produce a failure:

     openssl s_client -connect www.microsoft.com:443 -tls1 -servername
www.microsoft.com -CAfile Google-CA.pem -CApath /dev/null

**********

I like the default behavior of "use a list of CAs in the absence of
-CAfile and -CApath".

But I'm not sure the strategy taken is the best one. In fact, the
strategy kind on nullifies s_client's usefulness as a debug tool.

*If* the user specifies -CAfile or -CApath, then I would expect either:

    (1) disable all default, available certificates
    (2) disable the self-signed Root CAs (so only intermediates are available)

In either case, I can use s_client as a debug tool to verify a server
configuration.


From james_r-opensslbugs at jump.org.uk  Sat Jul 11 20:34:14 2015
From: james_r-opensslbugs at jump.org.uk (James A. T. Rice)
Date: Sat, 11 Jul 2015 21:34:14 +0100 (BST)
Subject: Website ciphers.html specifies DHE-RSA-DES-CBC3-SHA, OpenSSL needs
 EDH-RSA-DES-CBC3-SHA
Message-ID: <alpine.NEB.2.00.1507112109430.22790@marvin.jump.org.uk>

>From https://www.ietf.org/rfc/rfc4346.txt
     CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x16 };

>From https://www.openssl.org/docs/apps/ciphers.html
  TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA       DHE-RSA-DES-CBC3-SHA

>From ?openssl ciphers -V | grep 0x16?
           0x00,0x16 - EDH-RSA-DES-CBC3-SHA    SSLv3 Kx=DH       Au=RSA  Enc=3DES(168) Mac=SHA1

DHE-RSA-DES-CBC3-SHA (on the website) vs
EDH-RSA-DES-CBC3-SHA (actually usuable)


Thanks
James

From jpixton at gmail.com  Sun Jul 12 11:32:38 2015
From: jpixton at gmail.com (Joseph Birr-Pixton)
Date: Sun, 12 Jul 2015 12:32:38 +0100
Subject: [PATCH] Tests for CVE-2015-1788
Message-ID: <CACaGAp=q78+tigSN2PoaupAGoKNJR5qb75aWkBknAMoWDB5v8Q@mail.gmail.com>

Hi Folks,

With the report for CVE-2015-1788 I submitted a patch to improve
testing in this area (including a regression test for the specific
issue).

As far as I can see this hasn't made its way into the repo. So here it
is again to ensure it isn't forgotten.

Cheers,
Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tests.patch
Type: application/octet-stream
Size: 482892 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150712/1ca250e1/attachment-0001.obj>

From beldmit at gmail.com  Sun Jul 12 14:47:42 2015
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Sun, 12 Jul 2015 17:47:42 +0300
Subject: Missing CRL checks in cms/smime cmdline utilities
Message-ID: <CADqLbzJzVGkfB_+HuzPxkH03qSqxRnugQO_VkmZcyTa4jtqNqA@mail.gmail.com>

Hello,

There is a missing CRL check on encrypting the messages using the
'cms/smime -encrypt' commands. Encrypting the message for the owner of a
compromised key is dangerous, so CRL check in these utilities will be
useful enough.

Thank you!

-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150712/b82f5f7a/attachment.html>

From beldmit at gmail.com  Mon Jul 13 10:05:35 2015
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Mon, 13 Jul 2015 13:05:35 +0300
Subject: Site: deprecated page
Message-ID: <CADqLbz+nYw-Tzedbs1pe0xCV7ngzAgjUYzwHL_bZLpm+PHPFAA@mail.gmail.com>

Hello!

Content of the page at https://www.openssl.org/news/state.html seems to be
deprecated.

-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150713/c52651ef/attachment.html>

From mbrannig at cisco.com  Tue Jul 14 15:29:42 2015
From: mbrannig at cisco.com (Matthew A. Brannigan)
Date: Tue, 14 Jul 2015 09:29:42 -0600
Subject: Patch to fix issue with HMAC_init_ex in 1.0.1
Message-ID: <55A52AE6.5030809@cisco.com>

During testing with strongswan 5.1.3, an issue with openssl 1.0.1o was
found.  Openssl 1.0.1o has added code in HMAC_Init_ex() to detect
changing of message digest function. But that does not work when the
context has just been initialized with HMAC_CTX_init(). In this case,
ctx->md will be NULL after initialization and will not equal to the
function returned by EVP_sha256() and passed to HMAC_Init_ex().

Enclosed is a patch and test case.
-------------- next part --------------
diff -urN openssl-1.0.1p.orig/crypto/hmac/hmac.c openssl-1.0.1p/crypto/hmac/hmac.c
--- openssl-1.0.1p.orig/crypto/hmac/hmac.c	2015-07-09 08:21:24.000000000 -0400
+++ openssl-1.0.1p/crypto/hmac/hmac.c	2015-07-14 11:15:21.754743504 -0400
@@ -88,7 +88,7 @@
     }
 #endif
     /* If we are changing MD then we must have a key */
-    if (md != NULL && md != ctx->md && (key == NULL || len < 0))
+    if (md != NULL && md != ctx->md && ctx->md != NULL && (key == NULL || len < 0))
         return 0;
 
     if (md != NULL) {
-------------- next part --------------
#include <openssl/engine.h>
#include <openssl/hmac.h>
#include <openssl/evp.h>
#include <stdio.h>

int main(int argc, char ** argv)
{
    HMAC_CTX ctx;
    int ret;

    HMAC_CTX_init(&ctx);
    ret = HMAC_Init_ex(&ctx, NULL, 0, EVP_sha256(), NULL);

    if (ret == 0)
    {
        printf("Failed\n");
        return 1;
    }

    printf("Success\n");

    return 0;
}


From mahendersingh2706 at gmail.com  Tue Jul 14 17:56:28 2015
From: mahendersingh2706 at gmail.com (Mahender Singh)
Date: Tue, 14 Jul 2015 23:26:28 +0530
Subject: Vulnerability Report
Message-ID: <CAMsjTQArJxy2E4_KSQW1iBAFYRMa58SP7ZOD-va4DKSiuFzhjA@mail.gmail.com>

Dear Sir / Madam ,


                This is* Mahender Singh* *Security Researcher* from *India*,
i have found bug that i would like to share with your security team, this
bug is related server file discloser, i  have explain deeply as follows,

*Vulnerability* : GIT Config

*Vulnerable link *: www.openssl.org

*Payload =* .git/config

*then final url *= http://www.openssl.org/.git/config


I have Attached POC as follow


*Refer URL*

http://blogs.msdn.com/b/bharry/archive/2014/12/18/git-vulnerability-with-git-config.aspx

https://blog.netspi.com/dumping-git-data-from-misconfigured-web-servers/

https://www.owasp.org/index.php/Top_10_2013-A5


I have given enough details of Vulnerability if you need anything else you
can contact me at my mail id mahendersingh2706 at gmail
<hackdeep2015 at gmail.com>.com

Hope you will patch this as soon as.

Thank You

Regarding
*Mahender Singh*
*Cyber Security Researcher*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150714/69234a11/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: git_config.png
Type: image/png
Size: 28255 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150714/69234a11/attachment-0001.png>

From pholder at gmail.com  Tue Jul 14 21:26:58 2015
From: pholder at gmail.com (P Holder)
Date: Tue, 14 Jul 2015 17:26:58 -0400
Subject: OpenSSL command line tool feature request
Message-ID: <CAG7BDeaPLm=2v8ZortcD63qS60f87Y-5WVh0FyhSyQ1DS4+OyA@mail.gmail.com>

Right now, if I do add randomness from a file I get, for example:

OpenSSL> rand -rand r:\temp\randgen.bytes 0
Loading 'screen' into random state - done
10 semi-random bytes loaded

I'd like the option to remove the step the causes "Loading 'screen'
into random state - done" if I supply my own file.  I have a true
random number generating HSM and I don't need the screen input and in
the case I am have, I can't guarantee the "quality" of the screen, so
want it excluded.

Thanks for any consideration.

Paul


From maxim.gorbachyov at gmail.com  Wed Jul 15 10:21:39 2015
From: maxim.gorbachyov at gmail.com (Maxim Gorbachyov)
Date: Wed, 15 Jul 2015 13:21:39 +0300
Subject: broken cross-compilation for BSD-x86_64
Message-ID: <CAJLCkXO50XmML1+6nh7e-OOV5=bMqCMQr8dbK1+LOXifXFcccA@mail.gmail.com>

Hello.

I'm trying to cross-build OpenSSL 1.0.2d for BSD-x86_64 (on linux host):

./Configure -no-idea -no-mdc2 -no-rc5 -D_GNU_SOURCE
--cross-compile-prefix=x86_64-pc-freebsd8- BSD-x86_64 -no-asm && make
depend
...
Configured for BSD-x86_64.
making depend in crypto...
make[1]: Entering directory '.../openssl-1.0.2d/crypto'
../util/domd: 30: ../util/domd: makedepend: not found

Indeed, configured for BSD-x86_64 openssl-1.0.2d/Makefile wants
something strange:
MAKEDEPPROG=makedepend

For example, same thing when configured for BSD-x86:
MAKEDEPPROG= $(CROSS_COMPILE)gcc

I think the issue was introduced by this commit:
===
commit f877da9cedb95df94105d7292f8e0963175e58dc
Author: Ben Laurie <ben at links.org>
Date:   Fri May 1 15:53:46 2015 +0100

    Use cc instead of gcc so either clang or gcc is used as
appropriate. Add clang
    flags needed to keep it happy.

    Reviewed-by: Richard Levitte <levitte at openssl.org>
===

Among other changes it has:

-"BSD-x86_64",  "gcc:-DL_ENDIAN -O3
-Wall::${BSDthreads}:::SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT
DES_UNROLL:${x86_64_asm}:elf:dlfcn:bsd-gcc-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
+"BSD-x86_64",  "cc:-DL_ENDIAN -O3
-Wall::${BSDthreads}:::SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT
DES_UNROLL:${x86_64_asm}:elf:dlfcn:bsd-gcc-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",

But Configure uses that "gcc" to get MAKEDEPPROG:
s/^MAKEDEPPROG=.*$/MAKEDEPPROG= \$\(CROSS_COMPILE\)$cc/ if $cc eq "gcc";

I'm not sure what is the best way to fix it. I'm able to cross-build
for BSD-x86_64 with this line in Configure:
"BSD-x86_64",  "gcc:-DL_ENDIAN -O3
-Wall::${BSDthreads}:::SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT
DES_UNROLL:${x86_64_asm}:elf:dlfcn:bsd-gcc-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
, but "cc" is there for a reason, I guess.

Could you please suggest how to fix it?


From Rick_Andrews at symantec.com  Wed Jul 15 23:35:34 2015
From: Rick_Andrews at symantec.com (Rick Andrews)
Date: Wed, 15 Jul 2015 16:35:34 -0700
Subject: Enhancement request: Add support for RFC 5816
Message-ID: <544B0DD62A64C1448B2DA253C011414619231811EB@TUS1XCHEVSPIN33.SYMC.SYMANTEC.COM>

The OpenSSL time stamp code (crypto/ts_asn1.c) only supports RFC 3161. There
is no support for any of the data structures such as signingcertificateV2 or
ESSCertIDv2 defined in RFC 5816. Please consider adding support for the
newer RFC. Thanks,

-Rick Andrews
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150715/1087ac09/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5749 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150715/1087ac09/attachment.bin>

From beldmit at gmail.com  Thu Jul 16 19:46:36 2015
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Thu, 16 Jul 2015 22:46:36 +0300
Subject: Printing out X.509 extensions
Message-ID: <CADqLbzKXpanSUNLhvVeAUifkWyb1WFPX-3FCforry1DAZK0OBQ@mail.gmail.com>

Hello,

there is a problem to print out X.509 extensions correctly using the
cmdline utility. There is no way to pass the flags specified by the
"-nameopt" cmdline option to printing callbacks so non-ASCII strings are
always print like "\xD0\x97\xD0\xB0\xD1...".

It concerns, for example, X509_NAME structs in both X509v3 Subject
Alternative Name and X509v3 Authority Key Identifier fields.

Thank you!

-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150716/162a8d20/attachment.html>

From qza22c5l at gmail.com  Fri Jul 17 12:59:54 2015
From: qza22c5l at gmail.com (Nicholas Cooper)
Date: Fri, 17 Jul 2015 20:59:54 +0800
Subject: typos in openssl-1.0.2d
Message-ID: <55A8FC4A.50905@gmail.com>

The patch is for openssl-1.0.2d.tar.gz of which file the MD5 is
38dd619b2e77cbac69b99f52a053d25a
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openssl-1.0.2d.diff
Type: text/x-patch
Size: 2328 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150717/5b25d1c5/attachment-0001.bin>

From sdaoden at yandex.com  Tue Jul 21 14:23:23 2015
From: sdaoden at yandex.com (Steffen Nurpmeso)
Date: Tue, 21 Jul 2015 16:23:23 +0200
Subject: Bug: PKCS_final.7 not installed
Message-ID: <20150721142323.sXk4lrxX-lEA%sdaoden@yandex.com>

And on [1] (at least) the link "Please see the list of new or open
bugs and requests." leads to nowhere.
Ciao,

  [1] http://openssl.org/support/rt.html

--steffen


From cuoq at trust-in-soft.com  Wed Jul 22 09:37:23 2015
From: cuoq at trust-in-soft.com (Pascal Cuoq)
Date: Wed, 22 Jul 2015 09:37:23 +0000
Subject: Standard mem* functions called with length 0 and invalid pointer
 arguments
Message-ID: <F5009FDB-C1E4-4B10-A0D9-BF081B3FB07F@trust-in-soft.com>

Recently, GCC began to assume for optimization purposes that p and q are non-null pointers when
memcpy(p, q, n); is invoked.

This means that the if is eliminated completely when compiling the following sequence of instructions:

memcpy(p, q, n);
if (!p) printf("good\n");

And this causes a problem for any programmer that would expect ?good? to be printed by the
following program:

#include <string.h>

void f(void *p, void *q, size_t n) {
  memcpy(p, q, n);
  if (!p) printf("good\n");
}

int main(void) {
  f(0, 0, 0);
}

The clauses in the standard that allow GCC to ?optimize? the program in this way are, in C11, 7.24.1:2 and 7.1.4.

Clause 7.24.1:2 says:

?Where an argument declared as size_t n specifies the length of the array for a function,
n can have the value zero on a call to that function. Unless explicitly stated otherwise in the description
of a particular function in this subclause, pointer arguments on such a call shall still have valid values,
as described in 7.1.4?

Clause 7.1.4 also allows compilers to assume that p and q are not pointers ?one past? the end of an object:

http://stackoverflow.com/questions/25390577/is-memcpya-1-b-1-0-defined-in-c11

Since you can expect GCC developers to take as much responsibility for the vulnerabilities
introduced in previously working code when they add the optimization of assuming that p and q
are not pointers ?one past? than they did when they added the optimization of assuming that p
and q are not null (i.e. none at all), it would be prudent never to call any standard function
with pointers ?one past?, even when these are functions that also take a length and the length
is always 0 in these cases.

OpenSSL's bignum implementation contains two invocations of standard functions that
fail this property:

https://github.com/openssl/openssl/blob/b39fc560612984e65ec30d7f37487303bf514fb3/crypto/bn/bn_add.c#L225
https://github.com/openssl/openssl/blob/b39fc560612984e65ec30d7f37487303bf514fb3/crypto/bn/bn_mont.c#L199

These two lines are actually reached with pointers ?one past? and sizes of 0 during real executions.

The prudent thing to do would be to guard these lines so that the standard function is not called
with a pointer ?one past?, which can be done as simply as:

if (max - r->top) memset(&rp[r->top], 0, sizeof(*rp) * (max - r->top));

if (dif) memcpy(rp, ap, sizeof(*rp) * dif);

From david.woodhouse at intel.com  Wed Jul 22 12:57:40 2015
From: david.woodhouse at intel.com (Woodhouse, David)
Date: Wed, 22 Jul 2015 12:57:40 +0000
Subject: [RFC][PATCH] Allow certificate time checks to be disabled
Message-ID: <1437569859.3905.87.camel@intel.com>

There are various circumstances in which it makes no sense to be
checking the start and end times of a certificate's validity.

When validating OS kernel drivers, or indeed when validating the OS
kernel itself when the firmware loads it, we *really* don't want to
have a built-in obsolescence date after which the system will no longer
function. That would be a bad thing even if we *could* reliably trust
the system's real time clock at this stage in the boot sequence.

This patch gives us a way to disable the time checks entirely, by using
X509_VERIFY_PARAM_set_time() with a time of -1.

There is a slight risk here ? if anyone was genuinely using the value
of -1 to check if a certificate chain was indeed valid in the last
second of 1969. I judge that risk to be negligible. And it certainly
shouldn't be externally triggerable ? if an attacker could influence
the value passed to X509_VERIFY_PARAM_set_time() then all bets were off
w.r.t. time-based checks anyway.

If there are serious concerns, however, I can provide an alternative
patch which adds an X509_V_FLAG_NO_CHECK_TIME flag for this purpose
instead.

I'm happy with anything except the existing version in the UEFI source
tree that everyone is shipping, which just disables the time check if
OPENSSL_SYS_UEFI is set?. That one I *don't* like.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation

? http://git.infradead.org/users/dwmw2/openssl.git/commitdiff/2fb12afc2ceb
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Allow-certificate-time-checks-to-be-disabled.patch
Type: text/x-patch
Size: 2331 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150722/4378148f/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3437 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150722/4378148f/attachment-0001.bin>

From dwmw2 at infradead.org  Wed Jul 22 16:30:29 2015
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 22 Jul 2015 17:30:29 +0100
Subject: [PATCH] Introduce OPENSSL_SYS_UEFI for rand configuration
Message-ID: <1437582629.3905.125.camel@infradead.org>

For secure boot (and other services), OpenSSL is built as part of the
Tianocore UEFI firmware. It does not use the normal makefiles; it has
its own build system and provides its own #defines and list of files to
be built:
https://github.com/tianocore/edk2/blob/master/CryptoPkg/Library/Openssl
Lib/OpensslLib.inf

I'm open to suggestions on how best to generate opensslconf.h for it,
and keep that OpensslLib.inf up to date. To start with, though, this
simply gets the right version of RAND_poll() for OPENSSL_SYS_UEFI.

(I'm not even going to think about the asm bits yet.)

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-UEFI-flag-for-rand-build.patch
Type: text/x-patch
Size: 1333 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150722/daf4fd31/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5691 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150722/daf4fd31/attachment-0003.bin>

From plynch at mail.nih.gov  Wed Jul 22 19:22:20 2015
From: plynch at mail.nih.gov (Lynch, Paul (NIH/NLM/LHC) [E])
Date: Wed, 22 Jul 2015 19:22:20 +0000
Subject: Bug:  !RSA does not exclude aRSA
Message-ID: <A331FF5F62F2E94FBBC8826B56AA45DE3FC58341@msgb04.nih.gov>

The ciphers documentation page (https://www.openssl.org/docs/apps/ciphers.html) says:

"kRSA, aRSA, RSA
   cipher suites using RSA key exchange, authentication or either respectively."

That sounds like "RSA" should be a superset of kRSA and aRSA, but actually aRSA includes cipher suites not in "RSA", as can be seen from:

(bash)$ diff <(openssl ciphers 'RSA' | sed -e 's/:/\n/g') <(openssl ciphers 'aRSA'| sed -e 's/:/\n/g')

As a consequence, !RSA allows some aRSA ciphers.

I don't know whether this is a documentation problem or a software problem.

I am using "OpenSSL 1.0.1e-fips 11 Feb 2013" on "Red Hat Enterprise Linux Workstation release 6.6 (Santiago)".

Thanks,

--Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150722/a65b3c90/attachment.html>

From sdaoden at yandex.com  Thu Jul 23 11:40:58 2015
From: sdaoden at yandex.com (Steffen Nurpmeso)
Date: Thu, 23 Jul 2015 13:40:58 +0200
Subject: Enhancement suggestion: extend x509(1) with
 -key-fingerprint
Message-ID: <20150723114058.Sr1UatyDR6fU%sdaoden@yandex.com>

Hello,

for certificates which get renewed -- mine do twice a year, for
example -- the fingerprint changes

  ?0[tmp]$ openssl x509 -fingerprint -noout < cert.old
  SHA1 Fingerprint=00:10:F0:2C:EA:50:1F:11:FE:8D:CC:A0:A9:40:91:A2:D0:4D:65:4E
  ?0[tmp]$ openssl x509 -fingerprint -noout < cert.crt
  SHA1 Fingerprint=77:E3:10:F0:3B:D9:1E:1F:29:B0:83:74:50:29:67:E4:04:B2:53:B1

Of course if you have the CA's certificate you can verify the
validity of the above, but if i change the CA you need to get that
one etc.  I may also change to a self-signed CA.  Imagine i need
to renew my certificate, switch the CA and use sk_X509_push() to
include the new root certificate that signed my updated
certificate with my .p7s.  The receiver will (possibly) get
a verification failure, but if there would be an easy possibility
to verify the fingerprint of the public key he or she would be
able to verify that only the certificate changed, not the key:

  ?0[tmp]$ openssl x509 -pubkey -noout < cert.old|
  > openssl rsa -pubin -outform der|
  > openssl sha1
  writing RSA key
  (stdin)= 0e349338a3baf9f1edf176dd02151939a31ebb79
  ?0[tmp]$ openssl x509 -pubkey -noout < cert.crt|
  > openssl rsa -pubin -outform der|
  > openssl sha1
  writing RSA key
  (stdin)= 0e349338a3baf9f1edf176dd02151939a31ebb79

In the end the key is an authority by itself, no?

--steffen


From dwmw2 at infradead.org  Thu Jul 23 12:45:10 2015
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 23 Jul 2015 13:45:10 +0100
Subject: [PATCH] Reduce stack usage in PKCS7_verify()
Message-ID: <1437655510.27621.29.camel@infradead.org>

From: "Long, Qin" <qin.long at intel.com>

Some environments, such as 32-bit UEFI, have strict limits on stack size.
Using a 4KiB buffer on the stack for reading from p7bio is somewhat
excessive, so allocate it on the heap instead.
---
Alternatively, we could leave it on the stack and reduce it to 256
bytes or something like that. It's not as if performance is really an
issue here if we do that, right?

 crypto/pkcs7/pk7_smime.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/crypto/pkcs7/pk7_smime.c b/crypto/pkcs7/pk7_smime.c
index e52e746..077b06d 100644
--- a/crypto/pkcs7/pk7_smime.c
+++ b/crypto/pkcs7/pk7_smime.c
@@ -253,7 +253,8 @@ int PKCS7_verify(PKCS7 *p7, STACK_OF(X509) *certs, X509_STORE *store,
     STACK_OF(PKCS7_SIGNER_INFO) *sinfos;
     PKCS7_SIGNER_INFO *si;
     X509_STORE_CTX cert_ctx;
-    char buf[4096];
+    char *buf = NULL;
+    int bufsiz;
     int i, j = 0, k, ret = 0;
     BIO *p7bio;
     BIO *tmpin, *tmpout;
@@ -365,9 +366,14 @@ int PKCS7_verify(PKCS7 *p7, STACK_OF(X509) *certs, X509_STORE *store,
     } else
         tmpout = out;
 
+    bufsiz = 4096;
+    buf = OPENSSL_malloc(bufsiz);
+    if (buf == NULL) {
+        goto err;
+    }
     /* We now have to 'read' from p7bio to calculate digests etc. */
     for (;;) {
-        i = BIO_read(p7bio, buf, sizeof(buf));
+        i = BIO_read(p7bio, buf, bufsiz);
         if (i <= 0)
             break;
         if (tmpout)
@@ -407,6 +413,10 @@ int PKCS7_verify(PKCS7 *p7, STACK_OF(X509) *certs, X509_STORE *store,
 
     sk_X509_free(signers);
 
+    if (buf != NULL) {
+      OPENSSL_free(buf);
+    }
+
     return ret;
 }
 
-- 
2.4.3

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5691 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150723/6c3a013b/attachment.bin>

From murphy.zhao at qq.com  Fri Jul 24 06:45:50 2015
From: murphy.zhao at qq.com (=?ISO-8859-1?B?aWNl?=)
Date: Fri, 24 Jul 2015 14:45:50 +0800
Subject: SSL_accept() crashed in SSLv3 processing
Message-ID: <tencent_4FA4FF0B4D0A911110FE55E9@qq.com>

Hi,

in my process, I expecienced too many SSL_accept() crashed when processing SSLv3 client request.
(gdb) info stack 
#0  0xb76e3f7a in SSL_accept () from /lib/libssl.so.1.0.0
#1  0x00000000 in ?? ()
#2  0xb76e3f56 in SSL_accept () from /lib/libssl.so.1.0.0
#3  0xbfc2ff23 in ?? ()
#4  0x08049d57 in do_ssl_accept (client_cb=0x9f79790) at rhttpd.cc:823

$12 = {version = 768, type = 8192, method = 0x0, rbio = 0x9f799e0, wbio = 0x9f799e0, bbio = 0x0, rwstate = 1, in_handshake = 0, handshake_func = 0xb76d5d00 <ssl23_accept>, server = 1, new_session = 0, quiet_shutdown = 0, shutdown = 0, state = 8720, rstate = 240, 
  init_buf = 0x9f79a28, init_msg = 0x0, init_num = 0, init_off = 0, packet = 0x9fa3e30 "\026\003", packet_length = 11, s2 = 0x0, s3 = 0x9f9e4a8, d1 = 0x0, read_ahead = 0, msg_callback = 0, msg_callback_arg = 0x0, hit = 0, param = 0x9f78288, cipher_list = 0x0, 
  cipher_list_by_id = 0x0, mac_flags = 0, enc_read_ctx = 0x0, read_hash = 0x0, expand = 0x0, enc_write_ctx = 0x0, write_hash = 0x0, compress = 0x0, cert = 0x9f79948, sid_ctx_length = 0, sid_ctx = '\0' <repeats 31 times>, session = 0x0, generate_session_id = 0, 
  verify_mode = 0, verify_callback = 0, info_callback = 0, error = 0, error_code = 0, psk_client_callback = 0, psk_server_callback = 0, ctx = 0x9f77e60, debug = 0, verify_result = 0, ex_data = {sk = 0x0, dummy = 0}, client_CA = 0x0, references = 1, 
  options = 2147486719, mode = 0, max_cert_list = 102400, first_packet = 0, client_version = 771, max_send_fragment = 16384, tlsext_debug_cb = 0, tlsext_debug_arg = 0x0, tlsext_hostname = 0x0, servername_done = 0, tlsext_status_type = -1, tlsext_status_expected = 0, 
  tlsext_ocsp_ids = 0x0, tlsext_ocsp_exts = 0x0, tlsext_ocsp_resp = 0x0, tlsext_ocsp_resplen = -1, tlsext_ticket_expected = 0, tlsext_ecpointformatlist_length = 0, tlsext_ecpointformatlist = 0x0, tlsext_ellipticcurvelist_length = 0, tlsext_ellipticcurvelist = 0x0, 
  tlsext_opaque_prf_input = 0x0, tlsext_opaque_prf_input_len = 0, tlsext_session_ticket = 0x0, tls_session_ticket_ext_cb = 0, tls_session_ticket_ext_cb_arg = 0x0, tls_session_secret_cb = 0, tls_session_secret_cb_arg = 0x0, initial_ctx = 0x9f77e60, 
  next_proto_negotiated = 0x0, next_proto_negotiated_len = 0 '\0', srtp_profiles = 0x0, srtp_profile = 0x0, tlsext_heartbeat = 0, tlsext_hb_pending = 0, tlsext_hb_seq = 153, renegotiate = 167221624, srp_ctx = {SRP_cb_arg = 0x0, TLS_ext_srp_username_callback = 0, 
    SRP_verify_param_callback = 0, SRP_give_srp_client_pwd_callback = 0, login = 0x0, N = 0x0, g = 0x0, s = 0x0, B = 0x0, A = 0x0, a = 0x0, b = 0x9f786d0, v = 0x9f7b2f8, info = 0xb76b52e8 "@", strength = 0, srp_Mask = 0}}

Somehow the method became 0x0 when processing SSLv3. for now all crashes occured with SSLv3 client requests. We have to disable SSLv2 and SSLv3 support in the process. 
Could anyone help check what happened to make the "method" become 0x0 when processing SSLv3?

Thanks,
Murphy.zhao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150724/30a15248/attachment-0001.html>

From mahi22.k at gmail.com  Mon Jul 27 16:55:58 2015
From: mahi22.k at gmail.com (mahendar katkuri)
Date: Mon, 27 Jul 2015 18:55:58 +0200
Subject: BUG:Double free in int_thread_del_item in crypto/err/err.c
Message-ID: <CABGfs-D4kX=xzu7rcHnDwHg=N+42tR8O=6XweP4x+R7OY-LC_Q@mail.gmail.com>

Dear Sir/Madam,

  During system restart, there is a crash in openSSL(ver openssl-1.0.1j)
pointing to crypto/err/err.c
>From the backtrace, it is complaining about double free
in int_thread_del_item() function in crypto/err/err.c file. Please find
backtrace below. Could you let us know if this is a known issue.

#3  0x000000801ea20000 in __GI_raise (sig=<optimized out>) at
../sysdeps/unix/sysv/linux/raise.c:55
#4  0x000000801ea25850 in __GI_abort () at abort.c:89
#5  0x000000801ea60e24 in __libc_message (do_abort=<optimized out>,
fmt=<optimized out>) at ../sysdeps/posix/libc_fatal.c:175
#6  0x000000801ea6f368 in malloc_printerr (action=<optimized out>,
str=0x801eb4f240 "*double free or corruption (!prev)*", ptr=<optimized
out>) at malloc.c:4958
#7  0x000000801ea701bc in _int_free (av=<optimized out>, p=<optimized
out>, have_lock=<optimized out>) at malloc.c:3829
#8  0x00003fff7ab472d8 in CRYPTO_free (str=0x3fff4c001010) at mem.c:397
#9  0x00003fff7abda018 in lh_free (lh=0x3fff4c000f50) at lhash.c:175
#10 0x00003fff7abdd858 in int_thread_del_item (d=<optimized out>) at err.c:537
#11 0x00003fff7abde978 in ERR_remove_thread_state (id=<optimized out>)
at err.c:994
#12 0x00003fff7abdea14 in ERR_remove_state (pid=<optimized out>) at err.c:1000


BR

Mahendar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150727/16fa6efe/attachment.html>

From dweidenkopf at cococorp.com  Mon Jul 27 21:12:55 2015
From: dweidenkopf at cococorp.com (David Weidenkopf)
Date: Mon, 27 Jul 2015 14:12:55 -0700
Subject: [PATCH] pkcs12 application selects bad defaults in FIPS mode
Message-ID: <CACdfkSKtKvxb4-=K6A5Ty-9vYXk+bbxJ=JrhjQ22eAkcuyf4yg@mail.gmail.com>

openssl 1.0.1l

It seems that the default algorithm selection for pkcs12 is incorrect when
FIPS mode is in use. The root cause appears to be that the FIPS_mode()
check is performed prior to the load_config() call. A patch is attached
that changes this ordering.

Feedback on this issue would be much appreciated.

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150727/391cc585/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pkcs12_FIPS_check.patch
Type: text/x-patch
Size: 829 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150727/391cc585/attachment.bin>

From qza22c5l at gmail.com  Tue Jul 28 04:43:01 2015
From: qza22c5l at gmail.com (Nicholas Cooper)
Date: Tue, 28 Jul 2015 12:43:01 +0800
Subject: misleading comment in openssl-1.0.2
Message-ID: <55B70855.50005@gmail.com>

The patch is for openssl-1.0.2d.tar.gz of which file the MD5 is
38dd619b2e77cbac69b99f52a053d25a
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openssl-1.0.2d.diff
Type: text/x-patch
Size: 1012 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150728/8b613cab/attachment.bin>

From jsd at av8n.com  Tue Jul 28 14:35:41 2015
From: jsd at av8n.com (John Denker)
Date: Tue, 28 Jul 2015 07:35:41 -0700
Subject: make install fails with --prefix=./relative-path
Message-ID: <55B7933D.3030403@av8n.com>

Scenario:
  :; git clone https://github.com/openssl/openssl openssl-temp
  :; cd openssl-temp
  :; ./config --prefix=./relpath
  :; make
  :; make install
  [spewage snipped]

  created directory `./relpath'
  Cannot create directory ./relpath/.: File exists
  Makefile:669: recipe for target 'install_docs' failed
  make: *** [install_docs] Error 17

Discussion:

It could be argued that an implicit relative path of the
form --prefix=usr is probably a user error, i.e. a typo
in lieu of --prefix=/usr.  However, if you think it 
should be treated as an error, it should be caught at 
./config time ... rather than waiting until the middle 
of the install process.  Also, there should be some
meaningful, helpful error message, rather than "file 
exists".

Furthermore, an explicit relative path (i.e. one with 
a leading "./" or "../" in it) is probably not a user
error.  The expected and desired behavior is that it
should just work.

  If for some reason this cannot work, it should be
  caught at ./config time.  A meaningful, helpful
  error message should be given.


From eijdenberg at google.com  Tue Jul 28 15:32:45 2015
From: eijdenberg at google.com (Adam Eijdenberg)
Date: Tue, 28 Jul 2015 15:32:45 +0000
Subject: [PATCH] Fix broken argument parsing for genrsa
Message-ID: <CAP9QY5b57iqwKrbStjY_UNTnWoE59iX6Htwx_ThOvNUtJEKbNw@mail.gmail.com>

Hi rt at openssl.org,

Please see linked pull request for a small patch to fix various argument
parsing issues noticed in genrsa and also some other tools:
https://github.com/openssl/openssl/pull/339

Cheers, Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150728/b9ea8a35/attachment.html>

From eijdenberg at google.com  Tue Jul 28 17:18:58 2015
From: eijdenberg at google.com (Adam Eijdenberg)
Date: Tue, 28 Jul 2015 17:18:58 +0000
Subject: [PATCH] Fix behavior of unspecified number of requests for OCSP
 responder
Message-ID: <CAP9QY5bKcJFbHTwZsqrvMPhURdDGZARtLH8_HFbgMsVmaC=pqg@mail.gmail.com>

Documentation states that "-nrequest pnum Number of requests to accept
(default unlimited)", but in practice not specifying "-nrequest" would have
the affect of accepting only 1 request.

Pull request to fix behavior to match docs:
https://github.com/openssl/openssl/pull/343
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150728/0d4fbef0/attachment.html>

From eijdenberg at google.com  Tue Jul 28 18:23:04 2015
From: eijdenberg at google.com (Adam Eijdenberg)
Date: Tue, 28 Jul 2015 18:23:04 +0000
Subject: [PATCH] Fix -rev,
 -www and -WWW modes to also allow OCSP-stapled responses
Message-ID: <CAP9QY5a6zO4P6XKGVjh2va-+A7=fv0+-LdvOnZZL=EAK6fMStA@mail.gmail.com>

openssl s_server ignores all OCSP-stapling options if -rev, -www or -WWW
are enabled.

Fix by moving initialization of CTX to outside of the callback.

At same time also set options on ctx2 if available (matching how other ctx
options are set).

See pull request:
https://github.com/openssl/openssl/pull/344

Cheers, Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150728/03ffe5a5/attachment-0001.html>

From david.woodhouse at intel.com  Wed Jul 29 11:52:17 2015
From: david.woodhouse at intel.com (Woodhouse, David)
Date: Wed, 29 Jul 2015 11:52:17 +0000
Subject: Fix OPENSSL_NO_STDIO build
Message-ID: <1438170735.26511.33.camel@intel.com>

Please pull the following fixes from
   git://git.infradead.org/users/dwmw2/openssl-nostdio.git

These are browsable in gitweb at 
   http://git.infradead.org/users/dwmw2/openssl-nostdio.git

This removes a number of functions which require file access, which is not possible when OPENSSL_NO_STDIO is set. In some cases the functions were already missing, but the declarations were still present in the header files (and causing compilation errors if FILE was not defined). In other cases the declarations were correctly made conditional but the actual functions still existed.

A couple of places use the BUFSIZ macro for a temporary buffer, and needed an alternative.

The unused OPENSSL_stderr() function that does nothing but return stderr is removed entirely.

OPENSSL_showfatal() now does nothing for the no-stdio build. It might be possible to (re)introduce OPENSSL_std{in,out,err} as BIOs. Even platforms which have no file access and no true stdio will often have some form of console output, and BIO_printf() to that could certainly work for things like OPENSSL_showfatal(). That's left for a later date.

The main thing that I'm *not* happy with is including <stdio.h> to make sscanf() work in OPENSSL_cpuid_setup(). That's at the very end of the tree for a reason.

David Woodhouse (17):
      Eliminate compiler warning for unused send_fp_chars() with no-stdio
      Disable GOST engine when no-stdio
      Disable TEST_ENG_OPENSSL_PKEY with no-stdio
      Eliminate compiler warning for unused do_pk8pkey_fp() with no-stdio
      Eliminate SRP_VBASE_init() and supporting functions for no-stdio
      Use OPENSSL_showfatal() in CRYPTO_destroy_dynlockid() to fix no-stdio
      Disable X509_LOOKUP_hash_dir() with no-stdio
      Add missing DECLARE_PEM_write_fp_const for no-stdio
      Remove functions taking FILE * from header files for no-stdio
      Disable file-based TS_CONF_* functions for no-stdio build
      Disable file: values in pci_process_value() for no-stdio build
      Add fallback definition of BUFSIZ for no-stdio build
      Remove unviable conf functionality from no-stdio build
      Remove file-based functionality from ssl/ for no-stdio build
      Kill OPENSSL_stderr()
      Make OPENSSL_showfatal do nothing with no-stdio
      Include <stdio.h> for sscanf() even with no-stdio

-- 
                  Sent with Evolution's ActiveSync support.

David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3437 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150729/5d9a2321/attachment.bin>

From zeuscezary at gmail.com  Wed Jul 29 12:18:07 2015
From: zeuscezary at gmail.com (Cezary Pytka)
Date: Wed, 29 Jul 2015 14:18:07 +0200
Subject: Enhancement: s_client proxy basic authorization
Message-ID: <CACW145P0ikNmtqXJe9ZO-C_d=iYmZf4B8cMRpQpeNN=MdnZNFw@mail.gmail.com>

Hi,



Regarding OpenSSL v1.1.0-dev on Cygwin64, Windows 8.1



I've tried to use the proxy option in s_client and it seems that it doesn't
support basic authorization via user:password at proxyhost:port.



I get an error "getservbyname failure for password at proxyhost:port"



If I try user at proxyhost:port I get "gethostbyname failure"





Cezary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150729/2702e538/attachment-0001.html>

From dwmw2 at infradead.org  Wed Jul 29 13:19:36 2015
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 29 Jul 2015 14:19:36 +0100
Subject: Restore OPENSSL_NO_RFC3779
Message-ID: <1438175976.26511.50.camel@infradead.org>

This reverts the non-cleanup parts of commit c73ad69017. We do actually
have a reasonable use case for OPENSSL_NO_RFC3779 in the EDK2 UEFI
build, since we don't have a strspn() function in our runtime environment
and we don't want the RFC3779 functionality anyway.

In addition, it changes the default behaviour of the Configure script so
that RFC3779 support isn't disabled by default. It was always disabled
from when it was first added in 2006, right up until the point where
OPENSSL_NO_RFC3779 was turned into a no-op ? and the code in the
Configure script was left *trying* to disable it, but not actually
working.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Revert-OPENSSL_NO_xxx-cleanup-RFC3779.patch
Type: text/x-patch
Size: 10500 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150729/41f7204d/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5691 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150729/41f7204d/attachment-0003.bin>

From praveen at viptela.com  Wed Jul 29 20:24:01 2015
From: praveen at viptela.com (Praveen Kariyanahalli)
Date: Wed, 29 Jul 2015 13:24:01 -0700
Subject: Assert hit in the latest 1.0.2d code
Message-ID: <CAHwXwXQwhjn5wE8f_cJ=UeCjFWFLG9e4=KpvYJuFjDRDVqBAdg@mail.gmail.com>

int do_dtls1_write(SSL *s, int type, const unsigned char *buf, unsigned int
len, int create_empty_fragment)
        {
        unsigned char *p,*pseq;
        int i,mac_size,clear=0;
        int prefix_len = 0;
        SSL3_RECORD *wr;
        SSL3_BUFFER *wb;
        SSL_SESSION *sess;
        int bs;

        /* first check if there is a SSL3_BUFFER still being written
         * out.  This will happen with non blocking IO */
        if (s->s3->wbuf.left != 0)
                {
*                OPENSSL_assert(0); /* XDTLS:  want to see if we ever get
here */*
                return(ssl3_write_pending(s,type,buf,len));
                }



==================================


(gdb) frame 2
#2  0x00007ffff6d690d5 in do_dtls1_write (s=0x7ffff4fe5c10, type=23,
buf=0x7ffff4bdf010 "\005@\200", len=62, create_empty_fragment=0) at
d1_pkt.c:1505
1505            OPENSSL_assert(0);      /* XDTLS: want to see if we ever
get here */
(gdb) p s->s3->wbuf
$1 = {buf = 0x7ffff36f6010 "\027\376\375", len = 17584, offset = 0, left =
99}
(gdb)


====================================


We seem to hit this assert with the latest code.  Our sockets are all in
non-blocking fashion. I dont see this assert in the previous releases.

Can somebody throw more light on to this ? It is urgent. As we are not able
to migrate to this version because of this regression.

Thanks in Advance
-Praveen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150729/dc755e22/attachment.html>

From villapando_julius at yahoo.com  Thu Jul 30 10:52:53 2015
From: villapando_julius at yahoo.com (Julius Villapando)
Date: Thu, 30 Jul 2015 10:52:53 +0000 (UTC)
Subject: HOSENT: redefinition error
Message-ID: <1201272200.5605558.1438253573652.JavaMail.yahoo@mail.yahoo.com>

Hi,

I'm trying to use the openssl library along with other libraries but the HOSENT in bio.h conflicts with winsock.h HOSENT, do you guys have a solution for this, or can I request that you change the name of HOSENT to avoid the redefinition error? Thanks in advance.

Here is the error:openssl/bio.h(729) : error C2371: 'HOSTENT' : redefinition; different basic types
winsock.h(1029) : see declaration of 'HOSTENT'
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150730/e194b22b/attachment.html>

From dwmw2 at infradead.org  Thu Jul 30 11:19:59 2015
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 30 Jul 2015 12:19:59 +0100
Subject: [PATCH] Add OPENSSL_SYS_UEFI
Message-ID: <1438255199.26511.151.camel@infradead.org>

From 22bb269a219147c9bba0debf652458796850cadc Mon Sep 17 00:00:00 2001
From: David Woodhouse <David.Woodhouse at intel.com>
Date: Mon, 27 Jul 2015 11:05:14 +0100
Subject: [PATCH] Add OPENSSL_SYS_UEFI

This provides support for building in the EDK2 reference implementation
of UEFI. Most UEFI firmware in existence uses OpenSSL for implementing
the core cryptographic functionality needed for Secure Boot.

This has always previously been handled with external patches to OpenSSL
but we are now making a concerted effort to eliminate those.

In this mode, we don't actually use the OpenSSL makefiles; we process
the MINFO file generated by 'make files' and incorporate it into the
EDK2 build system.

Signed-off-by: David Woodhouse <David.Woodhouse at intel.com>
---
 Configurations/10-main.conf | 7 +++++++
 crypto/rand/rand_egd.c      | 2 +-
 crypto/rand/rand_unix.c     | 4 ++--
 e_os.h                      | 2 +-
 include/openssl/e_os2.h     | 5 +++++
 5 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/Configurations/10-main.conf b/Configurations/10-main.conf
index b5d32b6..2dcc82d 100644
--- a/Configurations/10-main.conf
+++ b/Configurations/10-main.conf
@@ -1207,6 +1207,13 @@
         shared_extension => ".dll.a",
     },
 
+#### UEFI
+    "UEFI" => {
+        cc               => "cc",
+        cflags           => "-DL_ENDIAN -O",
+        sys_id           => "UEFI",
+    },
+
 #### UWIN
     "UWIN" => {
         cc               => "cc",
diff --git a/crypto/rand/rand_egd.c b/crypto/rand/rand_egd.c
index 44ed4bb..d062dd6 100644
--- a/crypto/rand/rand_egd.c
+++ b/crypto/rand/rand_egd.c
@@ -95,7 +95,7 @@
  *   RAND_egd() is a wrapper for RAND_egd_bytes() with numbytes=255.
  */
 
-#if defined(OPENSSL_SYS_WIN32) || defined(OPENSSL_SYS_VMS) || defined(OPENSSL_SYS_MSDOS) || defined(OPENSSL_SYS_VXWORKS) || defined(OPENSSL_SYS_NETWARE) || defined(OPENSSL_SYS_VOS)
+#if defined(OPENSSL_SYS_WIN32) || defined(OPENSSL_SYS_VMS) || defined(OPENSSL_SYS_MSDOS) || defined(OPENSSL_SYS_VXWORKS) || defined(OPENSSL_SYS_NETWARE) || defined(OPENSSL_SYS_VOS) || defined(OPENSSL_SYS_UEFI)
 int RAND_query_egd_bytes(const char *path, unsigned char *buf, int bytes)
 {
     return (-1);
diff --git a/crypto/rand/rand_unix.c b/crypto/rand/rand_unix.c
index 72f8617..bb70a5b 100644
--- a/crypto/rand/rand_unix.c
+++ b/crypto/rand/rand_unix.c
@@ -116,7 +116,7 @@
 #include <openssl/rand.h>
 #include "rand_lcl.h"
 
-#if !(defined(OPENSSL_SYS_WINDOWS) || defined(OPENSSL_SYS_WIN32) || defined(OPENSSL_SYS_VMS) || defined(OPENSSL_SYS_OS2) || defined(OPENSSL_SYS_VXWORKS) || defined(OPENSSL_SYS_NETWARE))
+#if !(defined(OPENSSL_SYS_WINDOWS) || defined(OPENSSL_SYS_WIN32) || defined(OPENSSL_SYS_VMS) || defined(OPENSSL_SYS_OS2) || defined(OPENSSL_SYS_VXWORKS) || defined(OPENSSL_SYS_NETWARE) || defined(OPENSSL_SYS_UEFI))
 
 # include <sys/types.h>
 # include <sys/time.h>
@@ -419,7 +419,7 @@ int RAND_poll(void)
                                  * defined(OPENSSL_SYS_VXWORKS) ||
                                  * defined(OPENSSL_SYS_NETWARE)) */
 
-#if defined(OPENSSL_SYS_VXWORKS)
+#if defined(OPENSSL_SYS_VXWORKS) || defined(OPENSSL_SYS_UEFI)
 int RAND_poll(void)
 {
     return 0;
diff --git a/e_os.h b/e_os.h
index 4c1b4aa..b3a3338 100644
--- a/e_os.h
+++ b/e_os.h
@@ -112,7 +112,7 @@ extern "C" {
 #  define MSDOS
 # endif
 
-# if defined(MSDOS) && !defined(GETPID_IS_MEANINGLESS)
+# if (defined(MSDOS) || defined(OPENSSL_SYS_UEFI)) && !defined(GETPID_IS_MEANINGLESS)
 #  define GETPID_IS_MEANINGLESS
 # endif
 
diff --git a/include/openssl/e_os2.h b/include/openssl/e_os2.h
index 177b098..6327a64 100644
--- a/include/openssl/e_os2.h
+++ b/include/openssl/e_os2.h
@@ -76,6 +76,11 @@ extern "C" {
 #  define OPENSSL_SYS_NETWARE
 # endif
 
+/* -------------------------------- UEFI ---------------------------------- */
+# if defined(OPENSSL_SYS_UEFI)
+#  undef OPENSSL_SYS_UNIX
+# endif
+
 /* --------------------- Microsoft operating systems ---------------------- */
 
 /*
-- 
2.4.3

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5691 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150730/3ab39250/attachment.bin>

From aklitzing at gmail.com  Thu Jul 30 16:15:06 2015
From: aklitzing at gmail.com (A. Klitzing)
Date: Thu, 30 Jul 2015 18:15:06 +0200
Subject: Bug: install_sw target broken with no-engine
Message-ID: <CAJaftdik0+t1KYqd2R8rBDKiUa0jmfP=Kx=75+dosjgJeNSxcQ@mail.gmail.com>

Hi there!

The install_sw target of current master branch [1] is broken if no-engine
is provided.
Same works with 1.0.2d!

Steps:
$ ./Configure --prefix=/tmp/test no-engine shared linux-x86_64
[...]

$ make depend
[...]

$ make
[...]

$ make install_sw
making install in engines...
make[1]: Entering directory '/XXX/openssl/engines'
installing 4758cca
cp: cannot stat 'lib4758cca.so': No such file or directory
Makefile:96: recipe for target 'install' failed
make[1]: *** [install] Error 1
make[1]: Leaving directory '/XXX/openssl/engines'
Makefile:524: recipe for target 'install_sw' failed
make: *** [install_sw] Error 1


Best regards
  Andr? Klitzing


[1] 3df16cc2e27f75eac2c0991248b0c294e2c847b5
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150730/aad74b13/attachment-0001.html>

From bkaduk at akamai.com  Thu Jul 30 19:30:15 2015
From: bkaduk at akamai.com (Kaduk, Ben)
Date: Thu, 30 Jul 2015 19:30:15 +0000
Subject: EVP documentation implicitly recommends the use of single-DES
Message-ID: <D1DFE577.8A5%bkaduk@akamai.com>

See https://github.com/openssl/openssl/pull/348

I was looking for something else but then saw this text about "normally
supplied by a function such as EVP_des_cbc()"; we should not be misleading
our users in such a fashion.

-Ben


From hkario at redhat.com  Fri Jul 31 17:05:13 2015
From: hkario at redhat.com (Hubert Kario)
Date: Fri, 31 Jul 2015 19:05:13 +0200
Subject: few options in s_client and s_server are missing descriptions
Message-ID: <5287622.x94utvHqBf@pintsize.usersys.redhat.com>

-curves, -sigalgs, -client_sigalgs are not documented in s_client and s_server 
-help messages

fixes:
https://github.com/openssl/openssl/pull/351 (1.0.2)
https://github.com/openssl/openssl/pull/350 (master)
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150731/2cc1013d/attachment.sig>

From lbaudoin at google.com  Fri Jul 31 17:35:00 2015
From: lbaudoin at google.com (Laetitia Baudoin)
Date: Fri, 31 Jul 2015 10:35:00 -0700
Subject: The IV used by the 'openssl cms -encrypt -aes-256-gcm' command is not
 random (all zeroes).
Message-ID: <CAFTDvC5ho22zHTD1kRUJ=0Lmw8Tq_HvkFRg_HuozmNz_j7R9HA@mail.gmail.com>

When encrypting using the 'openssl cms -encrypt -aes-256-gcm' command an
all zero IV is used, this breaks any guarantees provided by the GCM
mode (see NIST Special Publication 800-38D).

Version tested: openssl 1.0.2d on linux x86_64.

Example:
openssl cms -encrypt -in message.txt -out encrypted-openssl-aes-256-gcm.msg
-recip user1_no_cn.pem -aes-256-gcm

When looking at the ASN.1 for the contentEncryptionAlgorithm we get:

SEQUENCE(2 elem)
  OBJECT IDENTIFIER2.16.840.1.101.3.4.1.46
  OCTET STRING(12 byte) 000000000000000000000000  <-- This is the IV

Expectation:
 - If AES-GCM is not supported by the 'openssl cms' command (there is no
clear RFC for it when generating enveloped data, RFC 5084 is for
authenticated enveloped data) the command should show an error.
 -  If AES-GCM is supported it should generate a random IV
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150731/1a87c2d5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: encrypted-openssl-aes-256-gcm.msg
Type: application/octet-stream
Size: 905 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150731/1a87c2d5/attachment.obj>

From lbaudoin at google.com  Fri Jul 31 17:42:15 2015
From: lbaudoin at google.com (Laetitia Baudoin)
Date: Fri, 31 Jul 2015 10:42:15 -0700
Subject: The CMS encrypt command uses the wrong ASN.1 encoding for the AES-GCM
 algorithm parameter.
Message-ID: <CAFTDvC471FrPRQmfTydFmN=Of05W2EiYaHA7BhT_e0GS9hr6Zg@mail.gmail.com>

When using 'openssl cms -encrypt -aes-256-gcm' the algorithm generated is
encoded as:

SEQUENCE(2 elem)
  OBJECT IDENTIFIER2.16.840.1.101.3.4.1.46
  OCTET STRING(12 byte) 000000000000000000000000

But RFC 5084 (Using AES-CCM and AES-GCM Authenticated Encryption in the
Cryptographic Message Syntax (CMS)) specifies the algorithm parameters as:

GCMParameters ::= SEQUENCE {
   aes-nonce        OCTET STRING, -- recommended size is 12 octets
   aes-ICVlen       AES-GCM-ICVlen DEFAULT 12 }

   AES-GCM-ICVlen ::= INTEGER (12 | 13 | 14 | 15 | 16)

So the openssl version is missing the SEQUENCE tag.

Version tested: openssl 1.0.2d on linux x86_64
Example:
openssl cms -encrypt -in message.txt -out encrypted-openssl-aes-256-gcm.msg
-recip user1_no_cn.pem -aes-256-gcm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150731/05636165/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: encrypted-openssl-aes-256-gcm.msg
Type: application/octet-stream
Size: 905 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150731/05636165/attachment.obj>

From harold.stuart at bluecoat.com  Fri Jul 31 23:37:24 2015
From: harold.stuart at bluecoat.com (Stuart, Harold)
Date: Fri, 31 Jul 2015 23:37:24 +0000
Subject: Bug report
Message-ID: <4F0B5D0C-F6FF-4838-9F18-7BB7B69A65DA@bluecoat.com>

The cryptographic engineering team at Blue Coat systems is conducting a review of OpenSSL and have found the following minor bug. We would appreciate your consideration.

Observe the following lines in evp_enc.c:

    if (in->cipher_data && in->cipher->ctx_size) {
        out->cipher_data = OPENSSL_malloc(in->cipher->ctx_size);
        if (!out->cipher_data) {
            EVPerr(EVP_F_EVP_CIPHER_CTX_COPY, ERR_R_MALLOC_FAILURE);
            return 0;
        }
        memcpy(out->cipher_data, in->cipher_data, in->cipher->ctx_size);
    }

    if (in->cipher->flags & EVP_CIPH_CUSTOM_COPY)
        return in->cipher->ctrl((EVP_CIPHER_CTX *)in, EVP_CTRL_COPY, 0, out);

Note that in->cipher data is checked for NULL, which implies that in->cipher_data can be NULL. Now, take a look at function ads_ccm_ctrl, which is what in->cipher_ctrl points to:

static int aes_ccm_ctrl(EVP_CIPHER_CTX *c, int type, int arg, void *ptr)
{
    EVP_AES_CCM_CTX *cctx = c->cipher_data;
    switch (type) {
    case EVP_CTRL_INIT:
        cctx->key_set = 0;
        cctx->iv_set = 0;
        cctx->L = 8;
        cctx->M = 12;
        cctx->tag_set = 0;
        cctx->len_set = 0;
        return 1;

Note that c->cipher_data has been dereferenced, even though it may be NULL.

Thanks,

Harold Stuart
Senior Staff Engineer
Blue Coat Systems, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-bugs-mod/attachments/20150731/92d08429/attachment-0001.html>