Re: [openssl-project] The problem of (implicit) relinking and changed behaviour
On 04/15/18 07:53, Viktor Dukhovni wrote: > > >> On Apr 15, 2018, at 1:38 AM, Richard Levitte wrote: >> >> Errr, are we? Please inform me, because I cannot remember having seen >> tests that specifically targets the case of programs built with 1.1.0 >> that get implicitly relinked with 1.1.1 libraries (that's what you >> call "going forward", isn't it?), or data collection for that matter. >> I may have missed something, but I am interested. > > It think it is most prudent to not fall into the trap of debating this > particular side-issue. I commend your initiative of running the 1.1.0 > tests against the 1.1.1 libraries, that's fantastic. And I further > commend attention to the failure cases. Thank you. > > With that out of the way, it seems to me that apart from some fixes in > the test framework, and tests that did not expect protocol versions > higher than TLS 1.2, no *interesting* issues have turned up. > > If such issue did or will turn up let's fix them, but there should not > be fundamental obstacles to an ABI-compatible 1.1.1 library with the > same SONAME as its 1.1.0 predecessor. The new library may negotiate > TLS 1.3 which 1.1.0 did not, but I don't see that as an incompatibility > that requires an SONAME version bump. > > Which is not to say I could not be convinced otherwise, but at present > I don't see a need for the bump, or for work-arounds to limit the > negotiated protocols for code compiled against 1.1.0 that happens to > run against 1.1.1. > > Let's stay alert, but not overreact to minor issues we can resolve. > One possible example of application failure that I am aware of is #5743: A certificate that is incompatible with TLS1.3 but works with TLS1.2. Admittedly that I did come up with that scenario only because I saw a possible issue per code inspection. Bernd. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] The problem of (implicit) relinking and changed behaviour
> On Apr 15, 2018, at 1:38 AM, Richard Levitte wrote: > > Errr, are we? Please inform me, because I cannot remember having seen > tests that specifically targets the case of programs built with 1.1.0 > that get implicitly relinked with 1.1.1 libraries (that's what you > call "going forward", isn't it?), or data collection for that matter. > I may have missed something, but I am interested. It think it is most prudent to not fall into the trap of debating this particular side-issue. I commend your initiative of running the 1.1.0 tests against the 1.1.1 libraries, that's fantastic. And I further commend attention to the failure cases. Thank you. With that out of the way, it seems to me that apart from some fixes in the test framework, and tests that did not expect protocol versions higher than TLS 1.2, no *interesting* issues have turned up. If such issue did or will turn up let's fix them, but there should not be fundamental obstacles to an ABI-compatible 1.1.1 library with the same SONAME as its 1.1.0 predecessor. The new library may negotiate TLS 1.3 which 1.1.0 did not, but I don't see that as an incompatibility that requires an SONAME version bump. Which is not to say I could not be convinced otherwise, but at present I don't see a need for the bump, or for work-arounds to limit the negotiated protocols for code compiled against 1.1.0 that happens to run against 1.1.1. Let's stay alert, but not overreact to minor issues we can resolve. -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] The problem of (implicit) relinking and changed behaviour
In message on Sat, 14 Apr 2018 21:13:47 +, "Salz, Rich" said: rsalz> We have *no* data points, except our tests, that anything fails to work. rsalz> In fact, we are increasingly collecting data that shows everything is just fine. Errr, are we? Please inform me, because I cannot remember having seen tests that specifically targets the case of programs built with 1.1.0 that get implicitly relinked with 1.1.1 libraries (that's what you call "going forward", isn't it?), or data collection for that matter. I may have missed something, but I am interested. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] The problem of (implicit) relinking and changed behaviour
> On Apr 14, 2018, at 5:13 PM, Salz, Rich wrote: > > I believe we were led into the current situation, because our tests don't > completely work *going backwards.* Do the 1.1.0 tests basically work *going > forwards* ? It is unclear what you mean by forwards and backwards, but some 1.1.0 tests failed when using a 1.1.1 library. However, the tests that I read about failing were testing artificial expectations that are only appropriate for the same library as the tests. The tests can be fixed to make their expectations more explicit (by e.g. setting the max protocol version to the largest supported by the corresponding library). -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] The problem of (implicit) relinking and changed behaviour
> On Apr 14, 2018, at 5:09 PM, Richard Levitte wrote: > >> I just tested posttls-finger compiled for 1.1.0 running with a 1.1.1 >> library against a TLS 1.2 server and it worked fine. > > Does this answer the whole question, or do they just do the most basic > stuff that our public headers make available? No mere test constitutes a formal proof of correctness. I'm just saying that compile-time 1.1.0 runs fine in routine SSL sessions with 1.1.1 as the underlying library. The posttls-finger program is comparatively sophisticated in its use of SSL, but by no means tests the entire API. > To put it another way, I would absolutely hate it if, after 1.1.1 > (assuming that's what we go for) is released, people came back > screaming at us because their program toppled over or bailed out in a > virtual panic attack just because of a shared library upgrade. When support for TLS 1.2 appeared in OpenSSL, some Postfix users ran into some trouble, with middle-boxes or some such and had to cap the TLS version at TLS 1.0. This happened some time between 1.0.0 and 1.0.2 IIRC, with the library ABI at 1.0. This is to be expected. No matter what we do some users will upgrade their applications and/or OpenSSL library and find that they run into some friction with TLS 1.3. None of our work-arounds will make the problem go away. They'll just have to deal with it. > openssl-users> What version of OpenSSL is Postfix linked against on > mta.openssl.org? > openssl-users> Care to upgrade it to 1.1.0 if not already? Then replace the > libraries > openssl-users> with the 1.1.1 versions? I can then retest... > > But tell you what, there's a test machine as well, which I did set up > specifically for trying this sort of thing. I can certainly screw > around with all of that there. A test machine would be great. -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] The problem of (implicit) relinking and changed behaviour
We have *no* data points, except our tests, that anything fails to work. In fact, we are increasingly collecting data that shows everything is just fine. I believe we were led into the current situation, because our tests don't completely work *going backwards.* Do the 1.1.0 tests basically work *going forwards* ? ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] The problem of (implicit) relinking and changed behaviour
In message on Sat, 14 Apr 2018 16:46:56 -0400, Viktor Dukhovni said: openssl-users> > On Apr 14, 2018, at 4:40 PM, Richard Levitte wrote: openssl-users> > openssl-users> > Would you say that it's an application bug if it stumbles on a change openssl-users> > in API behavior that isn't due to a bug fix? (and even better, if it openssl-users> > worked according to documentation?) openssl-users> openssl-users> Negotiating a new version of TLS is not a change in API behaviour. The openssl-users> application asks for a TLS session (of no particular maximum version), openssl-users> and it gets one that both the client library and the peer support. openssl-users> openssl-users> I just tested posttls-finger compiled for 1.1.0 running with a 1.1.1 openssl-users> library against a TLS 1.2 server and it worked fine. Does this answer the whole question, or do they just do the most basic stuff that our public headers make available? To put it another way, I would absolutely hate it if, after 1.1.1 (assuming that's what we go for) is released, people came back screaming at us because their program toppled over or bailed out in a virtual panic attack just because of a shared library upgrade. I would prefer if we treated this with *certainties* rather than *probabilities*, and for the moment, it feels like I'm being fed with the latter rather than the former. openssl-users> What version of OpenSSL is Postfix linked against on mta.openssl.org? openssl-users> Care to upgrade it to 1.1.0 if not already? Then replace the libraries openssl-users> with the 1.1.1 versions? I can then retest... mta.openssl.org runs Ubuntu 16.04 and the as up to date packages as I get. I prefer to run things with vendor packages, so we have an easy path for updates, and considering that's our central mail hub, I'm not at all keen on potentially screwing things up there. But tell you what, there's a test machine as well, which I did set up specifically for trying this sort of thing. I can certainly screw around with all of that there. openssl-users> Running an MTA built for 1.1.0 against 1.1.1 libraries openssl-users> might be a reasonable way to "eat our own dog food". Yeeehhh, ya know, I do believe in eating your own dog food, but only to a level. Central production machinery that we all depend on is a big no-no in my admin brain. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] The problem of (implicit) relinking and changed behaviour
> On Apr 14, 2018, at 4:40 PM, Richard Levitte wrote: > > Would you say that it's an application bug if it stumbles on a change > in API behavior that isn't due to a bug fix? (and even better, if it > worked according to documentation?) Negotiating a new version of TLS is not a change in API behaviour. The application asks for a TLS session (of no particular maximum version), and it gets one that both the client library and the peer support. I just tested posttls-finger compiled for 1.1.0 running with a 1.1.1 library against a TLS 1.2 server and it worked fine. What version of OpenSSL is Postfix linked against on mta.openssl.org? Care to upgrade it to 1.1.0 if not already? Then replace the libraries with the 1.1.1 versions? I can then retest... Running an MTA built for 1.1.0 against 1.1.1 libraries might be a reasonable way to "eat our own dog food". -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] The problem of (implicit) relinking and changed behaviour
In message <44fe0745-31df-41c3-b697-97025643c...@dukhovni.org> on Sat, 14 Apr 2018 16:24:56 -0400, Viktor Dukhovni said: openssl-users> openssl-users> openssl-users> > On Apr 14, 2018, at 4:18 PM, Richard Levitte wrote: openssl-users> > openssl-users> >> Will real applications run into any meaningful problems? openssl-users> > openssl-users> > This is an argument that I find *terribly* frustrating. Are you openssl-users> > suggesting that we have no test that tries to do what can be expect openssl-users> > from a "real" application? openssl-users> openssl-users> I am suggesting that we ignore test failures that test for rather openssl-users> artificial conditions. If our test negotiates TLS with our own openssl-users> server and tests that it got exactly TLS 1.2 (because that's the openssl-users> highest version our test expected to support by default) that's an openssl-users> artificial test, and its failure is fine. Do all the tests do that, i.e. actually check that they got nothing higher than TLSv1.2? This is an open question, I haven't dived enough into the TLS stuff to know (but will next week unless someone can say for sure). If that is the case, then I agree that it's quite artificial. Otherwise, not so much. openssl-users> Real applications that want no more than TLS 1.2 need openssl-users> to set the max version, or not expect that maximum. openssl-users> Anything else is an application bug. Would you say that it's an application bug if it stumbles on a change in API behavior that isn't due to a bug fix? (and even better, if it worked according to documentation?) openssl-users> Do we have any meaningful test failures that are not openssl-users> artificial like the above? If so, we should fix them, openssl-users> if not we possibly need more tests, but are otherwise openssl-users> fine as best we know. I disagree with us being fine, unless the possible issue I'm raising can be disqualified with certainty. -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] The problem of (implicit) relinking and changed behaviour
> On Apr 14, 2018, at 4:18 PM, Richard Levitte wrote: > >> Will real applications run into any meaningful problems? > > This is an argument that I find *terribly* frustrating. Are you > suggesting that we have no test that tries to do what can be expect > from a "real" application? I am suggesting that we ignore test failures that test for rather artificial conditions. If our test negotiates TLS with our own server and tests that it got exactly TLS 1.2 (because that's the highest version our test expected to support by default) that's an artificial test, and its failure is fine. Real applications that want no more than TLS 1.2 need to set the max version, or not expect that maximum. Anything else is an application bug. Do we have any meaningful test failures that are not artificial like the above? If so, we should fix them, if not we possibly need more tests, but are otherwise fine as best we know. -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] The problem of (implicit) relinking and changed behaviour
In message <352ebaa2-b2d4-4a2e-adc4-1033a1735...@dukhovni.org> on Sat, 14 Apr 2018 16:01:42 -0400, Viktor Dukhovni said: openssl-users> > 2. Make TLSv1.2 the absolutely maximum TLS version available for openssl-users> > programs linked with libssl 1.1.0. This is what's done in this PR: openssl-users> > https://github.com/openssl/openssl/pull/5945 openssl-users> > This makes sense insofar that it's safe, it works within the known openssl-users> > parameters for the library these programs were built for. openssl-users> > It also makes sense if we view TLSv1.3 as new functionality, and openssl-users> > new functionality is usually only available to those who openssl-users> > explicitely build their programs for the new library version. openssl-users> > TLSv1.3 is unusual in this sense because it's at least it great openssl-users> > part "under the hood", just no 100% transparently so. openssl-users> openssl-users> This should NOT be necessary. What it is about enabling TLS 1.3 openssl-users> that breaks existing code? Let's fix that. I'm not savvy enough to answer that properly. I'm mostly observing from the exterior. openssl-users> > 3. I dunno, please share ideas if you have them. openssl-users> openssl-users> We need to make sure that the introduction of TLS 1.3 is transparent, openssl-users> aside from occasionally leading to a connection that uses TLS 1.3. openssl-users> openssl-users> If all that's failing is our test-suite, which is too sensitive to the openssl-users> underlying implementation details, that's fine, not all the tests are openssl-users> designed to run cross-library. openssl-users> openssl-users> Will real applications run into any meaningful problems? This is an argument that I find *terribly* frustrating. Are you suggesting that we have no test that tries to do what can be expect from a "real" application? What do you expect a "real" application to limit itself to? Do you expect a "real" application to always set a maximum TLS version? Do you expect a "real" application to expect failure because it hasn't? Was any of the limitations you might think of advertised? In the 1.1.0 manual pages? Elsewhere? Also, I imagine that test_ssl_old, test_ssl_new and test_sslapi are three tests that do try to mimic "real world" use of libssl. openssl-users> While can artificially limit the max protocol in applications compiled openssl-users> for 1.1.0, I don't think that's a compelling design choice. We have openssl-users> support in 1.1.0 for min/max protocol, applications can use those openssl-users> controls explicitly. Yes, they can, but they won't necessarely. Just as an example, our 1.1.0 test programs didn't before I stoopidly made them do so (I'm reverting that with https://github.com/openssl/openssl/pull/5947, because it was an enormously stoopid move that only showed that an upgrade to 1.1.1 *required* at least the addition of such controls) openssl-users> In any case in order of preference, I'd like to see: openssl-users> openssl-users> 1. Fix any issues so that it is safe to upgrade. openssl-users> 2. Make the library version 1.2 openssl-users> 3. Hack the API to cap the protocol version based on compile-time openssl-users> maximum. openssl-users> openssl-users> -- openssl-users> -- openssl-users> Viktor. -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] The problem of (implicit) relinking and changed behaviour
I have not heard that any application program -- NOT COUNTING OUR TESTS -- that break. The one counterpoint we have is that s_client/s_server work. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] The problem of (implicit) relinking and changed behaviour
> On Apr 14, 2018, at 3:32 PM, Richard Levitte wrote: > > So regarding assumptions, there's only one assumption that I'm ready > to make: a program that worked correctly with libssl 1.1.0 and uses > its functionality as advertised should work the same with libssl > 1.1.1. Note that I'm not saying that this excludes new features > "under the hood", but in that case, those new features should work > transparently enough that a program doesn't need to be changed because > of them. Also, note again that I'm not talking about recompilation, > but the implicit relinking that is what happens when a shared library > is upgraded but keeps the same library version number (no "bump"). > (mind you, explicit relinking would make no different in this regard). > > Does anyone disagree with that assumption? It must be possible to upgrade from 1.1.0 to 1.1.1 without source code changes, or relinking the program. From what you describe, it seems that source code changes might be needed to adapt to a TLS-1.3-capable library. That should not happen. > 1. There's the option of making the new release 1.2.0 instead of 1.1.1. > I think most of us aren't keen on this, but it has to be said. This does not address the issue of yet another compatibility break, with many distributions not yet done adopting 1.1.0. So I don't see that as a solution. > 2. Make TLSv1.2 the absolutely maximum TLS version available for > programs linked with libssl 1.1.0. This is what's done in this PR: > https://github.com/openssl/openssl/pull/5945 > This makes sense insofar that it's safe, it works within the known > parameters for the library these programs were built for. > It also makes sense if we view TLSv1.3 as new functionality, and > new functionality is usually only available to those who > explicitely build their programs for the new library version. > TLSv1.3 is unusual in this sense because it's at least it great > part "under the hood", just no 100% transparently so. This should NOT be necessary. What it is about enabling TLS 1.3 that breaks existing code? Let's fix that. > 3. I dunno, please share ideas if you have them. We need to make sure that the introduction of TLS 1.3 is transparent, aside from occasionally leading to a connection that uses TLS 1.3. If all that's failing is our test-suite, which is too sensitive to the underlying implementation details, that's fine, not all the tests are designed to run cross-library. Will real applications run into any meaningful problems? While can artificially limit the max protocol in applications compiled for 1.1.0, I don't think that's a compelling design choice. We have support in 1.1.0 for min/max protocol, applications can use those controls explicitly. In any case in order of preference, I'd like to see: 1. Fix any issues so that it is safe to upgrade. 2. Make the library version 1.2 3. Hack the API to cap the protocol version based on compile-time maximum. -- -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] The problem of (implicit) relinking and changed behaviour
On Sat, Apr 14, 2018 at 09:54:41PM +0200, Richard Levitte wrote: > Yes, I agree that the TLSProxy tests aren't the most important in this > regard. Also note that this part was a side note. Can you then find examples of what a normal user of the library might be expected to do that fails? I know some other libraries have tests to see if version negiotation works properly. I expect those tests to fail, but I don't see this as a problem because the tests don't know about TLSv1.3 yet, and the library itself and it's users will work without problems. Kurt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] The problem of (implicit) relinking and changed behaviour
In message <20180414194244.ga27...@roeckx.be> on Sat, 14 Apr 2018 21:42:45 +0200, Kurt Roeckx said: kurt> On Sat, Apr 14, 2018 at 09:32:31PM +0200, Richard Levitte wrote: kurt> > kurt> > a. 1.1.0's test/recipes/70-test_sslextension.t has a couple of tests kurt> >that are meant to fail (i.e. if the individual tests fail, the kurt> >recipe is successful). When run against 1.1.1 libraries, the kurt> >recipe fails, i.e. the injection of double hellos didn't get the kurt> >communication to fail, or so it seems... kurt> kurt> This seems to be a test that is very aware of the protocol, and kurt> what should fail and what shouldn't. If you introduce a new kurt> protocol, the things it check might need to be updated. This is kurt> not something a normal application will be doing, so I don't see kurt> this as a problem. Yes, I agree that the TLSProxy tests aren't the most important in this regard. Also note that this part was a side note. -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] The problem of (implicit) relinking and changed behaviour
On Sat, Apr 14, 2018 at 09:32:31PM +0200, Richard Levitte wrote: > > a. 1.1.0's test/recipes/70-test_sslextension.t has a couple of tests >that are meant to fail (i.e. if the individual tests fail, the >recipe is successful). When run against 1.1.1 libraries, the >recipe fails, i.e. the injection of double hellos didn't get the >communication to fail, or so it seems... This seems to be a test that is very aware of the protocol, and what should fail and what shouldn't. If you introduce a new protocol, the things it check might need to be updated. This is not something a normal application will be doing, so I don't see this as a problem. Kurt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
[openssl-project] The problem of (implicit) relinking and changed behaviour
Hi, First, a note: I don't want this discussion to be just about technical details, but also about philosophy, and guidance for policy making in the long run. My feeling is that we've been... well, a bit lax with regards to library upgrade and program relinking (explicit or implicit, that shouldn't really matter). Some time ago, I engaged in the exercise to see how well the test programs from the 1.1.0 branch would do if linked with the 1.1.1 libraries (i.e. simulating a shared library upgrade from 1.1.0 to 1.1.1). See https://github.com/openssl/openssl/issues/5661 The conclusion drawn from this exercise is that TLSv1.3 has introduced a behaviour in libssl 1.1.1 that is incompatible with libssl 1.1.0. Not in every function, so for example, running basic s_server or s_client without any special options will work without issues, but just the fact that some amount of 1.1.0 tests fail when faced with libssl 1.1.1 tells me that there are some incompatibilities to deal with. Of course, one might argue that one can assume that a program that can't deal with certain details will tell libssl to stick with TLSv1.2 or older... but I'm unsure if such assumptions are realistic, and I'm again looking at the 1.1.0 test failures. Obviously, *we* didn't work along such assumptions. So regarding assumptions, there's only one assumption that I'm ready to make: a program that worked correctly with libssl 1.1.0 and uses its functionality as advertised should work the same with libssl 1.1.1. Note that I'm not saying that this excludes new features "under the hood", but in that case, those new features should work transparently enough that a program doesn't need to be changed because of them. Also, note again that I'm not talking about recompilation, but the implicit relinking that is what happens when a shared library is upgraded but keeps the same library version number (no "bump"). (mind you, explicit relinking would make no different in this regard). Does anyone disagree with that assumption? So, how to deal with this? 1. There's the option of making the new release 1.2.0 instead of 1.1.1. I think most of us aren't keen on this, but it has to be said. 2. Make TLSv1.2 the absolutely maximum TLS version available for programs linked with libssl 1.1.0. This is what's done in this PR: https://github.com/openssl/openssl/pull/5945 This makes sense insofar that it's safe, it works within the known parameters for the library these programs were built for. It also makes sense if we view TLSv1.3 as new functionality, and new functionality is usually only available to those who explicitely build their programs for the new library version. TLSv1.3 is unusual in this sense because it's at least it great part "under the hood", just no 100% transparently so. 3. I dunno, please share ideas if you have them. Side discussion: Some of the failing 1.1.0 tests shows that we've made some changes in 1.1.1 that we might not have thought would disrupt anything. a. 1.1.0's test/recipes/70-test_sslextension.t has a couple of tests that are meant to fail (i.e. if the individual tests fail, the recipe is successful). When run against 1.1.1 libraries, the recipe fails, i.e. the injection of double hellos didn't get the communication to fail, or so it seems... b. 1.1.0's test/recipes/80-test_ssl_new.t fails in the second test (protocol version checks) because it expects an InternalError alert, but gets ClientFail instead. So the question here is, what if some program actually pays attention to them? ... and it also begs the question if the alert type change was a bug fix, and in that case, why didn't it propagate to 1.1.0? Should it? Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
