Re: [openssl-dev] Seeking feedback on some #ifdef changes
TLS connection could be established without X509 certs and storage support (e.g. CoAP protocol with PSK cipher suites). It would be great to build libssl library without X509 at all. Thank you Alexey ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Seeking feedback on some #ifdef changes
TLS connection could be established without X509 certs and storage support (e.g. CoAP protocol with PSK cipher suites). It would be great to build libssl library without X509 at all. I'd be interested in working patches. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Seeking feedback on some #ifdef changes
On 5.3.2015 18:27, Salz, Rich wrote: Sorry for responding late to this thread, but has anyone considered consolidating the following three definitions: OPENSSL_NO_EC OPENSSL_NO_ECDH OPENSSL_NO_EDDSA Is there a valid case where all three of these wouldn't be used together? Would the code even compile if only one (or two) of these were defined? I would be happy to unify these, and you are probably right that the various mix and match options do not work. Does anyone here have issues or concerns if we do that? If you still keep the OPENSSL_NO_EC2M separate, then I do not have any problem with this. However I would expect these three ifdefs to work - of course with OPENSSL_NO_EC implying the NO_ECDH amd NO_ECDSA. Although I did not try it myself. Tomas Mraz ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Seeking feedback on some #ifdef changes
Sorry for responding late to this thread, but has anyone considered consolidating the following three definitions: OPENSSL_NO_EC OPENSSL_NO_ECDH OPENSSL_NO_EDDSA Is there a valid case where all three of these wouldn't be used together? Would the code even compile if only one (or two) of these were defined? On 01/23/2015 02:11 PM, Salz, Rich wrote: Looking at just OPENSSL_NO_xxx, we have over 100 openssl #ifdef options and we are considering removing nearly a third of them. Please reply soon if the following plan would cause problems. This will happen only in master, for post-1.0.2. We will remove the following options. You could argue that the OPENSSL_NO_SHAxxx options be treated as crypto, but OpenSSL does not compile without SHA and SHA1 defined, and we have no interest in spending the time to fix it. So for consistency, we will remove all of them. GENUINE_DSA (and the broken DSS0 since SHA0 will be removed) OPENSSL_NO_BIO OPENSSL_NO_BUFFER OPENSSL_NO_BUF_FREELISTS OPENSSL_NO_CHAIN_VERIFY OPENSSL_NO_DESCBCM (also removing the code; no EVP support) OPENSSL_NO_EVP OPENSSL_NO_FIPS_ERR OPENSSL_NO_HASH_COMP OPENSSL_NO_LHASH OPENSSL_NO_LOCKING OPENSSL_NO_MULTIBYTE (also removing the code) OPENSSL_NO_OBJECT OPENSSL_NO_RFC3779 OPENSSL_NO_SHA OPENSSL_NO_SHA0 (also removing the code for SHA0) OPENSSL_NO_SHA1 OPENSSL_NO_SHA224 OPENSSL_NO_SHA256 OPENSSL_NO_SHA384 OPENSSL_NO_SHA512 OPENSSL_NO_SPEED OPENSSL_NO_SSL_INTERN (first attempt at making things opaque) OPENSSL_NO_STACK OPENSSL_NO_STORE OPENSSL_NO_TLS OPENSSL_NO_TLS1 OPENSSL_NO_TLS1_2_CLIENT OPENSSL_NO_TLSEXT OPENSSL_NO_X509 OPENSSL_NO_X509_VERIFY -- Principal Security Engineer, Akamai Technologies IM: rs...@jabber.me mailto:rs...@jabber.me Twitter: RichSalz ___ 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
Re: [openssl-dev] Seeking feedback on some #ifdef changes
Sorry for responding late to this thread, but has anyone considered consolidating the following three definitions: OPENSSL_NO_EC OPENSSL_NO_ECDH OPENSSL_NO_EDDSA Is there a valid case where all three of these wouldn't be used together? Would the code even compile if only one (or two) of these were defined? I would be happy to unify these, and you are probably right that the various mix and match options do not work. Does anyone here have issues or concerns if we do that? ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Seeking feedback on some #ifdef changes
In message 775c783c5fbe4855b5461ce51ad9b...@ustx2ex-dag1mb2.msg.corp.akamai.com on Wed, 11 Feb 2015 00:25:35 +, Salz, Rich rs...@akamai.com said: rsalz rsalz Please continue to make it possible to build the crypto part of OpenSSL, rsalz without the X.509 and SSL/TLS code. There are lots of uses of OpenSSL that rsalz don't need that code. rsalz rsalz You can build crypto without ssl. And the only place OPENSSL_NO_X509 appeared was, strangely, in ssl. So crypto builds, which didn't really pay attention to OPENSLS_NO_x509 before, still don't. :) But it will pay attention to './config no-x509 no-x509v3', since that will remove the directories x509 and x509v3 from SDIRS. That still stands. Cheers, Richard -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ Life is a tremendous celebration - and I'm invited! -- from a friend's blog, translated from Swedish ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Seeking feedback on some #ifdef changes
On Tue, Feb 10, 2015 at 4:25 PM, Salz, Rich rs...@akamai.com wrote: Please continue to make it possible to build the crypto part of OpenSSL, without the X.509 and SSL/TLS code. There are lots of uses of OpenSSL that don't need that code. You can build crypto without ssl. And the only place OPENSSL_NO_X509 appeared was, strangely, in ssl. So crypto builds, which didn't really pay attention to OPENSLS_NO_x509 before, still don't. :) The X.509 code is in crypto, though. Also, when I've had a use for libssl, I've usually wanted to use an X.509 library other than OpenSSL's, for a variety of reasons. It would be useful to remove all of libssl's dependencies on the X.509 code during the time that the other compatibility-breaking changes are being made. Cheers, Brian ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Seeking feedback on some #ifdef changes
Please continue to make it possible to build the crypto part of OpenSSL, without the X.509 and SSL/TLS code. There are lots of uses of OpenSSL that don't need that code. You can build crypto without ssl. And the only place OPENSSL_NO_X509 appeared was, strangely, in ssl. So crypto builds, which didn't really pay attention to OPENSLS_NO_x509 before, still don't. :) Hope this helps. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Seeking feedback on some #ifdef changes
Salz, Rich rs...@akamai.com wrote: OPENSSL_NO_CHAIN_VERIFY OPENSSL_NO_RFC3779 OPENSSL_NO_TLS OPENSSL_NO_TLS1 OPENSSL_NO_TLS1_2_CLIENT OPENSSL_NO_TLSEXT OPENSSL_NO_X509 OPENSSL_NO_X509_VERIFY Please continue to make it possible to build the crypto part of OpenSSL, without the X.509 and SSL/TLS code. There are lots of uses of OpenSSL that don't need that code. Actually, I'd prefer if it were possible to build without any of the ASN.1 code too, but I understand that is messy because the EVP interface assumes the ASN.1 parser is available. But, building without X.509 and SSl/TLS support should be easy to continue to support. Cheers, Brian ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Seeking feedback on some #ifdef changes
Hi Rich, Salz, Rich wrote: Looking at just OPENSSL_NO_xxx, we have over 100 openssl #ifdef options and we are considering removing nearly a third of them. Please reply soon if the following plan would cause problems. This will happen only in master, for post-1.0.2. We will remove the following options. You could argue that the OPENSSL_NO_SHAxxx options be treated as crypto, but OpenSSL does not compile without SHA and SHA1 defined, and we have no interest in spending the time to fix it. So for consistency, we will remove all of them. What about a) OPENSSL_NO_SSL2 and b) OPENSSL_NO_SSL3 and OPENSSL_NO_SSL3_METHOD ? It seems to me master branch does not define #ifdef for those options in opensslconf.h . Change log point that ssl v2 is removed. It is expected opensslconf.h to define unconditionally OPENSSL_NO_SSL2. Please review ssl3. It seems to me b) is error in script. [SNIP] OPENSSL_NO_STORE Also removing the code? Regards, Roumen Petrov ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Seeking feedback on some #ifdef changes
What about a) OPENSSL_NO_SSL2 and b) OPENSSL_NO_SSL3 and OPENSSL_NO_SSL3_METHOD ? It seems to me master branch does not define #ifdef for those options in opensslconf.h . Hm, maybe Kurt can comment on this. Change log point that ssl v2 is removed. It is expected opensslconf.h to define unconditionally OPENSSL_NO_SSL2. Interesting idea. OPENSSL_NO_STORE Also removing the code? The team member working on this wants to keep it in the tree for now, so we will. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Seeking feedback on some #ifdef changes
El 27/01/15 a las 08:30, Hanno Böck escribió: Hello, On Fri, 23 Jan 2015 19:11:35 + Salz, Rich rs...@akamai.com wrote: OPENSSL_NO_BUF_FREELISTS As far as I remember the post-heartbleed discussions this disables an openssl-own memory management which in the case of heartbleed circumvented memory protection measures like address sanitizer. What's the plan here? Replace openssl's own memory management by default with standard memory management calls or is the plan to disable the possibility to have standard memory management at all? If the latter I'd vote against removing that flag. I think It needs be replaced by standard memory managment, whoever wants to do something special like using a different/tweaked allocator for whatever reason should use the operating system facilities to do so. Inordinate amounts of time have been spent improving things at this level, at least in linux BUF_FREELISTS functionality makes no sense whatsover. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Seeking feedback on some #ifdef changes
Hello, On Fri, 23 Jan 2015 19:11:35 + Salz, Rich rs...@akamai.com wrote: OPENSSL_NO_BUF_FREELISTS As far as I remember the post-heartbleed discussions this disables an openssl-own memory management which in the case of heartbleed circumvented memory protection measures like address sanitizer. What's the plan here? Replace openssl's own memory management by default with standard memory management calls or is the plan to disable the possibility to have standard memory management at all? If the latter I'd vote against removing that flag. cu, -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 pgp7loP3vOqCL.pgp Description: OpenPGP digital signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Seeking feedback on some #ifdef changes
What's the plan here? Replace openssl's own memory management by default with standard memory management calls or is the plan to disable the possibility to have standard memory management at all? If the latter I'd vote against removing that flag. We use using only malloc and free. We are no longer keeping our own freelist management. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Seeking feedback on some #ifdef changes
El 27/01/15 a las 08:30, Hanno Böck escribió: Hello, On Fri, 23 Jan 2015 19:11:35 + Salz, Rich rs...@akamai.com wrote: OPENSSL_NO_BUF_FREELISTS As far as I remember the post-heartbleed discussions this disables an openssl-own memory management which in the case of heartbleed circumvented memory protection measures like address sanitizer. What's the plan here? Replace openssl's own memory management by default with standard memory management calls or is the plan to disable the possibility to have standard memory management at all? If the latter I'd vote against removing that flag. I think It needs be replaced by standard memory managment, whoever wants to do something special like using a different/tweaked allocator for whatever reason should use the operating system facilities to do so. Inordinate amounts of time have been spent improving things at this level, at least in linux BUF_FREELISTS functionality makes no sense whatsover. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Seeking feedback on some #ifdef changes
Looking at just OPENSSL_NO_xxx, we have over 100 openssl #ifdef options and we are considering removing nearly a third of them. Please reply soon if the following plan would cause problems. This will happen only in master, for post-1.0.2. We will remove the following options. You could argue that the OPENSSL_NO_SHAxxx options be treated as crypto, but OpenSSL does not compile without SHA and SHA1 defined, and we have no interest in spending the time to fix it. So for consistency, we will remove all of them. GENUINE_DSA (and the broken DSS0 since SHA0 will be removed) OPENSSL_NO_BIO OPENSSL_NO_BUFFER OPENSSL_NO_BUF_FREELISTS OPENSSL_NO_CHAIN_VERIFY OPENSSL_NO_DESCBCM (also removing the code; no EVP support) OPENSSL_NO_EVP OPENSSL_NO_FIPS_ERR OPENSSL_NO_HASH_COMP OPENSSL_NO_LHASH OPENSSL_NO_LOCKING OPENSSL_NO_MULTIBYTE (also removing the code) OPENSSL_NO_OBJECT OPENSSL_NO_RFC3779 OPENSSL_NO_SHA OPENSSL_NO_SHA0 (also removing the code for SHA0) OPENSSL_NO_SHA1 OPENSSL_NO_SHA224 OPENSSL_NO_SHA256 OPENSSL_NO_SHA384 OPENSSL_NO_SHA512 OPENSSL_NO_SPEED OPENSSL_NO_SSL_INTERN (first attempt at making things opaque) OPENSSL_NO_STACK OPENSSL_NO_STORE OPENSSL_NO_TLS OPENSSL_NO_TLS1 OPENSSL_NO_TLS1_2_CLIENT OPENSSL_NO_TLSEXT OPENSSL_NO_X509 OPENSSL_NO_X509_VERIFY -- Principal Security Engineer, Akamai Technologies IM: rs...@jabber.memailto:rs...@jabber.me Twitter: RichSalz ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Seeking feedback on some #ifdef changes
The only one of all those that matters (to me) is OPENSSL_NO_SSL_INTERN since that provides a way to anticipate the effects of this API change. I'm fine with it going, but it needs a specified replacement (even if the replacement is we'll do that by default). Currently for example Qt won't build with OPENSSL_NO_SSL_INTERN defined since there are fields used for NPN that we need (iirc). I hadn't thought of it as being a preview for what we plan to do. I guess it makes sense to keep it, at least until we have a preview of some kind that lets folks start building in the New World Order. Thanks! -- Principal Security Engineer, Akamai Technologies IM: rs...@jabber.me Twitter: RichSalz ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Seeking feedback on some #ifdef changes
On Fri, Jan 23, 2015 at 09:57:27PM +, Salz, Rich wrote: I hadn't thought of it as being a preview for what we plan to do. I guess it makes sense to keep it, at least until we have a preview of some kind that lets folks start building in the New World Order. I've used it to future-proof Postfix. It now builds with the NO_INTERN flag set. Keeping that flag makes sense. -- Viktor. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Seeking feedback on some #ifdef changes
Looking at just OPENSSL_NO_xxx, we have over 100 openssl #ifdef options and we are considering removing nearly a third of them. Please reply soon if the following plan would cause problems. This will happen only in master, for post-1.0.2. We will remove the following options. You could argue that the OPENSSL_NO_SHAxxx options be treated as crypto, but OpenSSL does not compile without SHA and SHA1 defined, and we have no interest in spending the time to fix it. So for consistency, we will remove all of them. GENUINE_DSA (and the broken DSS0 since SHA0 will be removed) OPENSSL_NO_BIO OPENSSL_NO_BUFFER OPENSSL_NO_BUF_FREELISTS OPENSSL_NO_CHAIN_VERIFY OPENSSL_NO_DESCBCM (also removing the code; no EVP support) OPENSSL_NO_EVP OPENSSL_NO_FIPS_ERR OPENSSL_NO_HASH_COMP OPENSSL_NO_LHASH OPENSSL_NO_LOCKING OPENSSL_NO_MULTIBYTE (also removing the code) OPENSSL_NO_OBJECT OPENSSL_NO_RFC3779 OPENSSL_NO_SHA OPENSSL_NO_SHA0 (also removing the code for SHA0) OPENSSL_NO_SHA1 OPENSSL_NO_SHA224 OPENSSL_NO_SHA256 OPENSSL_NO_SHA384 OPENSSL_NO_SHA512 OPENSSL_NO_SPEED OPENSSL_NO_SSL_INTERN (first attempt at making things opaque) OPENSSL_NO_STACK OPENSSL_NO_STORE OPENSSL_NO_TLS OPENSSL_NO_TLS1 OPENSSL_NO_TLS1_2_CLIENT OPENSSL_NO_TLSEXT OPENSSL_NO_X509 OPENSSL_NO_X509_VERIFY -- Principal Security Engineer, Akamai Technologies IM: rs...@jabber.memailto:rs...@jabber.me Twitter: RichSalz ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Seeking feedback on some #ifdef changes
On Jan 23 19:11, Salz, Rich wrote: Looking at just OPENSSL_NO_xxx, we have over 100 openssl #ifdef options and we are considering removing nearly a third of them. Please reply soon if the following plan would cause problems. This will happen only in master, for post-1.0.2. We will remove the following options. You could argue that the OPENSSL_NO_SHAxxx options be treated as crypto, but OpenSSL does not compile without SHA and SHA1 defined, and we have no interest in spending the time to fix it. So for consistency, we will remove all of them. GENUINE_DSA (and the broken DSS0 since SHA0 will be removed) OPENSSL_NO_BIO OPENSSL_NO_BUFFER OPENSSL_NO_BUF_FREELISTS OPENSSL_NO_CHAIN_VERIFY OPENSSL_NO_DESCBCM (also removing the code; no EVP support) OPENSSL_NO_EVP OPENSSL_NO_FIPS_ERR OPENSSL_NO_HASH_COMP OPENSSL_NO_LHASH OPENSSL_NO_LOCKING OPENSSL_NO_MULTIBYTE (also removing the code) OPENSSL_NO_OBJECT OPENSSL_NO_RFC3779 OPENSSL_NO_SHA OPENSSL_NO_SHA0 (also removing the code for SHA0) OPENSSL_NO_SHA1 OPENSSL_NO_SHA224 OPENSSL_NO_SHA256 OPENSSL_NO_SHA384 OPENSSL_NO_SHA512 OPENSSL_NO_SPEED OPENSSL_NO_SSL_INTERN (first attempt at making things opaque) OPENSSL_NO_STACK OPENSSL_NO_STORE OPENSSL_NO_TLS OPENSSL_NO_TLS1 OPENSSL_NO_TLS1_2_CLIENT OPENSSL_NO_TLSEXT OPENSSL_NO_X509 OPENSSL_NO_X509_VERIFY For those of the flags controlling OS capabilities, it would be nice to have a brief description so the OS-specific maintainers can check removing some of them might be a problem. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat pgpLgIuMEXccY.pgp Description: PGP signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Seeking feedback on some #ifdef changes
For those of the flags controlling OS capabilities, it would be nice to have a brief description so the OS-specific maintainers can check removing some of them might be a problem. I don't think I understand what you mean, but the only OS related one is NO_BUF_FREELISTS, which has openssl create a cache of buffers for systems where malloc and free are too slow. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Seeking feedback on some #ifdef changes
On Jan 23 20:27, Salz, Rich wrote: For those of the flags controlling OS capabilities, it would be nice to have a brief description so the OS-specific maintainers can check removing some of ^^^ there was an if missing them might be a problem. I don't think I understand what you mean, but the only OS related one is NO_BUF_FREELISTS, which has openssl create a cache of buffers for systems where malloc and free are too slow. I was just asking if some of the flags handle OS-specific differences and if so, it would be nice to know which ones and what they were doing. This way platform maintainers of OpenSSL (Cygwin in my case) would know if they might get into trouble. But you already answered my question and it sounds like there's nothing to worry about :) Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat pgpOPzRLlBM5P.pgp Description: PGP signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Seeking feedback on some #ifdef changes
The only one of all those that matters (to me) is OPENSSL_NO_SSL_INTERN since that provides a way to anticipate the effects of this API change. I'm fine with it going, but it needs a specified replacement (even if the replacement is we'll do that by default). Currently for example Qt won't build with OPENSSL_NO_SSL_INTERN defined since there are fields used for NPN that we need (iirc). Cheers Rich. On 23 January 2015 at 19:11, Salz, Rich rs...@akamai.com wrote: Looking at just OPENSSL_NO_xxx, we have over 100 openssl #ifdef options and we are considering removing nearly a third of them. Please reply soon if the following plan would cause problems. This will happen only in master, for post-1.0.2. We will remove the following options. You could argue that the OPENSSL_NO_SHAxxx options be treated as crypto, but OpenSSL does not compile without SHA and SHA1 defined, and we have no interest in spending the time to fix it. So for consistency, we will remove all of them. GENUINE_DSA (and the broken DSS0 since SHA0 will be removed) OPENSSL_NO_BIO OPENSSL_NO_BUFFER OPENSSL_NO_BUF_FREELISTS OPENSSL_NO_CHAIN_VERIFY OPENSSL_NO_DESCBCM (also removing the code; no EVP support) OPENSSL_NO_EVP OPENSSL_NO_FIPS_ERR OPENSSL_NO_HASH_COMP OPENSSL_NO_LHASH OPENSSL_NO_LOCKING OPENSSL_NO_MULTIBYTE (also removing the code) OPENSSL_NO_OBJECT OPENSSL_NO_RFC3779 OPENSSL_NO_SHA OPENSSL_NO_SHA0 (also removing the code for SHA0) OPENSSL_NO_SHA1 OPENSSL_NO_SHA224 OPENSSL_NO_SHA256 OPENSSL_NO_SHA384 OPENSSL_NO_SHA512 OPENSSL_NO_SPEED OPENSSL_NO_SSL_INTERN (first attempt at making things opaque) OPENSSL_NO_STACK OPENSSL_NO_STORE OPENSSL_NO_TLS OPENSSL_NO_TLS1 OPENSSL_NO_TLS1_2_CLIENT OPENSSL_NO_TLSEXT OPENSSL_NO_X509 OPENSSL_NO_X509_VERIFY -- Principal Security Engineer, Akamai Technologies IM: rs...@jabber.me Twitter: RichSalz ___ 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
Re: [openssl-dev] Seeking feedback on some #ifdef changes
The only one of all those that matters (to me) is OPENSSL_NO_SSL_INTERN since that provides a way to anticipate the effects of this API change. I'm fine with it going, but it needs a specified replacement (even if the replacement is we'll do that by default). Currently for example Qt won't build with OPENSSL_NO_SSL_INTERN defined since there are fields used for NPN that we need (iirc). I hadn't thought of it as being a preview for what we plan to do. I guess it makes sense to keep it, at least until we have a preview of some kind that lets folks start building in the New World Order. Thanks! -- Principal Security Engineer, Akamai Technologies IM: rs...@jabber.me Twitter: RichSalz ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Seeking feedback on some #ifdef changes
On Fri, Jan 23, 2015 at 09:57:27PM +, Salz, Rich wrote: I hadn't thought of it as being a preview for what we plan to do. I guess it makes sense to keep it, at least until we have a preview of some kind that lets folks start building in the New World Order. I've used it to future-proof Postfix. It now builds with the NO_INTERN flag set. Keeping that flag makes sense. -- Viktor. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
