Re: [openssl.org #2793] bug report : SCRIPTS environment variable overrides makefile variable
Hi, Installation of openssl-1.0.0e fails if SCRIPTS environment variable is defined (export SCRIPTS=/home/xxx/scripts for example). making install in apps... installing openssl installing /home/xxx/scripts In apps/Makefile, SCRIPTS is defined (SCRIPTS=CA.sh CA.pl tsget), but it seems that the makefile is called with -e option ($(MAKE) -e), which means that environment variables must override makefile local definitions. Verify http://cvs.openssl.org/chngview?cn=22430. Why is it necessary to call $(MAKE) -e? It was the only way to get both GNU and SysV make flavors work consistently. It is a little bit risky to use such an option. SCRIPTS variable is a common name, and people may define it in their shell rc file. Yes, it poses risk, but there is a way to handle it, CLEARENV. That's what patch does, modifies CLEARENV. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re : [openssl.org #2793] bug report : SCRIPTS environment variable overrides makefile variable
Hi,
The problem is fixed with your patch. Thank you!
Regards,
Cédric Marie.
De : Andy Polyakov via RT r...@openssl.org
À : cedric.ma...@yahoo.fr
Cc : openssl-dev@openssl.org
Envoyé le : Jeudi 19 avril 2012 8h48
Objet : Re: [openssl.org #2793] bug report : SCRIPTS environment variable
overrides makefile variable
Hi,
Installation of openssl-1.0.0e fails if SCRIPTS environment variable is
defined (export SCRIPTS=/home/xxx/scripts for example).
making install in apps...
installing openssl
installing /home/xxx/scripts
In apps/Makefile, SCRIPTS is defined (SCRIPTS=CA.sh CA.pl tsget), but
it seems that the makefile is called with -e option ($(MAKE) -e),
which means that environment variables must override makefile local
definitions.
Verify http://cvs.openssl.org/chngview?cn=22430.
Why is it necessary to call $(MAKE) -e?
It was the only way to get both GNU and SysV make flavors work consistently.
It is a little bit risky to use such an option. SCRIPTS variable is a
common name, and people may define it in their shell rc file.
Yes, it poses risk, but there is a way to handle it, CLEARENV. That's
what patch does, modifies CLEARENV.
Hi,The problem is fixed with your patch. Thank you!Regards,C?dric Marie.De: Andy Polyakov via RT r...@openssl.org ?: cedric.ma...@yahoo.fr Cc: openssl-dev@openssl.org Envoy? le : Jeudi 19 avril 2012 8h48 Objet: Re: [openssl.org #2793] bug report : SCRIPTS environment variable overrides makefile variable Hi, Installation of openssl-1.0.0e fails if SCRIPTS environment variable is defined (export SCRIPTS=/home/xxx/scripts for example). making install in apps... installing openssl installing /home/xxx/scripts In apps/Makefile, SCRIPTS is defined ("SCRIPTS=CA.sh CA.pl tsget"), but it seems that the makefile is called with -e option ("$(MAKE) -e"), which means that environment variables must override makefile local definitions.Verify http://cvs.openssl.org/chngview?cn=22430. Why is it necessary to call "$(MAKE) -e"?It was the only way to get both GNU and SysV make flavors work consistently. It is a little bit risky to use such an option. SCRIPTS variable is a common name, and people may define it in their shell rc file.Yes, it poses risk, but there is a way to handle it, CLEARENV. That'swhat patch does, modifies CLEARENV.
OpenSSL Security Advisory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OpenSSL Security Advisory [19 Apr 2012] === ASN1 BIO vulnerability (CVE-2012-2110) === A potentially exploitable vulnerability has been discovered in the OpenSSL function asn1_d2i_read_bio. Any application which uses BIO or FILE based functions to read untrusted DER format data is vulnerable. Affected functions are of the form d2i_*_bio or d2i_*_fp, for example d2i_X509_bio or d2i_PKCS12_fp. Applications using the memory based ASN1 functions (d2i_X509, d2i_PKCS12 etc) are not affected. In particular the SSL/TLS code of OpenSSL is *not* affected. Applications only using the PEM routines are not affected. S/MIME or CMS applications using the built in MIME parser SMIME_read_PKCS7 or SMIME_read_CMS *are* affected. The OpenSSL command line utility is also affected if used to process untrusted data in DER format. Note: although an application using the SSL/TLS portions of OpenSSL is not automatically affected it might still call a function such as d2i_X509_bio on untrusted data and be vulnerable. Thanks to Tavis Ormandy, Google Security Team, for discovering this issue and to Adam Langley a...@chromium.org for fixing it. Affected users should upgrade to OpenSSL 1.0.1a, 1.0.0i or 0.9.8v. References == URL for this Security Advisory: http://www.openssl.org/news/secadv_20120419.txt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEVAwUBT5AJh6LSm3vylcdZAQII+Af/dPNEQrJZ6YHlytaMW6zvkG64pvYBLuoO BdJQnFBR3oWolOIQDyFD7byECly/czVHA5mTifsG+XyHeLHB5Zr2PsnLBLj3d6Su verXPt8JU/XQb+Rhn1P9F32qTMwhZkgNcjV3eOprpUBD7qNz+nQd1pJtlKX3asmK wtVYyX6Dbbe61GQ6nDxT4fLpAL6Yk/YJH3jRA/R4MW/0vyJzYCALKiCsFuAzp2Fl Ov5n3Gkn+Y+1jaaGpqNxdWv1F3OI8vieC4lN4CfbaDDkQxNCNBRwcucK/tBBKAxK 3gravlQDuqnGn3M6GOpVJ89hZaPscMvsKx80jUKZtn2kPBaC7NxYeQ== =91XR -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2753] AutoReply: Patch: let application explicitly seed RNG on Unix
A couple of questions on Thor's proposed patch:
1. There has been no discussion - does that imply a passive acceptance or
passive rejection?
2. I am using OpenSSL/FIPS on a system with /dev/urandom. Although the
rand_unix.c RAND_poll() function is called only once with the released
code, after the system has been up for a bit after reboot, I have assumed
that the read from /dev/urandom obtained sufficient entropy. That is, the
ok test in ssleay_rand_bytes() will always be true. Am I being naive? I
do not get any errors ever, but I have been using RAND_bytes without
checking the return code, since from what I can tell if the ok is true
once, it will always be true unless my application makes another call to
RAND_poll() if RAND_bytes returns 0. With Thor's patch however, the
RAND_bytes call would itself boost the entropy with calls to RAND_poll if
the initial call was not enough. Maybe it is not an issue with /dev/urandom?
Kevin
On Wed, Mar 7, 2012 at 5:24 AM, Thor Lancelot Simon via RT
r...@openssl.orgwrote:
Here is a better patch. The previous one caused problems for
applications that called RAND_bytes() (usually indirectly) before
any other RAND function -- like, say, the OpenSSH client.
Thor
Index: crypto/rand/md_rand.c
===
RCS file:
/cvsroot/src/crypto/external/bsd/openssl/dist/crypto/rand/md_rand.c,v
retrieving revision 1.1.1.3
retrieving revision 1.3
diff -u -r1.1.1.3 -r1.3
--- crypto/rand/md_rand.c 5 Jun 2011 14:59:27 - 1.1.1.3
+++ crypto/rand/md_rand.c 7 Mar 2012 10:17:47 - 1.3
@@ -141,7 +141,6 @@
static unsigned char md[MD_DIGEST_LENGTH];
static long md_count[2]={0,0};
static double entropy=0;
-static int initialized=0;
static unsigned int crypto_lock_rand = 0; /* may be set only when a thread
* holds CRYPTO_LOCK_RAND
@@ -187,7 +186,6 @@
md_count[0]=0;
md_count[1]=0;
entropy=0;
- initialized=0;
}
static void ssleay_rand_add(const void *buf, int num, double add)
@@ -389,18 +387,16 @@
CRYPTO_w_unlock(CRYPTO_LOCK_RAND2);
crypto_lock_rand = 1;
- if (!initialized)
- {
- RAND_poll();
- initialized = 1;
- }
-
if (!stirred_pool)
do_stir_pool = 1;
ok = (entropy = ENTROPY_NEEDED);
if (!ok)
{
+
+ RAND_poll();
+ ok = (entropy = ENTROPY_NEEDED);
+
/* If the PRNG state is not yet unpredictable, then seeing
* the PRNG output may help attackers to determine the new
* state; thus we have to decrease the entropy estimate.
@@ -571,11 +567,10 @@
CRYPTO_w_unlock(CRYPTO_LOCK_RAND2);
crypto_lock_rand = 1;
}
-
- if (!initialized)
+
+ if (entropy ENTROPY_NEEDED)
{
RAND_poll();
- initialized = 1;
}
ret = entropy = ENTROPY_NEEDED;
Index: crypto/rand/rand_unix.c
===
RCS file:
/cvsroot/src/crypto/external/bsd/openssl/dist/crypto/rand/rand_unix.c,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- crypto/rand/rand_unix.c 19 Jul 2009 23:30:41 - 1.2
+++ crypto/rand/rand_unix.c 5 Mar 2012 20:13:36 - 1.3
@@ -182,6 +182,16 @@
u_int32_t rnd = 0, i;
unsigned char buf[ENTROPY_NEEDED];
+ /*
+* XXX is this really a good idea? It has the seemingly
+* XXX very undesirable eventual result of keying the CTR_DRBG
+* XXX generator exclusively with key material produced by
+* XXX the libc arc4random(). It also guarantees that even
+* XXX if the generator tries to use RAND_poll() to rekey
+* XXX itself after a call to fork() etc, it will end up with
+* XXX the same state, since the libc arc4 state will be the same
+* XXX unless explicitly updated by the application.
+*/
for (i = 0; i sizeof(buf); i++) {
if (i % 4 == 0)
rnd = arc4random();
Re: [openssl.org #2792] Crash in rc4 on x86_64
On Wed, Apr 18, 2012 at 08:04:28PM +0200, Andy Polyakov via RT wrote: I've had 2 users report a crash in RC4() on x86_64. The backtrace looks like: #0 RC4 () at rc4-x86_64.s:343 #1 0x012d in ?? () #2 0x00df in ?? () #3 0x020b5660 in ?? () #4 0x7fc075f6a9c9 in rc4_hmac_md5_cipher (ctx=optimized out, out=0x20aae98 .\324\300\377AE'|#\242\300\233\025T\341\002}\237\242\240\273G\260\257\214z\321\001HK«RA\257HC0\0\257N*1C/,$\252-N1%1\261\/0C*'C\246-\!/C*\nb% SO\261\067\303\060,17^'*\260\063/\:C7+\261\'^1%\246\061- 0C\267+1\'^1\246%0C.6/7\252\33-'C\266-0/ 7\303 +*/'1\255C-\.03\242 C6*'3\257\066\060C/*07\316;7-'\247C*R[-/\265/^RC ,\255..., in=optimized out, len=0) at e_rc4_hmac_md5.c:163 #5 0x7fc076272b8f in tls1_enc (s=0x209c120, send=1) at t1_enc.c:828 #6 0x7fc076269e18 in do_ssl3_write (s=0x209c120, type=23, buf=0x209cf34 2 OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CON..., len=285, create_empty_fragment=0) at s3_pkt.c:808 #7 0x7fc07626a144 in ssl3_write_bytes (s=0x209c120, type=23, buf_=0x209cf34, len=optimized out) at s3_pkt.c:605 This looks simular to the AES problem with had, with a length of 0? More details are at: http://bugs.debian.org/666405 http://cvs.openssl.org/chngview?cn=22424 is combined patch. This fails like this on non-i386/x86_64 arches: ../libcrypto.a(e_rc4_hmac_md5.o): In function `EVP_rc4_hmac_md5': /build/buildd-openssl_1.0.1a-1-ia64-b35uCp/openssl-1.0.1a/crypto/evp/e_rc4_hmac_md5.c:294: undefined reference to `OPENSSL_ia32cap_P' /build/buildd-openssl_1.0.1a-1-ia64-b35uCp/openssl-1.0.1a/crypto/evp/e_rc4_hmac_md5.c:294: undefined reference to `OPENSSL_ia32cap_P' Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2792] Crash in rc4 on x86_64
On Thu, Apr 19, 2012 at 09:08:48PM +0200, Kurt Roeckx wrote:
On Wed, Apr 18, 2012 at 08:04:28PM +0200, Andy Polyakov via RT wrote:
I've had 2 users report a crash in RC4() on x86_64. The
backtrace looks like:
#0 RC4 () at rc4-x86_64.s:343
#1 0x012d in ?? ()
#2 0x00df in ?? ()
#3 0x020b5660 in ?? ()
#4 0x7fc075f6a9c9 in rc4_hmac_md5_cipher (ctx=optimized out,
out=0x20aae98
.\324\300\377AE'|#\242\300\233\025T\341\002}\237\242\240\273G\260\257\214z\321\001HK«RA\257HC0\0\257N*1C/,$\252-N1%1\261\/0C*'C\246-\!/C*\nb%
SO\261\067\303\060,17^'*\260\063/\:C7+\261\'^1%\246\061-
0C\267+1\'^1\246%0C.6/7\252\33-'C\266-0/ 7\303
+*/'1\255C-\.03\242
C6*'3\257\066\060C/*07\316;7-'\247C*R[-/\265/^RC ,\255...,
in=optimized out, len=0) at e_rc4_hmac_md5.c:163
#5 0x7fc076272b8f in tls1_enc (s=0x209c120, send=1) at t1_enc.c:828
#6 0x7fc076269e18 in do_ssl3_write (s=0x209c120, type=23,
buf=0x209cf34 2 OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR
LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES
THREAD=REFS MULTIAPPEND UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED
I18NLEVEL=1 CON..., len=285, create_empty_fragment=0) at s3_pkt.c:808
#7 0x7fc07626a144 in ssl3_write_bytes (s=0x209c120, type=23,
buf_=0x209cf34, len=optimized out) at s3_pkt.c:605
This looks simular to the AES problem with had, with a length of 0?
More details are at:
http://bugs.debian.org/666405
http://cvs.openssl.org/chngview?cn=22424 is combined patch.
This fails like this on non-i386/x86_64 arches:
../libcrypto.a(e_rc4_hmac_md5.o): In function `EVP_rc4_hmac_md5':
/build/buildd-openssl_1.0.1a-1-ia64-b35uCp/openssl-1.0.1a/crypto/evp/e_rc4_hmac_md5.c:294:
undefined reference to `OPENSSL_ia32cap_P'
/build/buildd-openssl_1.0.1a-1-ia64-b35uCp/openssl-1.0.1a/crypto/evp/e_rc4_hmac_md5.c:294:
undefined reference to `OPENSSL_ia32cap_P'
I've used this patch to fix it:
Index: openssl-1.0.1a/crypto/evp/e_rc4_hmac_md5.c
===
--- openssl-1.0.1a.orig/crypto/evp/e_rc4_hmac_md5.c 2012-04-18
19:51:33.0 +0200
+++ openssl-1.0.1a/crypto/evp/e_rc4_hmac_md5.c 2012-04-19 21:53:36.0
+0200
@@ -289,8 +289,14 @@
const EVP_CIPHER *EVP_rc4_hmac_md5(void)
{
+#ifdefined(__i386) || defined(__i386__) || defined(_M_IX86) || \
+ defined(__INTEL__) || \
+ defined(__x86_64) || defined(__x86_64__) || defined(_M_AMD64) ||
defined(_M_X64)
extern unsigned int OPENSSL_ia32cap_P[];
/* RC4_CHAR flag v */
return(OPENSSL_ia32cap_P[0](120) ? NULL : r4_hmac_md5_cipher);
+#else
+ return(r4_hmac_md5_cipher);
+#endif
}
#endif
Kurt
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Questions re: OpenSSL Security Advisory CVE-2012-2110
The detailed analysis for CVE-2012-2110 implies issues with truncation, specifically int vs long vs size_t. Is the problem limited to platforms where these are different sizes? The analysis says not limited to I32LP64, but does not rule out any platforms where it is not an issue. Can it occur on ILP32 or ILP32LL64 platforms? Thanks! Erik Tkal Juniper OAC/UAC/Pulse Development
Re: [openssl.org #2792] Crash in rc4 on x86_64
This looks simular to the AES problem with had, with a length of 0? For reference. What was going on was the RC4_set_key was generating compact key schedule on Intel legacy CPU, while rc4_md5_enc was treating as non-compact with 32-bit elements. As results it was messed up in such way that induced crash in *subsequent* call to RC4. More details are at: http://bugs.debian.org/666405 http://cvs.openssl.org/chngview?cn=22424 is combined patch. This fails like this on non-i386/x86_64 arches: ../libcrypto.a(e_rc4_hmac_md5.o): In function `EVP_rc4_hmac_md5': /build/buildd-openssl_1.0.1a-1-ia64-b35uCp/openssl-1.0.1a/crypto/evp/e_rc4_hmac_md5.c:294: undefined reference to `OPENSSL_ia32cap_P' /build/buildd-openssl_1.0.1a-1-ia64-b35uCp/openssl-1.0.1a/crypto/evp/e_rc4_hmac_md5.c:294: undefined reference to `OPENSSL_ia32cap_P' Once in a while you get too comfy and make such blunder. Apologies! I've used this patch to fix it: I've settled for http://cvs.openssl.org/chngview?cn=22455. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Questions re: OpenSSL Security Advisory CVE-2012-2110
On Thu, Apr 19, 2012, Erik Tkal wrote: The detailed analysis for CVE-2012-2110 implies issues with truncation, specifically int vs long vs size_t. Is the problem limited to platforms where these are different sizes? The analysis says not limited to I32LP64, but does not rule out any platforms where it is not an issue. Can it occur on ILP32 or ILP32LL64 platforms? Yes: it isn't just limited to I32LP64. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2792] Crash in rc4 on x86_64
I encounter compilation error when compiling for ARM platform wth OpenSSL
1.0.1a:
make -f ../Makefile.shared -e \
APPNAME=openssl OBJECTS=openssl.o verify.o asn1pars.o req.o dgst.o dh.o
dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o
rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o genrsa.o gendsa.o genpkey.o
s_server.o s_client.o speed.o s_time.o apps.o s_cb.o s_socket.o app_rand.o
version.o sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o pkey.o pkeyparam.o
pkeyutl.o spkac.o smime.o cms.o rand.o engine.o ocsp.o prime.o ts.o srp.o \
LIBDEPS= $LIBRARIES -ldl \
link_app.${shlib_target}
make[2]: Entering directory
`/home/qunying/projs/git/FortiOS_lib/openssl/trunk/apps'
../libcrypto.so: undefined reference to `OPENSSL_ia32cap_P'
--
qun-ying
- Original Message -
From: Andy Polyakov ap...@openssl.org
To: openssl-dev@openssl.org
Cc:
Sent: Thursday, April 19, 2012 1:52:31 PM
Subject: Re: [openssl.org #2792] Crash in rc4 on x86_64
This looks simular to the AES problem with had, with a length
of 0?
For reference. What was going on was the RC4_set_key was generating
compact key schedule on Intel legacy CPU, while rc4_md5_enc was treating
as non-compact with 32-bit elements. As results it was messed up in such
way that induced crash in *subsequent* call to RC4.
More details are at:
http://bugs.debian.org/666405
http://cvs.openssl.org/chngview?cn=22424 is combined patch.
This fails like this on non-i386/x86_64 arches:
../libcrypto.a(e_rc4_hmac_md5.o): In function `EVP_rc4_hmac_md5':
/build/buildd-openssl_1.0.1a-1-ia64-b35uCp/openssl-1.0.1a/crypto/evp/e_rc4_hmac_md5.c:294:
undefined reference to `OPENSSL_ia32cap_P'
/build/buildd-openssl_1.0.1a-1-ia64-b35uCp/openssl-1.0.1a/crypto/evp/e_rc4_hmac_md5.c:294:
undefined reference to `OPENSSL_ia32cap_P'
Once in a while you get too comfy and make such blunder. Apologies!
I've used this patch to fix it:
I've settled for http://cvs.openssl.org/chngview?cn=22455.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #2792] Crash in rc4 on x86_64
With fixed in http://cvs.openssl.org/chngview?cn=22455. seems compile ok。
--
qun-ying
- Original Message -
From: zhu qun-ying quny...@yahoo.com
To: openssl-dev@openssl.org openssl-dev@openssl.org
Cc:
Sent: Thursday, April 19, 2012 2:57:05 PM
Subject: Re: [openssl.org #2792] Crash in rc4 on x86_64
I encounter compilation error when compiling for ARM platform wth OpenSSL
1.0.1a:
make -f ../Makefile.shared -e \
APPNAME=openssl OBJECTS=openssl.o verify.o asn1pars.o req.o dgst.o dh.o
dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o
rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o genrsa.o gendsa.o genpkey.o
s_server.o s_client.o speed.o s_time.o apps.o s_cb.o s_socket.o app_rand.o
version.o sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o pkey.o pkeyparam.o
pkeyutl.o spkac.o smime.o cms.o rand.o engine.o ocsp.o prime.o ts.o srp.o
\
LIBDEPS= $LIBRARIES -ldl \
link_app.${shlib_target}
make[2]: Entering directory
`/home/qunying/projs/git/FortiOS_lib/openssl/trunk/apps'
../libcrypto.so: undefined reference to `OPENSSL_ia32cap_P'
--
qun-ying
- Original Message -
From: Andy Polyakov ap...@openssl.org
To: openssl-dev@openssl.org
Cc:
Sent: Thursday, April 19, 2012 1:52:31 PM
Subject: Re: [openssl.org #2792] Crash in rc4 on x86_64
This looks simular to the AES problem with had, with a
length
of 0?
For reference. What was going on was the RC4_set_key was generating
compact key schedule on Intel legacy CPU, while rc4_md5_enc was treating
as non-compact with 32-bit elements. As results it was messed up in such
way that induced crash in *subsequent* call to RC4.
More details are at:
http://bugs.debian.org/666405
http://cvs.openssl.org/chngview?cn=22424 is combined patch.
This fails like this on non-i386/x86_64 arches:
../libcrypto.a(e_rc4_hmac_md5.o): In function
`EVP_rc4_hmac_md5':
/build/buildd-openssl_1.0.1a-1-ia64-b35uCp/openssl-1.0.1a/crypto/evp/e_rc4_hmac_md5.c:294:
undefined reference to `OPENSSL_ia32cap_P'
/build/buildd-openssl_1.0.1a-1-ia64-b35uCp/openssl-1.0.1a/crypto/evp/e_rc4_hmac_md5.c:294:
undefined reference to `OPENSSL_ia32cap_P'
Once in a while you get too comfy and make such blunder.
Apologies!
I've used this patch to fix it:
I've settled for http://cvs.openssl.org/chngview?cn=22455.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: ENGINE reference leak using FIPS-capable OpenSSL
Dr. Stephen Henson wrote:
On Wed, Apr 18, 2012, Erik Tkal wrote:
Any takers? Should I be able to build a FIPS-capable OpenSSL and have some of
the implementation be provided via an ENGINE (e.g. let's say I have a hardware
module to perform AES) but some by the OpenSSL FIPS canister? Or is it truly
all or nothing?
Yes the FIPS capable OpenSSL should behave in a manner similar to non-FIPS
capable OpenSSL when not in FIPS mode, though it currently use the algorithm
implementations in the FIPS module even when not in FIPS mode.
I'll look into it.
Openssl test start to fail after only call FIPS_cipherinit in FIPS
mode - 1.0.{1|2}_stable fips build:
aes-128-cbc
Error setting cipher AES-128-CBC
Error setting cipher AES-128-CBC
cmp: EOF on ./p.aes-128-cbc.clear
Steve.
--
Roumen
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #2771] [BUG] Openssl 1.0.1 times out when connecting to Outlook Exchange 2007
We run a site that uses the F5 Networks BIG-IP load balancer, and OpenSSL 1.0.1 triggers this bug on the load balancer. When it occurs, the load balancer neither forwards the request to a pool member, nor does it respond to the OpenSSL client. There are warning messages in the load balancer's /var/log/ltm file: warning tmm[5313]: 012f0002:4: WARN at ../modules/hudproxy/bigproto/pva/pva_frames.c:1234:Received illegal header padding 100 versus 2ff Working with F5 Networks tech support, we have determined that this is a known issue, which they track as Bug 376483. It is fixed in the recently released BIG-IP LTM 10.2.4 software, though it is not mentioned in their release notes, and I confirm that TLS 1.2 connections no longer hang after upgrading to 10.2.4. Derek Poon University of British Columbia Begin forwarded message: From: F5 Support - Emailclerk c.emailcl...@f5.com Date: April 18, 2012 4:14:42 PM PDT Derek - Thanks for the data. After some pretty extensive research, it appears that while SOL 13037 was resolved as part of your update, you encounted a second known issue where the SSL connection hangs after OpenSSL v.1.0.1's Client Hello because it offered 80 ciphers. [...] This has been listed as Bug 376483, and is reported as having been fixed as of Version 10.2.4. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: ENGINE reference leak using FIPS-capable OpenSSL
On Fri, Apr 20, 2012, Roumen Petrov wrote:
Dr. Stephen Henson wrote:
On Wed, Apr 18, 2012, Erik Tkal wrote:
Any takers? Should I be able to build a FIPS-capable OpenSSL and have some
of the implementation be provided via an ENGINE (e.g. let's say I have a
hardware module to perform AES) but some by the OpenSSL FIPS canister? Or
is it truly all or nothing?
Yes the FIPS capable OpenSSL should behave in a manner similar to non-FIPS
capable OpenSSL when not in FIPS mode, though it currently use the algorithm
implementations in the FIPS module even when not in FIPS mode.
I'll look into it.
Openssl test start to fail after only call FIPS_cipherinit in FIPS
mode - 1.0.{1|2}_stable fips build:
aes-128-cbc
Error setting cipher AES-128-CBC
Error setting cipher AES-128-CBC
cmp: EOF on ./p.aes-128-cbc.clear
Ooops! This should fix it:
http://cvs.openssl.org/chngview?cn=22456
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
