Problems building openssl 1.1.0 under Vista+VS2008
Hello! 1. I believe there are a couple of bugs in cms.h - diff -ur openssl/crypto/cms/cms.h openssl-1.1.0/crypto/cms/cms.h --- openssl/crypto/cms/cms.h 2010-04-07 20:22:01.185601800 +0600 +++ openssl-1.1.0/crypto/cms/cms.h 2010-04-24 12:39:05.350609800 +0600 @@ -56,9 +56,9 @@ #define HEADER_CMS_H #if defined(_WIN64) - define ssize_t __int64 + #define ssize_t __int64 #else - define ssize_t long + #define ssize_t long #endif #include openssl/x509.h diff -ur openssl/inc32/openssl/cms.h openssl-1.1.0/inc32/openssl/cms.h --- openssl/inc32/openssl/cms.h 2010-04-07 20:28:54.606601800 +0600 +++ openssl-1.1.0/inc32/openssl/cms.h 2010-04-24 12:39:26.058680400 +0600 @@ -56,9 +56,9 @@ #define HEADER_CMS_H #if defined(_WIN64) - define ssize_t __int64 + #define ssize_t __int64 #else - define ssize_t long + #define ssize_t long #endif #include openssl/x509.h 2. Fixed that, in the stage of linking I got these errors - Creating library out32dll\libeay32.lib and object out32dll\libeay32.exp pmeth_lib.obj : error LNK2001: unresolved external symbol _cmac_pkey_meth ameth_lib.obj : error LNK2001: unresolved external symbol _cmac_asn1_meth out32dll\libeay32.dll : fatal error LNK1120: 2 unresolved externals NMAKE : fatal error U1077: 'c:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\link.EXE' : return code '0x460' I believe cm_ameth.c and cm_pmeth.c should be added to builds to fix this. P.S. I sent this message before, but I believe it did not arrive. -- Ruslan Gazizov. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Where I can find SHA 1 code (definitions/bodies of SHA1_Init, SHA1_Update, SHA1_Final routines) ?
Hi! I downloaded the openssl-fips-1.2 code. I did find out SHA 256 and SHA 512 code from openssl-fips-1.2\crypto\sha. Unfortunately, I could not find SHA 1 code (definitions/bodies of SHA1_Init, SHA1_Update, SHA1_Final routines) declared on the openssl-fips-1.2\crypto\sha\sha.h file. Anybody can help to point out where they are defined? Thank you in advance, Long Wei
[openssl.org #2250] CVS HEAD: x509_cmp.c bug: error path does not return 0 like it should; strlen() is in the way
Side note:
You may want to ignore the 'const' in the prototype for now; we have an
in-house copy of OpenSSL which is quite severely const-ified and
size_t-ified.
--- h:\prj\1original\openssl\openssl\crypto\x509\x509_cmp.c2010-01-12
19:29:33.0 +-0200
+++ h:\prj\3actual\openssl\crypto\x509\x509_cmp.c2010-05-01
01:39:34.0 +-0200
@@ -79,30 +79,31 @@
#ifndef OPENSSL_NO_MD5
-unsigned long X509_issuer_and_serial_hash(X509 *a)
+unsigned long X509_issuer_and_serial_hash(const X509 *a)
{
unsigned long ret=0;
EVP_MD_CTX ctx;
unsigned char md[16];
char *f;
+size_t l; /* [i_a] for strlen() so 'ret' is not 'damaged' when anyone
decided to 'goto err' ;-) */
EVP_MD_CTX_init(ctx);
f=X509_NAME_oneline(a-cert_info-issuer,NULL,0);
-ret=strlen(f);
+l=strlen(f); /* [i_a] */
if (!EVP_DigestInit_ex(ctx, EVP_md5(), NULL))
goto err;
-if (!EVP_DigestUpdate(ctx,(unsigned char *)f,ret))
+if (!EVP_DigestUpdate(ctx,(unsigned char *)f,l))
goto err;
OPENSSL_free(f);
if(!EVP_DigestUpdate(ctx,(unsigned char
*)a-cert_info-serialNumber-data,
(unsigned long)a-cert_info-serialNumber-length))
goto err;
if (!EVP_DigestFinal_ex(ctx,(md[0]),NULL))
goto err;
ret=(((unsigned long)md[0] )|((unsigned long)md[1]8L)|
((unsigned long)md[2]16L)|((unsigned long)md[3]24L)
)0xL;
-err:
+err:
EVP_MD_CTX_cleanup(ctx);
return(ret);
}
#endif
--
Met vriendelijke groeten / Best regards,
Ger Hobbelt
--
web:http://www.hobbelt.com/
http://www.hebbut.net/
mail: g...@hobbelt.com
mobile: +31-6-11 120 978
--
Side note:You may want to ignore the const in the prototype for now; we have an in-house copy of OpenSSL which is quite severely const-ified and size_t-ified.--- h:\prj\1original\openssl\openssl\crypto\x509\x509_cmp.c 2010-01-12 19:29:33.0 +-0200
+++ h:\prj\3actual\openssl\crypto\x509\x509_cmp.c 2010-05-01 01:39:34.0 +-0200@@ -79,30 +79,31 @@ #ifndef OPENSSL_NO_MD5-unsigned long X509_issuer_and_serial_hash(X509 *a)+unsigned long X509_issuer_and_serial_hash(const X509 *a)
{ unsigned long ret=0; EVP_MD_CTX ctx; unsigned char md[16]; char *f;+ size_t l; /* [i_a] for strlen() so ret is not damaged when anyone decided to goto err ;-) */
EVP_MD_CTX_init(ctx); f=X509_NAME_oneline(a-cert_info-issuer,NULL,0);- ret=strlen(f);+ l=strlen(f); /* [i_a] */ if (!EVP_DigestInit_ex(ctx, EVP_md5(), NULL)) goto err;
- if (!EVP_DigestUpdate(ctx,(unsigned char *)f,ret))+ if (!EVP_DigestUpdate(ctx,(unsigned char *)f,l)) goto err; OPENSSL_free(f); if(!EVP_DigestUpdate(ctx,(unsigned char *)a-cert_info-serialNumber-data,
(unsigned long)a-cert_info-serialNumber-length)) goto err; if (!EVP_DigestFinal_ex(ctx,(md[0]),NULL)) goto err; ret=( ((unsigned long)md[0] )|((unsigned long)md[1]8L)|
((unsigned long)md[2]16L)|((unsigned long)md[3]24L) )0xL;- err:+err: EVP_MD_CTX_cleanup(ctx); return(ret); } #endif
-- Met vriendelijke groeten / Best regards,Ger Hobbelt--web: http://www.hobbelt.com/
http://www.hebbut.net/mail: g...@hobbelt.commobile: +31-6-11 120 978--
x509_cmp_bug1.diff
Description: Binary data
[openssl.org #2251] CVS HEAD: x509v3\v3_pci.c: fix a memleak and a BIO chain leak + couple of realloc check fixes
Bug Fix: See attached diff. -- Met vriendelijke groeten / Best regards, Ger Hobbelt -- web:http://www.hobbelt.com/ http://www.hebbut.net/ mail: g...@hobbelt.com mobile: +31-6-11 120 978 -- Bug Fix:See attached diff.-- Met vriendelijke groeten / Best regards,Ger Hobbelt--web: http://www.hobbelt.com/ http://www.hebbut.net/mail: g...@hobbelt.commobile: +31-6-11 120 978-- x509v3_v3_pci_bug1_2.diff Description: Binary data
[openssl.org #2252] CVS HEAD: bug in BIO_f_buffer.pod: documentation not up to date since 0.9.6b
Changelog says: Changes between 0.9.6a and 0.9.6b [9 Jul 2001] [...] *) In crypto/bio/bf_buff.c, increase DEFAULT_BUFFER_SIZE to 4096 (previously it was 1024). [Bodo Moeller] However, the corresponding .pod hasn't been updated yet. .pod fix/patch attached. Also note that the .pod file has its 'see also' section updated. Side note: The extra 'const' in there I kept; our own copy has quite strict const-correctness and this is one the easy ones that IMO should find it's way into the mainstream after all. -- Met vriendelijke groeten / Best regards, Ger Hobbelt -- web:http://www.hobbelt.com/ http://www.hebbut.net/ mail: g...@hobbelt.com mobile: +31-6-11 120 978 -- Changelog says: Changes between 0.9.6a and 0.9.6b [9 Jul 2001][...] *) In crypto/bio/bf_buff.c, increase DEFAULT_BUFFER_SIZE to 4096 (previously it was 1024). [Bodo Moeller] However, the corresponding .pod hasnt been updated yet..pod fix/patch attached.Also note that the .pod file has its see also section updated.Side note:The extra const in there I kept; our own copy has quite strict const-correctness and this is one the easy ones that IMO should find its way into the mainstream after all. -- Met vriendelijke groeten / Best regards,Ger Hobbelt--web: http://www.hobbelt.com/ http://www.hebbut.net/mail: g...@hobbelt.commobile: +31-6-11 120 978-- BIO_f_buffer_pod_bug1.diff Description: Binary data
[openssl.org #2253] CVS HEAD: err_prn.c: bug: check callback return value so you don't keep hammering BIO_printf() on a failing error BIO.
The callback calls BIO_printf(); it's return value is properly propagated but is not checked in the error chain dumper func; when the errors are streamed through any BIO which fails, such failure hence remains undetected and the BIO is being hammered instead of aborting the error dump. Different behaviour will occur depending on type of failure and target BIO. fix attached. Side note: our own tree also calls BIO_flush to ensure any 'printed' error data does not hang around in any BIO buffers for too long; failures may arrive before a final croak and we'd rather see as much error info as we can get then. Feature patch attached. -- Met vriendelijke groeten / Best regards, Ger Hobbelt -- web:http://www.hobbelt.com/ http://www.hebbut.net/ mail: g...@hobbelt.com mobile: +31-6-11 120 978 -- The callback calls BIO_printf(); its return value is properly propagated but is not checked in the error chain dumper func; when the errors are streamed through any BIO which fails, such failure hence remains undetected and the BIO is being hammered instead of aborting the error dump. Different behaviour will occur depending on type of failure and target BIO. fix attached.Side note: our own tree also calls BIO_flush to ensure any printed error data does not hang around in any BIO buffers for too long; failures may arrive before a final croak and wed rather see as much error info as we can get then. Feature patch attached.-- Met vriendelijke groeten / Best regards,Ger Hobbelt--web: http://www.hobbelt.com/ http://www.hebbut.net/mail: g...@hobbelt.commobile: +31-6-11 120 978-- err_prn_bug1.diff Description: Binary data err_prn_feature2.diff Description: Binary data
[openssl.org #2254] CVS HEAD: engines\ccgost\gost94_keyx.c: bug: i2d call can return error code 0 which isn't caught
fix attached. -- Met vriendelijke groeten / Best regards, Ger Hobbelt -- web:http://www.hobbelt.com/ http://www.hebbut.net/ mail: g...@hobbelt.com mobile: +31-6-11 120 978 -- fix attached.-- Met vriendelijke groeten / Best regards,Ger Hobbelt--web: http://www.hobbelt.com/ http://www.hebbut.net/mail: g...@hobbelt.commobile: +31-6-11 120 978-- gost94_keyx_bug1.diff Description: Binary data
[openssl.org #2255] CVS HEAD: engines\e_ubsec.c bug: variable of RSA-dependent type instantiated outside #ifndef NO_RSA precomp check
fix attached. -- Met vriendelijke groeten / Best regards, Ger Hobbelt -- web:http://www.hobbelt.com/ http://www.hebbut.net/ mail: g...@hobbelt.com mobile: +31-6-11 120 978 -- fix attached.-- Met vriendelijke groeten / Best regards,Ger Hobbelt--web: http://www.hobbelt.com/ http://www.hebbut.net/mail: g...@hobbelt.commobile: +31-6-11 120 978-- e_ubsec_bug1.diff Description: Binary data
[openssl.org #2256] CVS HEAD: question: must this be hardcoded '8' or is it 'md_len' in disguise? :-S
ssl\s3_clnt.c:
since the hash length lands in 'md_len' and the entire hash
would/should/might be used as the IV...
What do the protocol wizards have to say about this?
--- h:\prj\1original\openssl\openssl\ssl\s3_clnt.c2010-02-28
02:24:04.0 +-0200
+++ h:\prj\3actual\openssl\ssl\s3_clnt.c2009-08-24 19:56:01.0
+-0200
@@ -2505,15 +2471,15 @@
EVP_DigestInit(ukm_hash,EVP_get_digestbynid(NID_id_GostR3411_94));
EVP_DigestUpdate(ukm_hash,s-s3-client_random,SSL3_RANDOM_SIZE);
EVP_DigestUpdate(ukm_hash,s-s3-server_random,SSL3_RANDOM_SIZE);
EVP_DigestFinal_ex(ukm_hash, shared_ukm, md_len);
EVP_MD_CTX_destroy(ukm_hash);
if
(EVP_PKEY_CTX_ctrl(pkey_ctx,-1,EVP_PKEY_OP_ENCRYPT,EVP_PKEY_CTRL_SET_IV,
-8,shared_ukm)0) {
+8 /* [i_a] shouldn't this be 'md_len' ? */ ,shared_ukm)0)
{
SSLerr(SSL_F_SSL3_SEND_CLIENT_KEY_EXCHANGE,
SSL_R_LIBRARY_BUG);
goto err;
}
/* Make GOST keytransport blob message */
/*Encapsulate it into sequence */
*(p++)=V_ASN1_SEQUENCE | V_ASN1_CONSTRUCTED;
msglen=255;
--
Met vriendelijke groeten / Best regards,
Ger Hobbelt
--
web:http://www.hobbelt.com/
http://www.hebbut.net/
mail: g...@hobbelt.com
mobile: +31-6-11 120 978
--
ssl\s3_clnt.c:since the hash length lands in md_len and the entire hash would/should/might be used as the IV...What do the protocol wizards have to say about this?--- h:\prj\1original\openssl\openssl\ssl\s3_clnt.c 2010-02-28 02:24:04.0 +-0200
+++ h:\prj\3actual\openssl\ssl\s3_clnt.c 2009-08-24 19:56:01.0 +-0200@@ -2505,15 +2471,15 @@ EVP_DigestInit(ukm_hash,EVP_get_digestbynid(NID_id_GostR3411_94)); EVP_DigestUpdate(ukm_hash,s-s3-client_random,SSL3_RANDOM_SIZE);
EVP_DigestUpdate(ukm_hash,s-s3-server_random,SSL3_RANDOM_SIZE); EVP_DigestFinal_ex(ukm_hash, shared_ukm, md_len); EVP_MD_CTX_destroy(ukm_hash); if (EVP_PKEY_CTX_ctrl(pkey_ctx,-1,EVP_PKEY_OP_ENCRYPT,EVP_PKEY_CTRL_SET_IV,
- 8,shared_ukm)0) {+ 8 /* [i_a] shouldnt this be md_len ? */ ,shared_ukm)0) { SSLerr(SSL_F_SSL3_SEND_CLIENT_KEY_EXCHANGE, SSL_R_LIBRARY_BUG);
goto err; } /* Make GOST keytransport blob message */ /*Encapsulate it into sequence */ *(p++)=V_ASN1_SEQUENCE | V_ASN1_CONSTRUCTED;
msglen=255;-- Met vriendelijke groeten / Best regards,Ger Hobbelt--web: http://www.hobbelt.com/
http://www.hebbut.net/mail: g...@hobbelt.commobile: +31-6-11 120 978--
ssl_s3_clnt_question1.diff
Description: Binary data
[openssl.org #2257] CVS HEAD: [quite probable] bug in ssl3_write: does not indirect through callback like it sibling ssl3_read
ssl3_read() does indirect, while ssl3_write does not.
Doesn't seem intentional to me, on the contrary.
Tick choice:
[ ] Correct reasoning fix?
[ ] Dead wrong, buster!
just in case: patch attached
--- h:\prj\1original\openssl\openssl\ssl\s3_lib.c2009-11-19
02:34:54.0 +-0200
+++ h:\prj\3actual\openssl\ssl\s3_lib.c2009-08-24 19:57:30.0
+-0200
@@ -3223,10 +3224,15 @@
/* The second test is because the buffer may have been removed */
if ((s-s3-flags SSL3_FLAGS_POP_BUFFER) (s-wbio == s-bbio))
{
/* First time through, we write into the buffer */
if (s-s3-delay_buf_pop_ret == 0)
{
+#if 0 /* [i_a] shouldn't this read like below??? */
ret=ssl3_write_bytes(s,SSL3_RT_APPLICATION_DATA,
buf,len);
+#else
+ret=s-method-ssl_write_bytes(s,SSL3_RT_APPLICATION_DATA,
+buf,len);
+#endif
if (ret = 0) return(ret);
--
Met vriendelijke groeten / Best regards,
Ger Hobbelt
--
web:http://www.hobbelt.com/
http://www.hebbut.net/
mail: g...@hobbelt.com
mobile: +31-6-11 120 978
--
ssl3_read() does indirect, while ssl3_write does not.Doesnt seem intentional to me, on the contrary.Tick choice:[ ] Correct reasoning fix?[ ] Dead wrong, buster! just in case: patch attached
--- h:\prj\1original\openssl\openssl\ssl\s3_lib.c 2009-11-19 02:34:54.0 +-0200+++ h:\prj\3actual\openssl\ssl\s3_lib.c 2009-08-24 19:57:30.0 +-0200@@ -3223,10 +3224,15 @@ /* The second test is because the buffer may have been removed */
if ((s-s3-flags SSL3_FLAGS_POP_BUFFER) (s-wbio == s-bbio)) { /* First time through, we write into the buffer */ if (s-s3-delay_buf_pop_ret == 0)
{+#if 0 /* [i_a] shouldnt this read like below??? */ ret=ssl3_write_bytes(s,SSL3_RT_APPLICATION_DATA, buf,len);+#else+ ret=s-method-ssl_write_bytes(s,SSL3_RT_APPLICATION_DATA,
+ buf,len);+#endif if (ret = 0) return(ret); -- Met vriendelijke groeten / Best regards,Ger Hobbelt--
web: http://www.hobbelt.com/ http://www.hebbut.net/mail: g...@hobbelt.commobile: +31-6-11 120 978
--
ssl_s3_lib_bug1.diff
Description: Binary data
Re: [openssl.org #2245] [PATCH] Add /Zi to VC++ CFLAG in debug configuration (1.0.0 and 0.9.8)
Dr. Stephen Henson wrote: That's most peculiar. I've tested 1.0.0-stable with Visual Studio Express 2008. I did the following simple test: Start openssl.exe Start VS express. Select tools-attach to process. Debug-Break All. I get a warning about deadlocked process but it is otherwise OK. I can set breakpoints and source code is displayed. This worked for debug shared and static builds. The non-debug builds didn't show any source and it said there were no symbols. This is working here, too. But... I have some very different directories for OpenSSL source tree (d:\proj.svn\common\openssl-1.0.0), plus for my project code (d:\proj.svn\Training\ssl1\MrFtp) and finally for the installed OpenSSL binaries (aka '--prefix', here it is: C:\tools\OpenSSL). The crazy thing now comes (please kindly keep patience, the solution is also coming at end of the mail): I built OpenSSL 2 times. The first one, with additional /Zi goes to = C:\TOOLS\OpenSSL, The second one, with normal -Zi goes to = C:\temp\OpenSSL, I tried your debug/attach test - it works even for C:\temp\OpenSSL\bin\openssl.exe (no extra /Zi) Then I changed my local project to use -I C:\temp\OpenSSL\include and linker uses c:\temp\OpenSSL\lib. Expecting to _not_ beeing able to jump into ERR_load_BIO_strings(), I am surprised. It works now! Next, I changed back -I C:\TOOLS\OpenSSL\include and linker uses c:\TOOLS\OpenSSL\lib. This is, where I have my /Zi-extra-built installed. Surprisingly, now _this_ version is not able to be debugged anymore! Linker tells: 1Generating Code... 1Linking... 1libeay32.lib(cryptlib.obj) : warning LNK4099: PDB 'out32.pdb' was not found with 'c:\tools\openssl\lib\libeay32.lib' or at 'd:\proj.svn\Training\ssl1\debug\out32.pdb'; linking object as if no debug info 1libeay32.lib(mem.obj) : warning LNK4099: PDB 'out32.pdb' was not found with 'c:\tools\openssl\lib\libeay32.lib' or at 'd:\proj.svn\Training\ssl1\debug\out32.pdb'; linking object as if no debug info 1libeay32.lib(mem_dbg.obj) : warning LNK4099: PDB 'out32.pdb' was not found with 'c:\tools\openssl\lib\libeay32.lib' or at 'd:\proj.svn\Training\ssl1\debug\out32.pdb'; linking object as if no debug info The files out32.pdb / out32dll.pdb are still laying around in d:\proj.svn\common\openssl-1.0.0. Should this be the reason? wrong location of *.pdb files? I copied them into c:\TOOLS\OpenSSL\lib and my projects d:\proj.svn\Training\ssl1\debug folders. No help - linker is complaining they are not referring to the *right* library: 2Generating Code... 2Linking... 2libeay32.lib(cryptlib.obj) : warning LNK4204: 'd:\proj.svn\Training\ssl1\debug\out32.pdb' is missing debugging information for referencing module; linking object as if no debug info 2libeay32.lib(mem.obj) : warning LNK4204: 'd:\proj.svn\Training\ssl1\debug\out32.pdb' is missing debugging information for referencing module; linking object as if no debug info If I understand this right, without the extra /Zi, the _location_ and the _content_ of out32*.pdb files is very important. To give the final proof, I again built the whole OpenSSL with my default --prefix=c:\TOOLS\OpenSSL, but this time /without/ the extra /Zi. Then again recompiled and started my training project ... now the debugging again works. _Conclusion_: With standard build rules (configure, make, test, install) _without_ a patched '\util\pl\VC-32.pl', VS2005 debugging _is_ working for both process attach and Run/Debug-in-single-Steps. But only if some more prerequisites are kept in mind: * source directory tree (where INSTALL.W32 resides) shall not be cleaned or removed after successfully run of 'make install' * this source directory must contain out32[dll].pdb * out32[dll].pdb must be created together with the same make configure make install call, which created your [prefix]\include and [prefix]\lib directories and content * your C project needs to include exactly the mentioned [prefix]\include and [prefix]\lib components, because its path seems to be encoded in out32[dll].pdb and vice versa. _Conclusion_ II: With standard build rules (configure, make, test, install) _plus_ a patched '\util\pl\VC-32.pl' (added /Zi), VS2005 debugging _is_ working for both process attach and Run/Debug-in-single-Steps, without some of the prerequisites mentioned above. The PDB files are neither in the openssl directory nor in the [prefix] directory. But debuging works. puh, long tests, long mail, short conclusions. Hope this helps for somebody, Modem Man __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
