Re: [openssl-dev] [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2
[moving from github to -dev] On 01/27/2017 07:36 AM, mattcaswell wrote: > > 1.0.2 is the software version. > The numbers on the end of lbssl.so.1.0.0 refer to the ABI version - > which is different. Software version 1.0.2 is a drop in replacement > for 1.0.1, which is a drop in replacement for 1.0.0 - hence they all > have the same ABI version. > > There was some discussion about 1.0.1 being EoL on a FreeBSD list [0], and whether it would make sense to move to 1.0.2 on their stable branch, which led to someone making the claim that 1.0.2 has removed 4 symbols compared to 1.0.1, and thus is not strictly ABI compatible, linking to https://abi-laboratory.pro/tracker/timeline/openssl/ . If I start semi-randomly clicking around, I can find a page [1] that seems to claim the missing symbols are: ASN1_STRING_clear_free() ENGINE_load_rsax() SRP_user_pwd_free() SRP_VBASE_get1_by_user() It may be too late to get the 1.0.x series fully compatible, but it's probably worth thinking about how we can use automation to ensure that the 1.1.x series remains ABI compatible going forward. I just learned about abi-laboratory.pro from the FreeBSD posting, so I don't know if it is appropriate or we would want to use some other tool. One (naive?) idea for a home-grown solution would be to come up with a scheme to serialize the public ABI to a file in the repo, maybe regenerated as part of 'make test', and ensure that that file is append-only, at least between releases. But I don't know if the state of the art is more advanced than that -- are there better options? -Ben [0] https://lists.freebsd.org/pipermail/freebsd-security/2017-January/009211.html [1] https://abi-laboratory.pro/tracker/compat_report/openssl/1.0.1u/1.0.2/c63bf/abi_compat_report.html#Removed -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2
On 27/01/17 16:54, Benjamin Kaduk via openssl-dev wrote: > [moving from github to -dev] > > On 01/27/2017 07:36 AM, mattcaswell wrote: >> >> 1.0.2 is the software version. >> The numbers on the end of lbssl.so.1.0.0 refer to the ABI version - >> which is different. Software version 1.0.2 is a drop in replacement >> for 1.0.1, which is a drop in replacement for 1.0.0 - hence they all >> have the same ABI version. >> >> > > There was some discussion about 1.0.1 being EoL on a FreeBSD list [0], > and whether it would make sense to move to 1.0.2 on their stable branch, > which led to someone making the claim that 1.0.2 has removed 4 symbols > compared to 1.0.1, and thus is not strictly ABI compatible, linking to > https://abi-laboratory.pro/tracker/timeline/openssl/ . If I start > semi-randomly clicking around, I can find a page [1] that seems to claim > the missing symbols are: > ASN1_STRING_clear_free() > ENGINE_load_rsax() > SRP_user_pwd_free() > SRP_VBASE_get1_by_user() > > It may be too late to get the 1.0.x series fully compatible, but it's Why can't we just add those symbols back in? I'm not sure why they were removed...we should look at that, but if nothing else make them no-ops or something. I'd look on it as a bug if there are missing symbols. > probably worth thinking about how we can use automation to ensure that > the 1.1.x series remains ABI compatible going forward. I just learned > about abi-laboratory.pro from the FreeBSD posting, so I don't know if it > is appropriate or we would want to use some other tool. > There is an abi build for 1.0.2 here already: https://openssl-sanity.cisco.com:8443/job/1_0_2_abi/ Unfortunately John Foley left cisco so AFAIK this farm is no longer being maintained...although it is still running. Matt > One (naive?) idea for a home-grown solution would be to come up with a > scheme to serialize the public ABI to a file in the repo, maybe > regenerated as part of 'make test', and ensure that that file is > append-only, at least between releases. But I don't know if the state > of the art is more advanced than that -- are there better options? > > -Ben > > > [0] > https://lists.freebsd.org/pipermail/freebsd-security/2017-January/009211.html > [1] > https://abi-laboratory.pro/tracker/compat_report/openssl/1.0.1u/1.0.2/c63bf/abi_compat_report.html#Removed > > -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2
The tool looks good, but either you didn't find the right link, or it's got bugs. Of the four symbols you found, ASN1_STRING_clear_free(), SRP_user_pwd_free(), and SRP_VBASE_get1_by_user() all exist; only ENGINE_load_rsax() was removed. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richs...@jabber.at Twitter: RichSalz -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2
Hi, SRP_VBASE_get1_by_user() was ADDED to 1.0.2g 1 march 2016 [CVE-2016-0798]. I remember it very well ! ;-) Michel -Message d'origine- De : openssl-dev [mailto:openssl-dev-boun...@openssl.org] De la part de Salz, Rich via openssl-dev Envoyé : vendredi 27 janvier 2017 19:49 À : Kaduk, Ben; openssl-dev@openssl.org Objet : Re: [openssl-dev] [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2 The tool looks good, but either you didn't find the right link, or it's got bugs. Of the four symbols you found, ASN1_STRING_clear_free(), SRP_user_pwd_free(), and SRP_VBASE_get1_by_user() all exist; only ENGINE_load_rsax() was removed. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2
I guess the dashboard is only picking up incremental differences, then, so the four missing symbols is just for 1.0.1u to 1.0.2 (no letter); any symbols that were added to both 1.0.1 and 1.0.2 letter releases (e.g., for CVE fixes) would show up as "removed" since they weren't in the initial 1.0.2 release. I guess the tool needs more investigation than the quickest look... -Ben On 01/27/2017 02:43 PM, Michel wrote: > Hi, > SRP_VBASE_get1_by_user() was ADDED to 1.0.2g 1 march 2016 [CVE-2016-0798]. > I remember it very well ! > ;-) > > Michel > > -Message d'origine- > De : openssl-dev [mailto:openssl-dev-boun...@openssl.org] De la part de > Salz, Rich via openssl-dev > Envoyé : vendredi 27 janvier 2017 19:49 > À : Kaduk, Ben; openssl-dev@openssl.org > Objet : Re: [openssl-dev] [openssl/openssl] ABI compatibility > 1.0.0-->1.0.1-->1.0.2 > > The tool looks good, but either you didn't find the right link, or it's got > bugs. Of the four symbols you found, ASN1_STRING_clear_free(), > SRP_user_pwd_free(), and SRP_VBASE_get1_by_user() all exist; only > ENGINE_load_rsax() was removed. > -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2
On Fri, 2017-01-27 at 10:54 -0600, Benjamin Kaduk via openssl-dev wrote: > [moving from github to -dev] > > On 01/27/2017 07:36 AM, mattcaswell wrote: > > 1.0.2 is the software version. > > The numbers on the end of lbssl.so.1.0.0 refer to the ABI version - > > which is different. Software version 1.0.2 is a drop in replacement > > for 1.0.1, which is a drop in replacement for 1.0.0 - hence they > > all have the same ABI version. > > > > There was some discussion about 1.0.1 being EoL on a FreeBSD list > [0], and whether it would make sense to move to 1.0.2 on their stable > branch, which led to someone making the claim that 1.0.2 has removed > 4 symbols compared to 1.0.1, and thus is not strictly ABI compatible, > linking to https://abi-laboratory.pro/tracker/timeline/openssl/ . If > I start semi-randomly clicking around, I can find a page [1] that > seems to claim the missing symbols are: > ASN1_STRING_clear_free() > ENGINE_load_rsax() > SRP_user_pwd_free() > SRP_VBASE_get1_by_user() > > ... > One (naive?) idea for a home-grown solution would be to come up with > a scheme to serialize the public ABI to a file in the repo, maybe > regenerated as part of 'make test', and ensure that that file is > append-only, at least between releases. But I don't know if the > state of the art is more advanced than that -- are there better > options? The abi-dumper and abi-compliance-checker tools can be used for that purpose. In fact they are the back-end tools used by the abi-laboratory you quote above. regards, Nikos -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2
31.01.2017, 10:21, "Nikos Mavrogiannopoulos": > On Fri, 2017-01-27 at 10:54 -0600, Benjamin Kaduk via openssl-dev > wrote: >> [moving from github to -dev] >> >> On 01/27/2017 07:36 AM, mattcaswell wrote: >> > 1.0.2 is the software version. >> > The numbers on the end of lbssl.so.1.0.0 refer to the ABI version - >> > which is different. Software version 1.0.2 is a drop in replacement >> > for 1.0.1, which is a drop in replacement for 1.0.0 - hence they >> > all have the same ABI version. >> > >> >> There was some discussion about 1.0.1 being EoL on a FreeBSD list >> [0], and whether it would make sense to move to 1.0.2 on their stable >> branch, which led to someone making the claim that 1.0.2 has removed >> 4 symbols compared to 1.0.1, and thus is not strictly ABI compatible, >> linking to https://abi-laboratory.pro/tracker/timeline/openssl/ . If >> I start semi-randomly clicking around, I can find a page [1] that >> seems to claim the missing symbols are: >> ASN1_STRING_clear_free() >> ENGINE_load_rsax() >> SRP_user_pwd_free() >> SRP_VBASE_get1_by_user() > > ... >> One (naive?) idea for a home-grown solution would be to come up with >> a scheme to serialize the public ABI to a file in the repo, maybe >> regenerated as part of 'make test', and ensure that that file is >> append-only, at least between releases. But I don't know if the >> state of the art is more advanced than that -- are there better >> options? > > The abi-dumper and abi-compliance-checker tools can be used for that > purpose. In fact they are the back-end tools used by the abi-laboratory > you quote above. Hello, These pages on OpenSSL wiki may be helpful: https://wiki.openssl.org/index.php/Binary_Compatibility https://wiki.openssl.org/index.php/ABI_Tracker Thank you. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2
In message on Fri, 27 Jan 2017 10:54:35 -0600, Benjamin Kaduk via openssl-dev said: openssl-dev> There was some discussion about 1.0.1 being EoL on a FreeBSD list [0], openssl-dev> and whether it would make sense to move to 1.0.2 on their stable openssl-dev> branch, which led to someone making the claim that 1.0.2 has removed 4 openssl-dev> symbols compared to 1.0.1, and thus is not strictly ABI compatible, openssl-dev> linking to https://abi-laboratory.pro/tracker/timeline/openssl/ . If I openssl-dev> start semi-randomly clicking around, I can find a page [1] that seems openssl-dev> to claim the missing symbols are: openssl-dev> ASN1_STRING_clear_free() openssl-dev> ENGINE_load_rsax() openssl-dev> SRP_user_pwd_free() openssl-dev> SRP_VBASE_get1_by_user() I haven't make a complete analysis over versions, just did a comparison of the files that define what we regard as public symbols (util/libeay.num and util/libssl.num) in the latest 1.0.1 and 1.0.2 releases. Diffs attached. As you can see, ENGINE_load_rsax *did* go away. That happened here: commit 74184b6f21e095dacd6193a78785a47dd515f0dc Author: Dr. Stephen Henson Date: Sun Dec 1 23:06:33 2013 + RSAX no longer compiled. I'm afraid I can't remember the reasoning behind this commit... The rest of those mentioned above haven't moved at all as far as I can see. You may notice that some of the symbols in libssl (ssleay.num) did move between "modules" (which in this case can be defined as a keyword you can say no to when configuring). I'm unsure how that affects your view on our stability, suffice to say that with default configuration, it doesn't affect the ABI one bit. FYI, here's how the diffs were produced: : ; (LANG=C; (cd ../1.0.1; pwd; git status); pwd; git status; diff -u ../1.0.1/util/libeay.num util/libeay.num > /tmp/libeay.num.diff) /home/levitte/gitwrk/openssl.net/official/1.0.1 HEAD detached at OpenSSL_1_0_1u nothing to commit, working tree clean /home/levitte/gitwrk/openssl.net/official/1.0.2 HEAD detached at OpenSSL_1_0_2k nothing to commit, working tree clean : ; (LANG=C; (cd ../1.0.1; pwd; git status); pwd; git status; diff -u ../1.0.1/util/ssleay.num util/ssleay.num > /tmp/ssleay.num.diff) /home/levitte/gitwrk/openssl.net/official/1.0.1 HEAD detached at OpenSSL_1_0_1u nothing to commit, working tree clean /home/levitte/gitwrk/openssl.net/official/1.0.2 HEAD detached at OpenSSL_1_0_2k nothing to commit, working tree clean Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ --- ../1.0.1/util/libeay.num 2016-06-30 01:06:40.0 +0200 +++ util/libeay.num 2017-01-26 11:46:30.640419220 +0100 @@ -4284,7 +4284,7 @@ CRYPTO_ccm128_aad 4649 EXIST::FUNCTION: CRYPTO_gcm128_init 4650 EXIST::FUNCTION: CRYPTO_gcm128_decrypt 4651 EXIST::FUNCTION: -ENGINE_load_rsax4652 EXIST::FUNCTION:ENGINE +ENGINE_load_rsax4652 NOEXIST::FUNCTION: CRYPTO_gcm128_decrypt_ctr32 4653 EXIST::FUNCTION: CRYPTO_gcm128_encrypt_ctr32 4654 EXIST::FUNCTION: CRYPTO_gcm128_finish4655 EXIST::FUNCTION: @@ -4316,3 +4316,103 @@ BIO_s_datagram_sctp 4680 EXIST::FUNCTION:DGRAM,SCTP BIO_dgram_is_sctp 4681 EXIST::FUNCTION:SCTP BIO_dgram_sctp_notification_cb 4682 EXIST::FUNCTION:SCTP +i2d_DHxparams 4683 EXIST::FUNCTION:DH +EC_curve_nist2nid 4684 EXIST::FUNCTION:EC +DH_get_1024_160 4685 EXIST::FUNCTION:DH +PEM_write_DHxparams 4686 EXIST:!WIN16:FUNCTION:DH +d2i_DHxparams 4687 EXIST::FUNCTION:DH +EC_curve_nid2nist 4688 EXIST::FUNCTION:EC +DH_get_2048_256 4689 EXIST::FUNCTION:DH +PEM_write_bio_DHxparams 4690 EXIST::FUNCTION:DH +DH_get_2048_224 4691 EXIST::FUNCTION:DH +X509_chain_check_suiteb 4692 EXIST::FUNCTION: +X509_chain_up_ref 4693 EXIST::FUNCTION: +X509_VERIFY_PARAM_set1_ip_asc 4694 EXIST::FUNCTION: +X509_CRL_check_suiteb 4695 EXIST::FUNCTION: +X509_VERIFY_PARAM_set1_email4696 EXIST::FUNCTION: +X509_check_email4697 EXIST::FUNCTION: +X509_check_host 4698 EXIST::FUNCTION: +X509_check_ip_asc 4699 EXIST::FUNCTION: +X509_get0_signature 4700 EXIST::FUNCTION: +X509_get_signature_nid 4701 EXIST::FUNCTION: +X509_VERIFY_PARAM_set1_host 4702 EXIST::FUNCTION: +X509_VERIFY_PARAM_set1_ip 4703 EXIST::FUNCTION: +X509_check_ip 4704 EXIST::FUNCTION: +X509_STORE_set_lookup_crls_cb 47
Re: [openssl-dev] [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2
On Sun, Feb 26, 2017 at 09:26:06AM +0300, Andrey Ponomarenko wrote: > 31.01.2017, 10:21, "Nikos Mavrogiannopoulos": > > On Fri, 2017-01-27 at 10:54 -0600, Benjamin Kaduk via openssl-dev > > wrote: > >> [moving from github to -dev] > >> > >> On 01/27/2017 07:36 AM, mattcaswell wrote: > >> > 1.0.2 is the software version. > >> > The numbers on the end of lbssl.so.1.0.0 refer to the ABI version - > >> > which is different. Software version 1.0.2 is a drop in replacement > >> > for 1.0.1, which is a drop in replacement for 1.0.0 - hence they > >> > all have the same ABI version. > >> > > >> > >> There was some discussion about 1.0.1 being EoL on a FreeBSD list > >> [0], and whether it would make sense to move to 1.0.2 on their stable > >> branch, which led to someone making the claim that 1.0.2 has removed > >> 4 symbols compared to 1.0.1, and thus is not strictly ABI compatible, > >> linking to https://abi-laboratory.pro/tracker/timeline/openssl/ . If > >> I start semi-randomly clicking around, I can find a page [1] that > >> seems to claim the missing symbols are: > >> ASN1_STRING_clear_free() > >> ENGINE_load_rsax() > >> SRP_user_pwd_free() > >> SRP_VBASE_get1_by_user() It's normal that you might see some symbols removed if you compare something like 1.0.1t against 1.0.2, but it shouldn't when compared to 1.0.2k. CRYPTO_memcmp was added in 1.0.1d. ASN1_STRING_clear_free was added in 1.0.1m and 1.0.2a In 1.0.1s and 1.0.2g the following were added (for CVE-2016-0798): SRP_VBASE_get1_by_user; SRP_user_pwd_free; ENGINE_load_rsax seems to have been removed because it didn't compile? That looks like the only symbol that has been removed, and it probably shouldn't have. Kurt -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2
26.02.2017, 16:27, "Kurt Roeckx":> On Sun, Feb 26, 2017 at 09:26:06AM +0300, Andrey Ponomarenko wrote:>> 31.01.2017, 10:21, "Nikos Mavrogiannopoulos":>> > On Fri, 2017-01-27 at 10:54 -0600, Benjamin Kaduk via openssl-dev>> > wrote:>> >> [moving from github to -dev]>> >> On 01/27/2017 07:36 AM, mattcaswell wrote:>> >> > 1.0.2 is the software version.>> >> > The numbers on the end of lbssl.so.1.0.0 refer to the ABI version ->> >> > which is different. Software version 1.0.2 is a drop in replacement>> >> > for 1.0.1, which is a drop in replacement for 1.0.0 - hence they>> >> > all have the same ABI version.>> >> >>> >> There was some discussion about 1.0.1 being EoL on a FreeBSD list>> >> [0], and whether it would make sense to move to 1.0.2 on their stable>> >> branch, which led to someone making the claim that 1.0.2 has removed>> >> 4 symbols compared to 1.0.1, and thus is not strictly ABI compatible,>> >> linking to https://abi-laboratory.pro/tracker/timeline/openssl/ . If>> >> I start semi-randomly clicking around, I can find a page [1] that>> >> seems to claim the missing symbols are:>> >> ASN1_STRING_clear_free()>> >> ENGINE_load_rsax()>> >> SRP_user_pwd_free()>> >> SRP_VBASE_get1_by_user()>> It's normal that you might see some symbols removed if you compare> something like 1.0.1t against 1.0.2, but it shouldn't when compared> to 1.0.2k.>> CRYPTO_memcmp was added in 1.0.1d.>> ASN1_STRING_clear_free was added in 1.0.1m and 1.0.2a>> In 1.0.1s and 1.0.2g the following were added (for CVE-2016-0798):> SRP_VBASE_get1_by_user;> SRP_user_pwd_free;>> ENGINE_load_rsax seems to have been removed because it didn't> compile? That looks like the only symbol that has been removed,> and it probably shouldn't have.>> Kurt I found new ABI navigator reports to be very useful when checking for these symbols: https://abi-laboratory.pro/index.php?view=navigator&selected=SRP_VBASE_get1_by_user#resulthttps://abi-laboratory.pro/index.php?view=navigator&selected=ASN1_STRING_clear_free#result Thank you.-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2
On 02/26/2017 07:26 AM, Kurt Roeckx wrote: > It's normal that you might see some symbols removed if you compare > something like 1.0.1t against 1.0.2, but it shouldn't when compared > to 1.0.2k. I agree, and figured this out at some point after I sent the initial query. Given the low interest leve the thread had at the time, I didn't see a need to send a follow-up clarifying. > CRYPTO_memcmp was added in 1.0.1d. > > ASN1_STRING_clear_free was added in 1.0.1m and 1.0.2a > > In 1.0.1s and 1.0.2g the following were added (for CVE-2016-0798): > SRP_VBASE_get1_by_user; > SRP_user_pwd_free; > > ENGINE_load_rsax seems to have been removed because it didn't > compile? That looks like the only symbol that has been removed, > and it probably shouldn't have. > Someone(TM) should probably make a pull request to put back a stub function, then. (Maybe something for tomorrow's code health exercies...) I wonder if the ABI laboratory has a way to compare specific versions that are not direct successors, so that the tip of 1.0.1 could be compared to the tip of 1.0.2 (which is what would make the most sense to compare, to me). (I couldn't find such a thing with my random clicking around.) -Ben -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2
On 02/26/2017 02:10 AM, Richard Levitte wrote: > In message on Fri, 27 Jan > 2017 10:54:35 -0600, Benjamin Kaduk via openssl-dev > said: > > openssl-dev> There was some discussion about 1.0.1 being EoL on a FreeBSD > list [0], > openssl-dev> and whether it would make sense to move to 1.0.2 on their stable > openssl-dev> branch, which led to someone making the claim that 1.0.2 has > removed 4 > openssl-dev> symbols compared to 1.0.1, and thus is not strictly ABI > compatible, > openssl-dev> linking to https://abi-laboratory.pro/tracker/timeline/openssl/ > . If I > openssl-dev> start semi-randomly clicking around, I can find a page [1] that > seems > openssl-dev> to claim the missing symbols are: > openssl-dev> ASN1_STRING_clear_free() > openssl-dev> ENGINE_load_rsax() > openssl-dev> SRP_user_pwd_free() > openssl-dev> SRP_VBASE_get1_by_user() > > I haven't make a complete analysis over versions, just did a > comparison of the files that define what we regard as public symbols > (util/libeay.num and util/libssl.num) in the latest 1.0.1 and 1.0.2 > releases. Diffs attached. > > As you can see, ENGINE_load_rsax *did* go away. That happened here: > > commit 74184b6f21e095dacd6193a78785a47dd515f0dc > Author: Dr. Stephen Henson > Date: Sun Dec 1 23:06:33 2013 + > > RSAX no longer compiled. > > I'm afraid I can't remember the reasoning behind this commit... > > The rest of those mentioned above haven't moved at all as far as I can > see. You may notice that some of the symbols in libssl (ssleay.num) > did move between "modules" (which in this case can be defined as a > keyword you can say no to when configuring). I'm unsure how that > affects your view on our stability, suffice to say that with default > configuration, it doesn't affect the ABI one bit. > Agreed. Though, just the presence of a function/symbol does not preclude ABI changes for that symbol, if the function signature (or behavior) changed. -Ben -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
