> 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 li
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:
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 c
> 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 tw
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
we
In message
<775c783c5fbe4855b5461ce51ad9b...@ustx2ex-dag1mb2.msg.corp.akamai.com> on Wed,
11 Feb 2015 00:25:35 +, "Salz, Rich" 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
On Tue, Feb 10, 2015 at 4:25 PM, Salz, Rich 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_
> 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
Salz, Rich 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 buil
> 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
> defin
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 followi
El 27/01/15 a las 08:30, Hanno Böck escribió:
Hello,
On Fri, 23 Jan 2015 19:11:35 +
"Salz, Rich" 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 protec
> 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
Hello,
On Fri, 23 Jan 2015 19:11:35 +
"Salz, Rich" 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 th
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-
> 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
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 wi
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
^^^
> 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 cr
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 rem
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 t
21 matches
Mail list logo
