[openssl.org #1497] Issue: PKCS#12 export with empty password produces incorrect encoding of MacData in PFX object
openssl pkcs12 -export -in _.pem -nodes -out _.p12 generates PFX DER data with MacData in which empty password is used incorrectly, violating following quote from Chapter B, section B.2, item 3 of PKCS#12 standard [1]: Note that if the password is the empty string, then so is P. However, I verified that openssl uses 2-byte BMPString 00 00 in hex notation when preparing a string to be hashed. Correct implementation is to use zero-length BMPString for an empty password. I believe that openssl can read correct formatting of PKCS#12, i.e. it understands both formats, so the problem is limited to export. Another name of this problem is ' NULL v.s. '. [1] ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/pkcs-12v1.pdf Thank you. The tail of make report is attached. I didn't attach the whole thing, since I think the issue is s design issue. ... OpenSSL self-test report: OpenSSL version: 0.9.8d Last change: Introduce limits to prevent malicious keys being able t... Options: -mcpu=pentium no-camellia no-gmp no-krb5 no-mdc2 no-rc5 no-shared no-zlib no-zlib-dynamic OS (uname): Linux tcm 2.6.18-mh1aj #8 PREEMPT Sun Sep 24 00:26:08 PDT 2006 i686 i686 i386 GNU/Linux OS (config): i686-whatever-linux2 Target (default): linux-elf Target: linux-elf Compiler: Using built-in specs. Target: i386-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=i386-redhat-linux Thread model: posix gcc version 4.1.0 20060304 (Red Hat 4.1.0-3) Test passed. Test report in file testlog I also filed http://rt.openssl.org/Ticket/Display.html?ShowHeaders=1id=1496 first by mistake. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1498] OpenSSL 0.9.8e Fatal Error on make
This transaction appears to have no content Hi,I am trying to install openssl-0.9.8e on Solaris v10 12/06. I got Fatal error when I build OpenSSL by running make command.I attached the output of ./config and make (config_log.txt and make_log.txt).Could you please advice me what should I do?Shouldyouhaveanyqueries,pleasefeelfreetocallmeat2608-6220.Regards,EmersSoftwareSpecialistAutomatedSystems(HK)LimitedTel.:(852)2608-6220Fax:(852)2608-6566Add.:15/F,TopsailPlaza,11OnSumStreet,Shatin,NT,HongKongVisitusat:http://www.asl.com.hkThis is a PRIVATE message. If you are not the intended recipient please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. config_log.txt Description: Binary data make_log.txt Description: Binary data
Re: [patch] Valgrind complaining about unitialized data
Yes, it's desirable that that data is unknown however there is a compromise possible: Complement the area. It'll mean valgrind will only complain at the correct place, or possibly not at all, and it's still random. The performance hit from doing that will be so small it won't matter. This annoyed me as well - the big advantage of valgrind is that it doesn't require recompilation to work and it's really good if you don't have to wade through all the flase alarms before you can find the real problems. Peter Stefan Neis [EMAIL PROTECTED] line.de To Sent by: openssl-dev@openssl.org owner-openssl-dev cc @openssl.org Subject Re: [patch] Valgrind complaining 02/03/07 07:53 PM about unitialized data Please respond to openssl-dev Hi, I'd also like to speak up on behalf of the **vast** majority. They don't want unnecessary zeroing of memory in frequently executed code paths (for which the only reason is to satisfy an infrequently executed testing environment that valgrind provides). Those wanting to run valgrind WITH OpenSSL -DPURIFY is provided. Maybe more importantly (at least from my POV), if you're looking for random bytes, using uninitialized memory (assuming the OS or C runtime doesn't initialize it anyway) instead of something always initialized to the same fixed sequence of bytes actually might be a good idea - or did I misunderstand something? Regards, Stefan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Openssl 0.9.9 release
Hi All, I was looking for EAP-FAST support in openssl library. In the mail list I found a patch. Patch was distributed for openssl-0.9.8. And I also found some mails stating EAP-FAST support will be added in openssl-0.9.9.I have few queries now. I. Will EAP-FAST support will be added in openssl-0.9.9? II.When openssl-0.9.9 likely to be realsed. II.We are using openssl-0.9.8a version now. Can I use the patch for this library? III.Is it legal to use this patch for the openssl library used in the commercial products? Any help is appreciated. Regards, Jaya. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1455] inconsistant behaviour when using s_client with and without -pause option
Hello, I am also encountering the behaviour described in http://rt.openssl.org/Ticket/Display.html?id=1455 I'd like help fixing this bug, maybe by providing Logs or Network Traffic dumps - would somebody with OpenSSL developement experience be kind enough to consider looking into this bug? It's kind of a show stopper for me... I'd say the problem has to be located somewhere around where sleep(1) occurs in the read- and write-functions (ssl/s2_pkt.c) but I don't have enough experience to know how the buffers are handled and what is done exactly... bye Christian PS: I already posted concerning this bug some days ago - Subject Weird OpenSSL behaviour on connecting to W2k3-LDAPS [LONG] posted on 16.02.07. You can find some log output there... -- Christian Margmail: mailto:[EMAIL PROTECTED] Rechenzentrum TU Clausthalweb : http://www.rz.tu-clausthal.de D-38678 Clausthal-Zellerfeld fon : 05323/72-2043 Germany ICQ : on request signature.asc Description: OpenPGP digital signature
Re: adding a reference count to SSL_CTX
One can omit the SSL_CTX_free but in oder to be clean, someone must call it, and this may unfortunately not necessarily be the same instance who created it. I think you are kind of right, but there's another possibility. Does the other instance call SSL_free as well? Note that SSL_free also calls SSL_CTX_free, so I suspect your call to SSL_CTX_free is not needed (except in by whoever called SSL_CTX_new). Consider how you would make it work if you had three SSL objects sharing the same SSL_CTX. __Martin __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
TLS extension support
Hi All, Can any one tell me when SessionTicket TLS Extension support will be included in openssl library? Thanks in advance. Regards, Jaya. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1497] Issue: PKCS#12 export with empty password produces incorrect encoding of MacData in PFX object
[EMAIL PROTECTED] - Fri Mar 02 09:58:13 2007]: openssl pkcs12 -export -in _.pem -nodes -out _.p12 generates PFX DER data with MacData in which empty password is used incorrectly, violating following quote from Chapter B, section B.2, item 3 of PKCS#12 standard [1]: Note that if the password is the empty string, then so is P. However, I verified that openssl uses 2-byte BMPString 00 00 in hex notation when preparing a string to be hashed. Correct implementation is to use zero-length BMPString for an empty password. I believe that openssl can read correct formatting of PKCS#12, i.e. it understands both formats, so the problem is limited to export. Another name of this problem is ' NULL v.s. '. [1] ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/pkcs-12v1.pdf As I recall this was a compatibility issue. A zero-length password is interpreted as a valid password by some implementations resulting in a double NULL but as empty by others. OpenSSL chose the option for maximum interoperability. On parsing a file it does try both versions and uses whichever produces the correct MAC. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: adding a reference count to SSL_CTX
On Fri, 02 Mar 2007 07:58:14 +, Darryl Miles said: Delivered-To: openssl-dev-l@master.openssl.org Delivered-To: openssl-dev@openssl.org Martin Simmons wrote: On Thu, 01 Mar 2007 11:40:24 +0100, Peter Sylvester said: The crtl function basically would do: CRYPTO_add(ctx-references,1,CRYPTO_LOCK_SSL_CTX) assuming that calling this directly in the application is not an external interface. I think you are kind of right, but there's another possibility. Does the other instance call SSL_free as well? Note that SSL_free also calls SSL_CTX_free, so I suspect your call to SSL_CTX_free is not needed (except in by whoever called SSL_CTX_new). Consider how you would make it work if you had three SSL objects sharing the same SSL_CTX. No. Thats now how reference counting works. If you called a SSL_FOOBAR_new() function which creates a new object and increments the reference counter. Then its also your responsibility to call SSL_FOOBAR_free() to revert that increment. Sorry, I couldn't decide who that No was addressed to. Maybe we are just agreeing -- since there was only one call to SSL_CTX_new in the userapp, there should only be one call to SSL_CTX_free in the userapp. You are correct SSL_free() also calls SSL_CTX_free() but this is only to counteract the increment SSL_new() made on the SSL_CTX * it was passed. Yes, I know, but that was not the problem raised by the OP. The OP's problem was that he is making a second reference to the SSL_CTX without incrementing the reference count (because there is no API to incrementing it!). That is not ideal, because it forces the userapp to have its own mechanism for tracking its references to SSL_CTX, in order to call SSL_CTX_free only once. __Martin __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [patch] Valgrind complaining about unitialized data
Peter Waltenberg wrote: Yes, it's desirable that that data is unknown however there is a compromise possible: Complement the area. It'll mean valgrind will only complain at the correct place, or possibly not at all, and it's still random. The performance hit from doing that will be so small it won't matter. This annoyed me as well - the big advantage of valgrind is that it doesn't require recompilation to work and it's really good if you don't have to wade through all the flase alarms before you can find the real problems. Not being a valgrind user... I do not see that leaving this area uninitialized will give us some cryptographically useful amount of entropy so that we could as well memset it to 0... Regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [patch] Valgrind complaining about unitialized data
Can't someone just create a valgrind suppression entry for this? Valgrind can read a file that tells it things to ignore, like lint's old NOTREACHED comment. /r$ -- STSM Senior Security Architect DataPower SOA Appliances __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [patch] Valgrind complaining about unitialized data
Darryl Miles [EMAIL PROTECTED] writes: [...] So the -DPURIFY kills the only known source of uninitialized data warnings in the OpenSSL project that has been reported todate. There's another little one in RAND_load_file. If the function is given a non-NULL file that doesn't exist, it still does /* If the state fails, put some crap in anyway */ RAND_add(sb,sizeof(sb),0.0); for the (uninitialised) struct stat sb. So I suggest an #ifndef PURIFY around that. (Or, I guess, if PURIFY is defined, initialise sb.) [...] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [patch] Valgrind complaining about unitialized data
Richard Salz wrote: Can't someone just create a valgrind suppression entry for this? Valgrind can read a file that tells it things to ignore, like lint's old NOTREACHED comment. Valgrind reports at the point of use where it considers the usage potentially harmful. This means you can copy around uninitalized data within your program all day long, but it is only at the point you pass that data to a libc function or system call that a warning is emitted. It is that call which is emitted in the valgrind output (not the original source of the initialized data, the OpenSSL #ifdef PURIFY code). Most of the time the source is close to the usage so this method of reporting works well for most error. But Random data has its own voodoo, like in being copied somewhere ready for use at startup then at a seemingly random point in time the program decides to pick it up and make use of it. So the valgrind warning you see is the symptom not the problem and this disconnection of events is what can cause confusion. Maybe valgrind should have a rule put in place which resets the uninitialized data bit in the memory bitmap over the block of data returned by the low level RAND_() functions provided by OpenSSL. Darryl __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: adding a reference count to SSL_CTX
On Fri, 02 Mar 2007 13:21:18 +0100, Peter Sylvester said: One can omit the SSL_CTX_free but in oder to be clean, someone must call it, and this may unfortunately not necessarily be the same instance who created it. OK, so a less hacky solution using the current APIs would be to do your own reference counting and only call SSL_CTX_free when your count goes to 0. __Martin I think you are kind of right, but there's another possibility. Does the other instance call SSL_free as well? Note that SSL_free also calls SSL_CTX_free, so I suspect your call to SSL_CTX_free is not needed (except in by whoever called SSL_CTX_new). Consider how you would make it work if you had three SSL objects sharing the same SSL_CTX. __Martin __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Openssl 0.9.9 release
This belongs on openssl-users, not openssl-dev. I. I don't have the precise information, but I think it likely will be if it was a project committer who stated it will be. II. Your guess is as good as mine. III. If it applies, compiles, and functions then there shouldn't be a problem. It is always recommended that you use the latest version though (0.9.8a had a critical security vulnerability in its handling of RSA key lengths, if I remember correctly). IV. Does the patch itself have any license text associated? If not, custom has been to assume that it can be used under the same license as the library that it is applied to; you would have to ask the originator of the patch for absolute certainty, but if it is included in the distribution that distribution version will be distributed under the same license as the current version in the absence of any statement to the contrary. I am not a lawyer, I am not a project team member, I cannot give legal advice, if you need legal advice talk to an attorney. These statements are my own and are not endorsed by the OpenSSL project team, I do not claim to speak for anyone else at all. (and I have to include this particular disclaimer line because you specifically used the word 'legal' in your final question.) -Kyle H On Mar 2, 2007, at 2:43 AM, Bhat, Jayalakshmi Manjunath wrote: Hi All, I was looking for EAP-FAST support in openssl library. In the mail list I found a patch. Patch was distributed for openssl-0.9.8. And I also found some mails stating EAP-FAST support will be added in openssl-0.9.9.I have few queries now. I. Will EAP-FAST support will be added in openssl-0.9.9? II.When openssl-0.9.9 likely to be realsed. II.We are using openssl-0.9.8a version now. Can I use the patch for this library? III.Is it legal to use this patch for the openssl library used in the commercial products? Any help is appreciated. Regards, Jaya. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [patch] Valgrind complaining about unitialized data
Maybe valgrind should have a rule put in place which resets the
uninitialized data bit in the memory bitmap over the block of data
returned by the low level RAND_() functions provided by OpenSSL.
Yes, exactly my point.Until someone enhances valgrind, however,
something like this might work well:
{
RAND_bytes1
Memcheck: Value1
/* notused */
RAND_bytes
}
and repeat that four times with 2, 4, 8, 16 replacing the two 1's.
I betcha that catches almost all problems; at least within OpenSSL.
/r$
--
STSM
Senior Security Architect
DataPower SOA Appliances
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Bug in DSA_generate_parameters_ex in 20070227 snapshot
In dsa_gen.c:
for (i = qsize-1; i = 0; i--)
{
buf[i]++;
if (buf[i] != 0)
break;
}
i is a size_t, so the expression i = 0 is always true. If the value
of seed is 0xFF...FF, the break will never be triggered either, and
it will modify memory after seed.
Test case:
int main()
{
DSA* dsa = DSA_new();
unsigned char seed[20] = { 0 };
memset(seed, 0xFF, 20);
DSA_generate_parameters_ex(dsa, 1024, seed, sizeof(seed), 0, 0, 0);
}
Under valgrind (after compiling with -DPURIFY) the error is visible:
==27347== 1 errors in context 1 of 1:
==27347== Conditional jump or move depends on uninitialised value(s)
==27347==at 0x40C583: dsa_builtin_paramgen (in
/home/jack/sources/openssl-SNAP-20070227/dsa_gen)
==27347==by 0x40CBD5: DSA_generate_parameters_ex (in
/home/jack/sources/openssl-SNAP-20070227/dsa_gen)
==27347==by 0x401764: main (dsa_gen.c:283)
Adding
seed[19] = 0xFE;
before the call to DSA_generate_parameters_ex allows the loop to exit
before it walks off the end, and no error shows up under valgrind.
-Jack
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
[openssl.org #1499] Uninitialized value in RAND_load_file, with -DPURIFY
If RAND_load_file is called with a non-NULL file which does not exist, then it still does: i=stat(file,sb); /* If the state fails, put some crap in anyway */ RAND_add(sb,sizeof(sb),0.0); if (i 0) return(0); And sb may well be uninitialized. Obviously that's of no consequence normally, but it can provide irritating noise if one's trying to track down real issues in an application, so I suggest it not happen if PURIFY is defined. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1499] Uninitialized value in RAND_load_file, with -DPURIFY
Guessing on the stack being non-predictable does not seem to improve entropy too much to me. I have therefore modified the code to no longer use uninitialized memory in any case. Not relying on -DPURIFY will also make valgrind users happy :-) Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Bug in DSA_generate_parameters_ex in 20070227 snapshot
Jack Lloyd wrote:
In dsa_gen.c:
for (i = qsize-1; i = 0; i--)
{
buf[i]++;
if (buf[i] != 0)
break;
}
i is a size_t, so the expression i = 0 is always true.
true ... 'i' is now a 'int' again.
Thanks,
Nils
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: [CVS] OpenSSL: openssl/crypto/rand/ rand_lib.c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello Lutz,
why not...
Lutz Jaenicke wrote:
patch -p0 '@@ .'
Index: openssl/crypto/rand/rand_lib.c
$ cvs diff -u -r1.16 -r1.17 rand_lib.c
--- openssl/crypto/rand/rand_lib.c 30 Jan 2003 17:39:23 - 1.16
+++ openssl/crypto/rand/rand_lib.c 2 Mar 2007 17:54:51 - 1.17
@@ -154,6 +154,7 @@
int RAND_bytes(unsigned char *buf, int num)
{
const RAND_METHOD *meth = RAND_get_rand_method();
if (meth meth-bytes)
return meth-bytes(buf,num);
+ memset(buf, 0, num);
return(-1);
@@ -162,6 +163,7 @@
int RAND_pseudo_bytes(unsigned char *buf, int num)
{
const RAND_METHOD *meth = RAND_get_rand_method();
if (meth meth-pseudorand)
return meth-pseudorand(buf,num);
+ memset(buf, 0, num);
return(-1);
This way memset() will only be called in error case.
In the normal case the (not needed) memset will
not waste processor cycles...
This is a workaround for people that use debuging tools
that generate results they can't understand.
Bye
Goetz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
iD8DBQFF6IG82iGqZUF3qPYRAsxeAKCD8YmCuSeZtWafatkPzTucLfeJEACfQZks
IYF84gloJki7bH4uYidlbrs=
=P0Kp
-END PGP SIGNATURE-
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1497] Issue: PKCS#12 export with empty password produces incorrect encoding of MacData in PFX object
Stephen Henson via RT wrote: [EMAIL PROTECTED] - Fri Mar 02 09:58:13 2007]: openssl pkcs12 -export -in _.pem -nodes -out _.p12 generates PFX DER data with MacData in which empty password is used incorrectly, violating following quote from Chapter B, section B.2, item 3 of PKCS#12 standard [1]: Note that if the password is the empty string, then so is P. However, I verified that openssl uses 2-byte BMPString 00 00 in hex notation when preparing a string to be hashed. Correct implementation is to use zero-length BMPString for an empty password. I believe that openssl can read correct formatting of PKCS#12, i.e. it understands both formats, so the problem is limited to export. Another name of this problem is ' NULL v.s. '. [1] ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/pkcs-12v1.pdf As I recall this was a compatibility issue. A zero-length password is interpreted as a valid password by some implementations resulting in a double NULL but as empty by others. OpenSSL chose the option for maximum interoperability. On parsing a file it does try both versions and uses whichever produces the correct MAC. Thank you for the reply. Would it be time to re-consider the issue again and perhaps consider using correct format, given that many applications that expected incorrect format, Internet Explorer for example, have been since fixed? Thank you. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Weird OpenSSL behaviour on connecting to W2k3-LDAPS [LONG]
Christian Marg wrote: Hello, Since noone on the openssl-users list could help, I'm trying this list for help. In http://marc.theaimsgroup.com/?l=openssl-usersm=116111352610602w=2 Geert Van Muylem reports a similar problem but didn't get a response, so I just repost this issue along with my findings. = = Short form: = I can't connect to my Active Directory Server's LDAPS-Port due to an SSL handshake failure. I can reproduce the following using some different Versions and Builds (Windows, FreeBSD, Solaris, Linux) of OpenSSL. openssl s_client -connect windowsserver.fqdn:636 -CAfile /etc/ldap-certs gives me a handshake failure: === 65580:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s23_lib.c:226: === If I add either of the -debug, -pause, -ssl2 command line switches the connection is established fine... could you reproduce the problem if you log the traffic wit ssldump ? Cheers, Nils __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [patch] Valgrind complaining about unitialized data
On Fri, Mar 02, 2007 at 02:06:09PM +1100, Erik de Castro Lopo wrote: Hi all, I'm working with version 0.9.8c distributed as part of Ubuntu but I have also veryfied that the same problem exists with the latest release 0.9.8e. Please see: http://www.mail-archive.com/openssl-dev@openssl.org/msg21156.html In Debian, since version 0.9.8b-1 those 2 calls are being commented out. I don't know what Ubuntu did to the openssl package, but I assume they still base it on Debian's version. So I can only wonder why Ubuntu's 0.9.8c doesn't have this. Anyway, the memset() you add does remove the warning in some cases. The first place the unintialised values get used is in those MD_Update() calls. There are other places in the code that also call it with an unintialised buffer. I've ran all the regression test thru valgrind, using the memset() solves most of those. As far as I know, commenting out those 2 calls solved all the warnings valgrind reported. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [patch] Valgrind complaining about unitialized data
Lutz Jaenicke wrote: Lutz Jaenicke wrote: Peter Waltenberg wrote: Yes, it's desirable that that data is unknown however there is a compromise possible: Complement the area. It'll mean valgrind will only complain at the correct place, or possibly not at all, and it's still random. The performance hit from doing that will be so small it won't matter. This annoyed me as well - the big advantage of valgrind is that it doesn't require recompilation to work and it's really good if you don't have to wade through all the flase alarms before you can find the real problems. Not being a valgrind user... I do not see that leaving this area uninitialized will give us some cryptographically useful amount of entropy so that we could as well memset it to 0... Ok, I have just applied the patch to 0.9.8-stable and 0.9.9-dev. Oi. Don't do that. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
