[openssl.org #2278] Incomplete fix for type-checking/casting issue
The following commit fixes an type checking/casting issue in the SKM_ASN1_SET_OF_i2d macro http://cvs.openssl.org/filediff?f=openssl/crypto/stack/safestack.hv1=1.72.2.5v2=1.72.2.6 However, the SKM_ASN1_SET_OF_d2i needs a similar fix too: $ diff -u openssl/safestack.h.orig openssl/safestack.h --- openssl/safestack.h.orig2010-05-18 18:12:20.0 +0200 +++ openssl/safestack.h 2010-05-27 08:31:56.905596266 +0200 @@ -179,7 +179,7 @@ sk_is_sorted(CHECKED_STACK_OF(type, st)) #defineSKM_ASN1_SET_OF_d2i(type, st, pp, length, d2i_func, free_func, ex_tag, ex_class) \ - (STACK_OF(type) *)d2i_ASN1_SET(CHECKED_STACK_OF(type, st), \ + (STACK_OF(type) *)d2i_ASN1_SET((STACK_OF(OPENSSL_BLOCK) **)CHECKED_STACK_OF(type, st), \ pp, length, \ CHECKED_D2I_OF(type, d2i_func), \ CHECKED_SK_FREE_FUNC(type, free_func), \ --- openssl/safestack.h.orig 2010-05-18 18:12:20.0 +0200 +++ openssl/safestack.h 2010-05-27 08:31:56.905596266 +0200 @@ -179,7 +179,7 @@ sk_is_sorted(CHECKED_STACK_OF(type, st)) #define SKM_ASN1_SET_OF_d2i(type, st, pp, length, d2i_func, free_func, ex_tag, ex_class) \ - (STACK_OF(type) *)d2i_ASN1_SET(CHECKED_STACK_OF(type, st), \ + (STACK_OF(type) *)d2i_ASN1_SET((STACK_OF(OPENSSL_BLOCK) **)CHECKED_STACK_OF(type, st), \ pp, length, \ CHECKED_D2I_OF(type, d2i_func), \ CHECKED_SK_FREE_FUNC(type, free_func), \ smime.p7s Description: S/MIME cryptographic signature
[openssl.org #2269] ENGINE_register_complete() seems to ignore OPENSSL_NO_RAND
The only reference I can find to OPENSSL_NO_RAND is in crypto/dh/dh_key.c and it shouldn't really be in there. There isn't an option to compile OpenSSL without a PRNG as just about everything uses it. 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
[openssl.org #2260] Problems with smime
[claes.west...@tieto.com - Thu May 06 17:32:44 2010]: Hello! I am trying to create a S/MIME document that is sent as a base64 coded data element to a web service. When the server side decodes the base64 and then tries to verify the document they get an error message. faultstring=invalid signature format in message: + content hash found in signedattributes different On the serverside the ues a Java package from Bouncy Castle. I am using openssl version 0.9.7a Feb 19 2003 on a RedHat server. This is not the latest RedHat version. The command that I use is openssl smime -sign -in $TEMPIN -signer /usr/mumps/apo/cert/sws_sign_v3.pem -ink ey /usr/mumps/apo/cert/sws_sign_v3.key -certfile /usr/mumps/apo/cert/SITHS_CA_v3 .cer -outform SMIME -out $TEMPOUT1 TEMPIN is the actual document which includes the part1 header. I have replaced all the LF linebreaks whith CRLF. Does anybody recognize this problem? And is there a solution to it? Is it worth while trying to get a later version of openssl? That is an ancient version of OpenSSL. It is worth upgrading anyway as there are many bugs and security issues fixed since that version. The actual error message indicates that the content received doesn't match what it expects from the hash. This could be a line translation issue. What happens with the -binary command line switch? This should go to openssl-users and not the request tracker.. marking ticket as resolved. 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
Version control
On Wed, 2010-05-26 at 21:32 +0200, Ger Hobbelt wrote: Those [i_a] bits are my markers in our local code base so I know which edits are mine when doing a (manual) merge with 'vanilla' CVS HEAD. Yes, I know there are smarter systems around, but I've been 'tracking' OpenSSL for almost a decade and tools available to me haven't always been smart enough to ensure I didn't lose local edits across upgrades. And drilling down the RCS database for every edit isn't fun nor fast like that. So marking has become a habit by now. Often accompanied with a short text about the 'why' or related info. Sorry, wasn't meant to be bothersome to you. None of the existing CVS-git import tools handle the OpenSSL repository correctly -- they all do strange things on branches. But for HEAD, they should work OK. I'd be very happy to work on fixing that, if there's a real prospect of OpenSSL actually changing over to using such a git repository once it exists. I think that would make life a _lot_ easier for anyone working on OpenSSL. Git is portable enough, and a git server can offer cvspserver access for users who are resolutely stuck in the 20th century. -- dwmw2 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Version control
David Woodhouse wrote: On Wed, 2010-05-26 at 21:32 +0200, Ger Hobbelt wrote: Those [i_a] bits are my markers in our local code base so I know which edits are mine when doing a (manual) merge with 'vanilla' CVS HEAD. Yes, I know there are smarter systems around, but I've been 'tracking' OpenSSL for almost a decade and tools available to me haven't always been smart enough to ensure I didn't lose local edits across upgrades. And drilling down the RCS database for every edit isn't fun nor fast like that. So marking has become a habit by now. Often accompanied with a short text about the 'why' or related info. Sorry, wasn't meant to be bothersome to you. None of the existing CVS-git import tools handle the OpenSSL repository correctly -- they all do strange things on branches. But for HEAD, they should work OK. So far we have not seen technical problems when last tested. I'd be very happy to work on fixing that, if there's a real prospect of OpenSSL actually changing over to using such a git repository once it exists. I think that would make life a _lot_ easier for anyone working on OpenSSL. Internal discussion about which version control system to use in the future have not yet been completed. Best regards, Lutz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Version control
On Thu, 2010-05-27 at 17:51 +0200, Lutz Jaenicke wrote: David Woodhouse wrote: On Wed, 2010-05-26 at 21:32 +0200, Ger Hobbelt wrote: Those [i_a] bits are my markers in our local code base so I know which edits are mine when doing a (manual) merge with 'vanilla' CVS HEAD. Yes, I know there are smarter systems around, but I've been 'tracking' OpenSSL for almost a decade and tools available to me haven't always been smart enough to ensure I didn't lose local edits across upgrades. And drilling down the RCS database for every edit isn't fun nor fast like that. So marking has become a habit by now. Often accompanied with a short text about the 'why' or related info. Sorry, wasn't meant to be bothersome to you. None of the existing CVS-git import tools handle the OpenSSL repository correctly -- they all do strange things on branches. But for HEAD, they should work OK. So far we have not seen technical problems when last tested. That's interesting. What tool were you testing? I've had issues with both cvs2git and git-cvsimport. My normal reaction in dealing with _any_ project which uses a legacy version control system (cvs,svn,hg,bzr,etc) is to mirror it into git so that I can deal with it sensibly. OpenSSL has so far resisted my efforts, which is one of the reason I find it a PITA to deal with. -- dwmw2 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
