Re: Apple are, apparently, dicks...
On 14/06/13 14:16, Ben Laurie wrote: On 14 June 2013 14:08, Rob Stradling rob.stradl...@comodo.com wrote: snip Apparently the ECDHE-ECDSA bug is in SecureTransport, which is an integral component of OSX. https://developer.apple.com/library/mac/#documentation/security/Reference/secureTransportRef/Reference/reference.html seems to suggest it is a library. Ben, what else needs to happen before this patch is either committed or rejected? Thanks. -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Apple are, apparently, dicks...
On 14/06/13 15:25, Florian Weimer wrote: On 06/14/2013 03:31 PM, Dr. Stephen Henson wrote: Note that the patch changes the value of SSL_OP_ALL so if OpenSSL shared libraries are updated to include the patch existing applications wont set it: they'd all need to be recompiled. That's a valid point. Possibly alternative is to reuse one of the existing *ancient* flags. Does anyone really care about compatibility with a bug in SSLeay 0.80 for example? Wouldn't it be better to reverse the meaning of the flag and not set it in SSL_OP_ALL? Just to complicate matters further, the 0x400 bit used to be set in SSL_OP_ALL, and has previously been used for at least 2 other purposes! http://cvs.openssl.org/chngview?cn=18974 http://cvs.openssl.org/chngview?cn=22501 -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Apple are, apparently, dicks...
...and don't intend to fix their broken ECDSA support in Safari. It is therefore suggested that I pull this patch: https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d What do people think? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Apple are, apparently, dicks...
On Thu, Jun 13, 2013 at 6:39 PM, Ben Laurie b...@links.org wrote: It is therefore suggested that I pull this patch: https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d The behavior change applies only if new option SSL_OP_SAFARI_ECDHE_ECDSA_BUG is used (part of SSL_OP_ALL), as is standard for interoperability bug workarounds, so while it is very unfortunate that we'd need to do this, I'm in favor of accepting this patch.
Re: Apple are, apparently, dicks...
On 13/06/13 17:39, Ben Laurie wrote: ...and don't intend to fix their broken ECDSA support in Safari. Ben, you've got your wires a bit crossed there. The ECDHE-ECDSA ciphersuites are indeed broken in Safari on OSX 10.8 to 10.8.3, but they are _fixed_ in OSX 10.8.4 (released last week). It is therefore suggested that I pull this patch: https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d What do people think? The unfortunate reality is that significant numbers of OSX 10.8.x users won't upgrade to 10.8.4 anytime soon, even though the upgrade is free and easy to install. No server administrator will want to deploy ECDHE-ECDSA if it means breaking compatibility with even a small fraction of deployed browsers. Hence why this patch is, unfortunately, necessary. -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Apple are, apparently, dicks...
On 14 June 2013 09:39, Rob Stradling rob.stradl...@comodo.com wrote: On 13/06/13 17:39, Ben Laurie wrote: ...and don't intend to fix their broken ECDSA support in Safari. Ben, you've got your wires a bit crossed there. The ECDHE-ECDSA ciphersuites are indeed broken in Safari on OSX 10.8 to 10.8.3, but they are _fixed_ in OSX 10.8.4 (released last week). It is therefore suggested that I pull this patch: https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d What do people think? The unfortunate reality is that significant numbers of OSX 10.8.x users won't upgrade to 10.8.4 anytime soon, even though the upgrade is free and easy to install. Precisely my point - so how were my wires crossed? No server administrator will want to deploy ECDHE-ECDSA if it means breaking compatibility with even a small fraction of deployed browsers. Hence why this patch is, unfortunately, necessary. What is _necessary_ is that Apple accept responsibility for their errors :-) Why are we chasing after them cleaning up their messes? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Apple are, apparently, dicks...
On 14/06/13 10:20, Ben Laurie wrote: On 14 June 2013 09:39, Rob Stradling rob.stradl...@comodo.com wrote: On 13/06/13 17:39, Ben Laurie wrote: ...and don't intend to fix their broken ECDSA support in Safari. Ben, you've got your wires a bit crossed there. The ECDHE-ECDSA ciphersuites are indeed broken in Safari on OSX 10.8 to 10.8.3, but they are _fixed_ in OSX 10.8.4 (released last week). It is therefore suggested that I pull this patch: https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d What do people think? The unfortunate reality is that significant numbers of OSX 10.8.x users won't upgrade to 10.8.4 anytime soon, even though the upgrade is free and easy to install. Precisely my point - so how were my wires crossed? Ah, so you're criticizing Apple for not being willing to force all OSX 10.8.x users to update to 10.8.4. If OSX 10.8.x has a mechanism that allows Apple to force updates to be installed, then I agree. But my suspicion is that it doesn't, and if so, Apple's willingness isn't the key issue here. No server administrator will want to deploy ECDHE-ECDSA if it means breaking compatibility with even a small fraction of deployed browsers. Hence why this patch is, unfortunately, necessary. What is _necessary_ is that Apple accept responsibility for their errors :-) Agreed. Sadly, the OSX 10.8.4 changelog doesn't even mention the ECDHE-ECDSA bugfix. Why are we chasing after them cleaning up their messes? Because we want ECDHE-ECDSA to be deployable. -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Apple are, apparently, dicks...
On 14 June 2013 12:25, Rob Stradling rob.stradl...@comodo.com wrote: On 14/06/13 10:20, Ben Laurie wrote: On 14 June 2013 09:39, Rob Stradling rob.stradl...@comodo.com wrote: On 13/06/13 17:39, Ben Laurie wrote: ...and don't intend to fix their broken ECDSA support in Safari. Ben, you've got your wires a bit crossed there. The ECDHE-ECDSA ciphersuites are indeed broken in Safari on OSX 10.8 to 10.8.3, but they are _fixed_ in OSX 10.8.4 (released last week). It is therefore suggested that I pull this patch: https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d What do people think? The unfortunate reality is that significant numbers of OSX 10.8.x users won't upgrade to 10.8.4 anytime soon, even though the upgrade is free and easy to install. Precisely my point - so how were my wires crossed? Ah, so you're criticizing Apple for not being willing to force all OSX 10.8.x users to update to 10.8.4. No. If OSX 10.8.x has a mechanism that allows Apple to force updates to be installed, then I agree. But my suspicion is that it doesn't, and if so, Apple's willingness isn't the key issue here. It has a mechanism to nag you endlessly until you do install updates. Which makes me wonder why you think people won't install the OS update? No server administrator will want to deploy ECDHE-ECDSA if it means breaking compatibility with even a small fraction of deployed browsers. Hence why this patch is, unfortunately, necessary. What is _necessary_ is that Apple accept responsibility for their errors :-) Agreed. Sadly, the OSX 10.8.4 changelog doesn't even mention the ECDHE-ECDSA bugfix. Why are we chasing after them cleaning up their messes? Because we want ECDHE-ECDSA to be deployable. -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Apple are, apparently, dicks...
On 14/06/13 12:31, Ben Laurie wrote: On 14 June 2013 12:25, Rob Stradling rob.stradl...@comodo.com wrote: snip Ah, so you're criticizing Apple for not being willing to force all OSX 10.8.x users to update to 10.8.4. No. If OSX 10.8.x has a mechanism that allows Apple to force updates to be installed, then I agree. But my suspicion is that it doesn't, and if so, Apple's willingness isn't the key issue here. It has a mechanism to nag you endlessly until you do install updates. Which makes me wonder why you think people won't install the OS update? Safari's User-Agent string reveals the OSX version that it is running on. A few weeks ago I analyzed some webserver logs to get an idea of historical OSX update rates. Based on that analysis, I forecast that the majority of OSX 10.8.x users will install the 10.8.4 update, but that a significant minority won't. No server administrator will want to deploy ECDHE-ECDSA if it means breaking compatibility with even a small fraction of deployed browsers. Hence why this patch is, unfortunately, necessary. What is _necessary_ is that Apple accept responsibility for their errors :-) Agreed. Sadly, the OSX 10.8.4 changelog doesn't even mention the ECDHE-ECDSA bugfix. Why are we chasing after them cleaning up their messes? Because we want ECDHE-ECDSA to be deployable. -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Apple are, apparently, dicks...
On 14 June 2013 13:57, Rob Stradling rob.stradl...@comodo.com wrote: On 14/06/13 12:31, Ben Laurie wrote: On 14 June 2013 12:25, Rob Stradling rob.stradl...@comodo.com wrote: snip Ah, so you're criticizing Apple for not being willing to force all OSX 10.8.x users to update to 10.8.4. No. If OSX 10.8.x has a mechanism that allows Apple to force updates to be installed, then I agree. But my suspicion is that it doesn't, and if so, Apple's willingness isn't the key issue here. It has a mechanism to nag you endlessly until you do install updates. Which makes me wonder why you think people won't install the OS update? Safari's User-Agent string reveals the OSX version that it is running on. A few weeks ago I analyzed some webserver logs to get an idea of historical OSX update rates. Based on that analysis, I forecast that the majority of OSX 10.8.x users will install the 10.8.4 update, but that a significant minority won't. I guess then we need to know why? And would they upgrade Safari alone? No server administrator will want to deploy ECDHE-ECDSA if it means breaking compatibility with even a small fraction of deployed browsers. Hence why this patch is, unfortunately, necessary. What is _necessary_ is that Apple accept responsibility for their errors :-) Agreed. Sadly, the OSX 10.8.4 changelog doesn't even mention the ECDHE-ECDSA bugfix. Why are we chasing after them cleaning up their messes? Because we want ECDHE-ECDSA to be deployable. -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Apple are, apparently, dicks...
On Thu, Jun 13, 2013 at 05:39:36PM +0100, Ben Laurie wrote: ...and don't intend to fix their broken ECDSA support in Safari. It is therefore suggested that I pull this patch: https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d What do people think? No keep the patch. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org -- Member - Liberal International This is doc...@nl2k.ab.ca Ici doc...@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism The false churches will conform themselves to this world's demands, seeing as they do not fear and thus do not obey God. - anon __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Apple are, apparently, dicks...
On Fri, Jun 14, 2013, Bodo Moeller wrote: On Thu, Jun 13, 2013 at 6:39 PM, Ben Laurie b...@links.org wrote: It is therefore suggested that I pull this patch: https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d The behavior change applies only if new option SSL_OP_SAFARI_ECDHE_ECDSA_BUG is used (part of SSL_OP_ALL), as is standard for interoperability bug workarounds, so while it is very unfortunate that we'd need to do this, I'm in favor of accepting this patch. Note that the patch changes the value of SSL_OP_ALL so if OpenSSL shared libraries are updated to include the patch existing applications wont set it: they'd all need to be recompiled. Possibly alternative is to reuse one of the existing *ancient* flags. Does anyone really care about compatibility with a bug in SSLeay 0.80 for example? 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: Apple are, apparently, dicks...
On 06/14/2013 03:31 PM, Dr. Stephen Henson wrote: Note that the patch changes the value of SSL_OP_ALL so if OpenSSL shared libraries are updated to include the patch existing applications wont set it: they'd all need to be recompiled. That's a valid point. Possibly alternative is to reuse one of the existing *ancient* flags. Does anyone really care about compatibility with a bug in SSLeay 0.80 for example? Wouldn't it be better to reverse the meaning of the flag and not set it in SSL_OP_ALL? -- Florian Weimer / Red Hat Product Security Team __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Apple are, apparently, dicks...
Note that the patch changes the value of SSL_OP_ALL so if OpenSSL shared libraries are updated to include the patch existing applications wont set it: they'd all need to be recompiled. That's a valid point. This is true, unfortunately. Possibly alternative is to reuse one of the existing *ancient* flags. Does anyone really care about compatibility with a bug in SSLeay 0.80 for example? Wouldn't it be better to reverse the meaning of the flag and not set it in SSL_OP_ALL? Hm, without any SSL_OP_... settings, the expectation generally is that we kind of sort of follow the specs and don't do any weird stuff like this for interoperability's sake. If we switch semantics around for certain options, the resulting inconsistencies would make all that even more confusing. In theory we could create an explicit SSL_OP_ALL-equivalent bit (SSL_OP_ALL_ALL?) that enables all current SSL_OP_ALL features and doesn't allow further masking, but that seems hard to deploy given that some current applications may expressly want SSL_OP_ALL *without* certain flags. Of course the legacy flag an application disables could be the one that we're about to recycle ... SSL_OP_ALL ideally would always have included some unused bits for future use, but that again is hard to pull off retroactively -- it's probably a good idea for a later release (with an incompatible .so version so that we can safely change SSL_OP_ALL). If we can find an appropriate ancient flag that no one should care about (which sounds plausible), recycling that one sounds like a good idea. If we can't, using reverted semantics might be the best option we have. Bodo
RE: Apple are, apparently, dicks...
Ø Hm, without any SSL_OP_... settings, the expectation generally is that we kind of sort of follow the specs Ø and don't do any weird stuff like this for interoperability's sake. If we switch semantics around for certain Ø options, the resulting inconsistencies would make all that even more confusing. +1 -- Principal Security Engineer Akamai Technology Cambridge, MA
Re: Apple are, apparently, dicks...
On 14/06/13 13:58, Ben Laurie wrote: On 14 June 2013 13:57, Rob Stradling rob.stradl...@comodo.com wrote: snip Safari's User-Agent string reveals the OSX version that it is running on. A few weeks ago I analyzed some webserver logs to get an idea of historical OSX update rates. Based on that analysis, I forecast that the majority of OSX 10.8.x users will install the 10.8.4 update, but that a significant minority won't. I guess then we need to know why? And would they upgrade Safari alone? Apparently the ECDHE-ECDSA bug is in SecureTransport, which is an integral component of OSX. No server administrator will want to deploy ECDHE-ECDSA if it means breaking compatibility with even a small fraction of deployed browsers. Hence why this patch is, unfortunately, necessary. What is _necessary_ is that Apple accept responsibility for their errors :-) Agreed. Sadly, the OSX 10.8.4 changelog doesn't even mention the ECDHE-ECDSA bugfix. Why are we chasing after them cleaning up their messes? Because we want ECDHE-ECDSA to be deployable. -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Apple are, apparently, dicks...
On 14 June 2013 13:54, The Doctor doc...@doctor.nl2k.ab.ca wrote: On Thu, Jun 13, 2013 at 05:39:36PM +0100, Ben Laurie wrote: ...and don't intend to fix their broken ECDSA support in Safari. It is therefore suggested that I pull this patch: https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d What do people think? No keep the patch. I am not sure what you mean by this. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Apple are, apparently, dicks...
On 14 June 2013 14:08, Rob Stradling rob.stradl...@comodo.com wrote: On 14/06/13 13:58, Ben Laurie wrote: On 14 June 2013 13:57, Rob Stradling rob.stradl...@comodo.com wrote: snip Safari's User-Agent string reveals the OSX version that it is running on. A few weeks ago I analyzed some webserver logs to get an idea of historical OSX update rates. Based on that analysis, I forecast that the majority of OSX 10.8.x users will install the 10.8.4 update, but that a significant minority won't. I guess then we need to know why? And would they upgrade Safari alone? Apparently the ECDHE-ECDSA bug is in SecureTransport, which is an integral component of OSX. https://developer.apple.com/library/mac/#documentation/security/Reference/secureTransportRef/Reference/reference.html seems to suggest it is a library. No server administrator will want to deploy ECDHE-ECDSA if it means breaking compatibility with even a small fraction of deployed browsers. Hence why this patch is, unfortunately, necessary. What is _necessary_ is that Apple accept responsibility for their errors :-) Agreed. Sadly, the OSX 10.8.4 changelog doesn't even mention the ECDHE-ECDSA bugfix. Why are we chasing after them cleaning up their messes? Because we want ECDHE-ECDSA to be deployable. -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Apple are, apparently, dicks...
On 14/06/13 13:54, The Doctor wrote: On Thu, Jun 13, 2013 at 05:39:36PM +0100, Ben Laurie wrote: ...and don't intend to fix their broken ECDSA support in Safari. It is therefore suggested that I pull this patch: https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d What do people think? No keep the patch. I think you misunderstood what Ben meant by pull. See man git-pull -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Apple are, apparently, dicks...
On 14/06/13 14:31, Dr. Stephen Henson wrote: snip The behavior change applies only if new option SSL_OP_SAFARI_ECDHE_ECDSA_BUG is used (part of SSL_OP_ALL), as is standard for interoperability bug workarounds, so while it is very unfortunate that we'd need to do this, I'm in favor of accepting this patch. Note that the patch changes the value of SSL_OP_ALL so if OpenSSL shared libraries are updated to include the patch existing applications wont set it: they'd all need to be recompiled. Yep, but 0x400 is the only currently unallocated bit. Possibly alternative is to reuse one of the existing *ancient* flags. Does anyone really care about compatibility with a bug in SSLeay 0.80 for example? I'd wondered about that. If you're happy to reallocate one of the ancient flags, please do! -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Apple are, apparently, dicks...
On 14 June 2013 16:10, Bodo Moeller bmoel...@acm.org wrote: Note that the patch changes the value of SSL_OP_ALL so if OpenSSL shared libraries are updated to include the patch existing applications wont set it: they'd all need to be recompiled. That's a valid point. This is true, unfortunately. Possibly alternative is to reuse one of the existing *ancient* flags. Does anyone really care about compatibility with a bug in SSLeay 0.80 for example? Wouldn't it be better to reverse the meaning of the flag and not set it in SSL_OP_ALL? Hm, without any SSL_OP_... settings, the expectation generally is that we kind of sort of follow the specs and don't do any weird stuff like this for interoperability's sake. If we switch semantics around for certain options, the resulting inconsistencies would make all that even more confusing. In theory we could create an explicit SSL_OP_ALL-equivalent bit (SSL_OP_ALL_ALL?) that enables all current SSL_OP_ALL features and doesn't allow further masking, but that seems hard to deploy given that some current applications may expressly want SSL_OP_ALL *without* certain flags. Of course the legacy flag an application disables could be the one that we're about to recycle ... SSL_OP_ALL ideally would always have included some unused bits for future use, but that again is hard to pull off retroactively -- it's probably a good idea for a later release (with an incompatible .so version so that we can safely change SSL_OP_ALL). If we can find an appropriate ancient flag that no one should care about (which sounds plausible), recycling that one sounds like a good idea. If we can't, using reverted semantics might be the best option we have. We could just add an SSL_OP_ALL_FROM_FUTURE flag that did this, and leave SSL_OP_ALL as it is? If you really want to get funky, you could make it so any bit set with SSL_OP_ALL_FROM_FUTURE disables the corresponding feature. This would mean you could never re-use bits, tho... __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
