[openssl-dev] Seeking feedback on some #ifdef changes

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[openssl-dev] Seeking feedback on some #ifdef changes

Salz, Rich

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: [hidden email] Twitter: RichSalz

 


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Seeking feedback on some #ifdef changes

Corinna Vinschen
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

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Seeking feedback on some #ifdef changes

Salz, Rich
> 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
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Seeking feedback on some #ifdef changes

Corinna Vinschen
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

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Seeking feedback on some #ifdef changes

Richard Moore
In reply to this post by Salz, Rich
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 <[hidden email]> 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: [hidden email] 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
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Seeking feedback on some #ifdef changes

Salz, Rich
> 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: [hidden email] Twitter: RichSalz
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Seeking feedback on some #ifdef changes

Viktor Dukhovni
On Fri, Jan 23, 2015 at 09:57:27PM +0000, 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
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Seeking feedback on some #ifdef changes

Hanno Böck-4
In reply to this post by Salz, Rich
Hello,

On Fri, 23 Jan 2015 19:11:35 +0000
"Salz, Rich" <[hidden email]> 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: [hidden email]
GPG: BBB51E42

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Seeking feedback on some #ifdef changes

Salz, Rich
> 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
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Seeking feedback on some #ifdef changes

Cristian Rodríguez
In reply to this post by Hanno Böck-4
El 27/01/15 a las 08:30, Hanno Böck escribió:

> Hello,
>
> On Fri, 23 Jan 2015 19:11:35 +0000
> "Salz, Rich" <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Seeking feedback on some #ifdef changes

Roumen Petrov
In reply to this post by Salz, Rich
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
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Seeking feedback on some #ifdef changes

Salz, Rich
> 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
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Seeking feedback on some #ifdef changes

Brian Smith
In reply to this post by Salz, Rich
Salz, Rich <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Seeking feedback on some #ifdef changes

Salz, Rich

> 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
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Seeking feedback on some #ifdef changes

Brian Smith
On Tue, Feb 10, 2015 at 4:25 PM, Salz, Rich <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Seeking feedback on some #ifdef changes

Richard Levitte - VMS Whacker
In reply to this post by Salz, Rich
In message <[hidden email]> on Wed, 11 Feb 2015 00:25:35 +0000, "Salz, Rich" <[hidden email]> 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                         [hidden email]
                                        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
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Seeking feedback on some #ifdef changes

John Foley-3
In reply to this post by Salz, Rich
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: [hidden email] 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
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Seeking feedback on some #ifdef changes

Salz, Rich
> 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
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Seeking feedback on some #ifdef changes

Tomas Mraz-2
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
Reply | Threaded
Open this post in threaded view
|

Re: [openssl-dev] Seeking feedback on some #ifdef changes

Alexey Bakhtin
In reply to this post by Richard Levitte - VMS Whacker
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
12