Re: [openssl-dev] GOST89 cipher control command
Hello OpenSSL team, Any recommendations? Thank you! On Mon, May 25, 2015 at 10:40 PM, Dmitry Belyavsky beld...@gmail.com wrote: Hello Openssl team, GOST89 cipher algorithm seems to be the only cipher algorithm supporting more than one sets of S-boxes. Current implementation of the GOST89 cipher provided by the ccgost engine does not allow to specify usage of particular S-boxes for a particular EVP_CIPHER_CTX instance. If I understand correctly, the only way to do it is to specify a ctrl-command and implement it in the engine. Is it OK to reuse EVP_CTRL_INIT ctrl command for this purpose or it will be better to add a special value for this? Thank you! -- SY, Dmitry Belyavsky -- SY, Dmitry Belyavsky ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3876] [PATCH] Do not complain if config file not found
Hello all, Some engines configure themselves using config, so absence of config can mean non-functional engine. On Thu, May 28, 2015 at 3:36 PM, Short, Todd via RT r...@openssl.org wrote: The parameters in the configuration file, in general, apply only to certificate operations. The openssl application does way more than certificate operations, and seeing a warning for a configuration file that has no impact on the operation being performed is annoying. Rather than completely remove the warning, I would instead suggest that the warning only be issued for certain commands that may use parameters from the configuration file. -- -Todd Short // tsh...@akamai.commailto:tsh...@akamai.com // “One if by land, two if by sea, three if by the Internet. On May 28, 2015, at 8:19 AM, Blumenthal, Uri - 0553 - MITLL u...@ll.mit.edumailto:u...@ll.mit.edu wrote: If I want and expect openssl to use a config file, and it did not find it - it's darn useful for me to be informed of that fact by openssl. - Original Message - From: Rich Salz via RT [mailto:r...@openssl.org] Sent: Wednesday, May 27, 2015 08:44 PM To: tsh...@akamai.commailto:tsh...@akamai.com tsh...@akamai.commailto: tsh...@akamai.com Cc: openssl-dev@openssl.orgmailto:openssl-dev@openssl.org openssl-dev@openssl.orgmailto:openssl-dev@openssl.org Subject: [openssl-dev] [openssl.orghttp://openssl.org #3876] [PATCH] Do not complain if config file not found Because it goes ahead and proceeds. Not it is explicit testing ENOTFOUND. It should either error+exit or not complain. I can be convinced the current behavior is useful. -- Rich Salz, OpenSSL dev team; rs...@openssl.orgmailto:rs...@openssl.org ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- SY, Dmitry Belyavsky ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3621] Support legacy CA removal, ignore unnecessary intermediate CAs in SSL/TLS handshake by default
On Fri May 29 05:40:51 2015, raysat...@yahoo.com wrote: On 5/27/2015 4:21 AM, Matt Caswell via RT wrote: On Wed May 27 06:41:51 2015, raysat...@yahoo.com wrote: On 3/16/2015 5:45 AM, Kai Engert via RT wrote: Thank you very much for your work on this issue! In my testing so far, it works as requested. I noticed the code changes in x509_vfy.c apply fine on top of the 1.0.2 stable branch, and the test suite succeeeds. Will you consider to add this enhancement in a feature release on the 1.0.2 branch? I second this. It looks like this is also discussed in bug #2634 where it was considered an enhancement and therefore will not be in 1.0.2. It seems more like a bug fix to me though. If OpenSSL can complete the chain it should. What would be the disadvantage of doing so? This issue is now being treated as a bug fix and the fix was already applied to the 1.0.2 tree a while ago (and therefore will appear in the next 1.0.2 release). A backport for 1.0.1 also exists but has not yet hit the repo. Matt Thanks Matt. TRUSTED_FIRST flag has been brought up a few times on curl-library and we are wondering what would be the disadvantages if we added it to our default flags? Also, the alt chain check in x509_vfy.c isn't done if TRUSTED_FIRST and I'm having trouble grasping why that is. Why not check for alternate chains regardless of whether or not you're checking trusted store first? From 1.0.2b onwards OpenSSL will support three different strategies for achieving the goal of building a valid certificate chain: 1) Old style 2) Trusted first 3) Alt chains With old style (all current versions of OpenSSL) we start with the peer provided certificate, then we add as many certificates to the chain as we can from the list provided by the peer. Finally we add as many as we can from the trusted certificate store. If we end up with a valid chain then we have been successful. From 1.0.2 we additionally support the trusted first strategy (although this is not the default). In this strategy we start with the peer provided certificate and then see if we can add certificates from the trusted store to build a chain. If we can then great - we're done. Otherwise we add a certificate from the peer provided list and then check the trusted store again, and so on until we have either found a chain or run out of peer provided certificates to add. We considered making trusted first the default strategy however there is a problem with this. The trusted store logic will cache certificates that we look up. However we only cache *success* but not *failure*. Therefore there is a potential performance hit every time we go through the trusted store but fail to find any certificates. The trusted first strategy could end up doing this a lot. Its unclear exactly how big this performance hit is - but that is the reason why we were wary of making this the default. From 1.0.2b we will also support the alt chains strategy (and this will be the default). This starts off in exactly the same way as the old style approach. However if after adding all the certificates from the peer provided list we are unable to build a trusted chain, then we pop the last certificate off the chain we've built so far and go back to the trusted store to have another go. We continue this until we've got no more certificates to pop. The primary advantage of the alt chains strategy is that there is no performance hit over any chain that would be successfully built using the old style strategy (because it starts off in the same way). There might be a performance hit on unsuccessful chain building over the old style - but we assume this is less of an issue. It makes no sense to combine the trusted first and alt chains strategies. With trusted first we have already checked all of the possible chains by the time we get to the end of the peer provided list - so there is no point in then popping certs off the top of our chain and checking the trusted store again. Hope that clarifies things, Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3871] Patch for latest git master to fix crypto/ec build errors (OSX)
Fixed in 88f4c6f3d2f884715f8f5f8eb81f0a96cbec8cef, thanks for spotting! ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3879] [BUG] opennssl 1.0.1g cause the system crash (obj_xref.c)
On Fri May 29 07:06:02 2015, joy...@moxa.com wrote: Hi, I am porting openssl_1.0.1g to our private OS. But we meet some problem, could you please give me a favor. The issue is described below. Inside the file obj_xref.c, there is a variable sigx_app that never be initialize, so this variable sigx_app will be changed anytime. The uninitialized variable sigx_app will cause the system crash at anytime. Could you please tell me the reason why the variable didn’t initialize? The variable sigx_app is a global variable. If your global variables are not being initialised then I would classify this as a compiler bug. OpenSSL assumes a compiler to be conformant with the C90 spec. All global variables have static storage duration. From section 6.5.7 of C90: If an object that has static storage duration is not initialized explicitly, it is initialized implicitly as if every member that has arithmetic type were assigned 0 and every member that has pointer type were assigned a null pointer constant. Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3879] [BUG] opennssl 1.0.1g cause the system crash (obj_xref.c)
On Fri, May 29, 2015 at 02:58:32PM +0200, Matt Caswell via RT wrote: On Fri May 29 07:06:02 2015, joy...@moxa.com wrote: Hi, I am porting openssl_1.0.1g to our private OS. But we meet some problem, could you please give me a favor. The issue is described below. Inside the file obj_xref.c, there is a variable sigx_app that never be initialize, so this variable sigx_app will be changed anytime. The uninitialized variable sigx_app will cause the system crash at anytime. Could you please tell me the reason why the variable didn't initialize? The variable sigx_app is a global variable. If your global variables are not being initialised then I would classify this as a compiler bug. OpenSSL assumes a compiler to be conformant with the C90 spec. All global variables have static storage duration. From section 6.5.7 of C90: If an object that has static storage duration is not initialized explicitly, it is initialized implicitly as if every member that has arithmetic type were assigned 0 and every member that has pointer type were assigned a null pointer constant. This is typically done by putting those variables in the bss segment. Your private OS probably didn't set the bss segment to all 0's. Kurt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3879] [BUG] opennssl 1.0.1g cause the system crash (obj_xref.c)
From: Kurt Roeckx via RT [r...@openssl.org] Sent: Saturday, May 30, 2015 12:58 AM To: Joy Tu (凃清祺) Cc: openssl-dev@openssl.org Subject: Re: [openssl-dev] [openssl.org #3879] [BUG] opennssl 1.0.1g cause the system crash (obj_xref.c) On Fri, May 29, 2015 at 02:58:32PM +0200, Matt Caswell via RT wrote: On Fri May 29 07:06:02 2015, joy...@moxa.com wrote: Hi, I am porting openssl_1.0.1g to our private OS. But we meet some problem, could you please give me a favor. The issue is described below. Inside the file obj_xref.c, there is a variable sigx_app that never be initialize, so this variable sigx_app will be changed anytime. The uninitialized variable sigx_app will cause the system crash at anytime. Could you please tell me the reason why the variable didn't initialize? The variable sigx_app is a global variable. If your global variables are not being initialised then I would classify this as a compiler bug. OpenSSL assumes a compiler to be conformant with the C90 spec. All global variables have static storage duration. From section 6.5.7 of C90: If an object that has static storage duration is not initialized explicitly, it is initialized implicitly as if every member that has arithmetic type were assigned 0 and every member that has pointer type were assigned a null pointer constant. This is typically done by putting those variables in the bss segment. Your private OS probably didn't set the bss segment to all 0's. So the solution is to initialize the variable by myself or update the compiler to conformant with the C90 spec or force those global variable in the bss segment to be all 0's on my private OS? ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3879] [BUG] opennssl 1.0.1g cause the system crash (obj_xref.c)
So the solution is to initialize the variable by myself or update the compiler to conformant with the C90 spec or force those global variable in the bss segment to be all 0's on my private OS? From: Kurt Roeckx [k...@roeckx.be] Sent: Saturday, May 30, 2015 12:57 AM To: r...@openssl.org; openssl-dev@openssl.org Cc: Joy Tu (凃清祺) Subject: Re: [openssl-dev] [openssl.org #3879] [BUG] opennssl 1.0.1g cause the system crash (obj_xref.c) On Fri, May 29, 2015 at 02:58:32PM +0200, Matt Caswell via RT wrote: On Fri May 29 07:06:02 2015, joy...@moxa.com wrote: Hi, I am porting openssl_1.0.1g to our private OS. But we meet some problem, could you please give me a favor. The issue is described below. Inside the file obj_xref.c, there is a variable sigx_app that never be initialize, so this variable sigx_app will be changed anytime. The uninitialized variable sigx_app will cause the system crash at anytime. Could you please tell me the reason why the variable didn't initialize? The variable sigx_app is a global variable. If your global variables are not being initialised then I would classify this as a compiler bug. OpenSSL assumes a compiler to be conformant with the C90 spec. All global variables have static storage duration. From section 6.5.7 of C90: If an object that has static storage duration is not initialized explicitly, it is initialized implicitly as if every member that has arithmetic type were assigned 0 and every member that has pointer type were assigned a null pointer constant. This is typically done by putting those variables in the bss segment. Your private OS probably didn't set the bss segment to all 0's. Kurt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
