Re: [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2

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

Re: [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2

OpenSSL - Dev mailing list
[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
Reply | Threaded
Open this post in threaded view
|

Re: [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2

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

Re: [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2

OpenSSL - Dev mailing list
In reply to this post by OpenSSL - Dev mailing list
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: [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/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2

Michel
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:[hidden email]] De la part de
Salz, Rich via openssl-dev
Envoyé : vendredi 27 janvier 2017 19:49
À : Kaduk, Ben; [hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2

OpenSSL - Dev mailing list
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 [[hidden email]] De la part de
Salz, Rich via openssl-dev
Envoyé : vendredi 27 janvier 2017 19:49
À : Kaduk, Ben; [hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2

Nikos Mavrogiannopoulos-2
In reply to this post by OpenSSL - Dev mailing list
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
Reply | Threaded
Open this post in threaded view
|

Re: [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2

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

Re: [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2

Richard Levitte - VMS Whacker-2
In reply to this post by OpenSSL - Dev mailing list
In message <[hidden email]> on Fri, 27 Jan 2017 10:54:35 -0600, Benjamin Kaduk via openssl-dev <[hidden email]> 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 <[hidden email]>
    Date:   Sun Dec 1 23:06:33 2013 +0000
   
        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         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/

--- ../1.0.1/util/libeay.num 2016-06-30 01:06:40.000000000 +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_rsax                        4652 EXIST::FUNCTION:ENGINE
+ENGINE_load_rsax                        4652 NOEXIST::FUNCTION:
 CRYPTO_gcm128_decrypt_ctr32             4653 EXIST::FUNCTION:
 CRYPTO_gcm128_encrypt_ctr32             4654 EXIST::FUNCTION:
 CRYPTO_gcm128_finish                    4655 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_email            4696 EXIST::FUNCTION:
+X509_check_email                        4697 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           4705 EXIST::FUNCTION:
+X509_CRL_diff                           4706 EXIST::FUNCTION:
+X509_CRL_http_nbio                      4707 EXIST::FUNCTION:EVP
+OCSP_REQ_CTX_i2d                        4708 EXIST::FUNCTION:
+OCSP_REQ_CTX_get0_mem_bio               4709 EXIST::FUNCTION:
+X509_STORE_CTX_get0_store               4710 EXIST::FUNCTION:
+X509_REVOKED_dup                        4711 EXIST::FUNCTION:
+CMS_RecipientInfo_encrypt               4712 EXIST::FUNCTION:CMS
+OCSP_REQ_CTX_http                       4713 EXIST::FUNCTION:
+OCSP_REQ_CTX_nbio                       4714 EXIST::FUNCTION:
+X509_http_nbio                          4715 EXIST::FUNCTION:EVP
+OCSP_set_max_response_length            4716 EXIST::FUNCTION:
+OCSP_REQ_CTX_new                        4717 EXIST::FUNCTION:
+OCSP_REQ_CTX_nbio_d2i                   4718 EXIST::FUNCTION:
+EVP_aes_256_wrap                        4719 EXIST::FUNCTION:AES
+CRYPTO_128_wrap                         4720 EXIST::FUNCTION:
+RSA_OAEP_PARAMS_new                     4721 EXIST::FUNCTION:RSA
+CRYPTO_128_unwrap                       4722 EXIST::FUNCTION:
+ECDSA_METHOD_set_name                   4723 EXIST::FUNCTION:ECDSA
+CMS_RecipientInfo_kari_decrypt          4724 EXIST::FUNCTION:CMS
+CMS_SignerInfo_get0_pkey_ctx            4725 EXIST::FUNCTION:CMS
+ECDSA_METHOD_set_flags                  4726 EXIST::FUNCTION:ECDSA
+ECDSA_METHOD_set_sign_setup             4727 EXIST::FUNCTION:ECDSA
+CMS_RecipientInfo_kari_orig_id_cmp      4728 EXIST:!VMS:FUNCTION:CMS
+CMS_RecipInfo_kari_orig_id_cmp          4728 EXIST:VMS:FUNCTION:CMS
+CMS_RecipientInfo_kari_get0_alg         4729 EXIST::FUNCTION:CMS
+EVP_aes_192_wrap                        4730 EXIST::FUNCTION:AES
+EVP_aes_128_cbc_hmac_sha256             4731 EXIST::FUNCTION:AES,SHA256
+DH_compute_key_padded                   4732 EXIST::FUNCTION:DH
+ECDSA_METHOD_set_sign                   4733 EXIST::FUNCTION:ECDSA
+CMS_RecipientEncryptedKey_cert_cmp      4734 EXIST:!VMS:FUNCTION:CMS
+CMS_RecipEncryptedKey_cert_cmp          4734 EXIST:VMS:FUNCTION:CMS
+DH_KDF_X9_42                            4735 EXIST::FUNCTION:DH
+RSA_OAEP_PARAMS_free                    4736 EXIST::FUNCTION:RSA
+EVP_des_ede3_wrap                       4737 EXIST::FUNCTION:DES
+RSA_OAEP_PARAMS_it                      4738 EXIST:!EXPORT_VAR_AS_FUNCTION:VARIABLE:RSA
+RSA_OAEP_PARAMS_it                      4738 EXIST:EXPORT_VAR_AS_FUNCTION:FUNCTION:RSA
+ASN1_TIME_diff                          4739 EXIST::FUNCTION:
+EVP_aes_256_cbc_hmac_sha256             4740 EXIST::FUNCTION:AES,SHA256
+CMS_SignerInfo_get0_signature           4741 EXIST::FUNCTION:CMS
+CMS_RecipientInfo_kari_get0_reks        4742 EXIST:!VMS:FUNCTION:CMS
+CMS_RecipInfo_kari_get0_reks            4742 EXIST:VMS:FUNCTION:CMS
+EVP_aes_128_wrap                        4743 EXIST::FUNCTION:AES
+CMS_SignerInfo_get0_md_ctx              4744 EXIST::FUNCTION:CMS
+OPENSSL_gmtime_diff                     4745 EXIST::FUNCTION:
+CMS_RecipientInfo_kari_set0_pkey        4746 EXIST:!VMS:FUNCTION:CMS
+CMS_RecipInfo_kari_set0_pkey            4746 EXIST:VMS:FUNCTION:CMS
+i2d_RSA_OAEP_PARAMS                     4747 EXIST::FUNCTION:RSA
+d2i_RSA_OAEP_PARAMS                     4748 EXIST::FUNCTION:RSA
+ECDH_KDF_X9_62                          4749 EXIST::FUNCTION:ECDH
+CMS_RecipientInfo_kari_get0_ctx         4750 EXIST::FUNCTION:CMS
+ECDSA_METHOD_new                        4751 EXIST::FUNCTION:ECDSA
+CMS_RecipientInfo_get0_pkey_ctx         4752 EXIST::FUNCTION:CMS
+CMS_RecipientEncryptedKey_get0_id       4753 EXIST:!VMS:FUNCTION:CMS
+CMS_RecipEncryptedKey_get0_id           4753 EXIST:VMS:FUNCTION:CMS
+RSA_padding_check_PKCS1_OAEP_mgf1       4754 EXIST:!VMS:FUNCTION:RSA
+RSA_pad_check_PKCS1_OAEP_mgf1           4754 EXIST:VMS:FUNCTION:RSA
+ECDSA_METHOD_set_verify                 4755 EXIST::FUNCTION:ECDSA
+CMS_SharedInfo_encode                   4756 EXIST::FUNCTION:CMS
+RSA_padding_add_PKCS1_OAEP_mgf1         4757 EXIST::FUNCTION:RSA
+CMS_RecipientInfo_kari_get0_orig_id     4758 EXIST:!VMS:FUNCTION:CMS
+CMS_RecipInfo_kari_get0_orig_id         4758 EXIST:VMS:FUNCTION:CMS
+ECDSA_METHOD_free                       4759 EXIST::FUNCTION:ECDSA
+X509_VERIFY_PARAM_get_count             4760 EXIST::FUNCTION:
+X509_VERIFY_PARAM_get0_name             4761 EXIST::FUNCTION:
+X509_VERIFY_PARAM_get0                  4762 EXIST::FUNCTION:
+X509V3_EXT_free                         4763 EXIST::FUNCTION:
+BIO_hex_string                          4764 EXIST::FUNCTION:
+X509_VERIFY_PARAM_set_hostflags         4765 EXIST::FUNCTION:
+BUF_strnlen                             4766 EXIST::FUNCTION:
+X509_VERIFY_PARAM_get0_peername         4767 EXIST::FUNCTION:
+ECDSA_METHOD_set_app_data               4768 EXIST::FUNCTION:ECDSA
+sk_deep_copy                            4769 EXIST::FUNCTION:
+ECDSA_METHOD_get_app_data               4770 EXIST::FUNCTION:ECDSA
+X509_VERIFY_PARAM_add1_host             4771 EXIST::FUNCTION:
+EC_GROUP_get_mont_data                  4772 EXIST::FUNCTION:EC
+i2d_re_X509_tbs                         4773 EXIST::FUNCTION:
+EVP_PKEY_asn1_set_item                  4774 EXIST::FUNCTION:

--- ../1.0.1/util/ssleay.num 2016-06-30 01:06:40.000000000 +0200
+++ util/ssleay.num 2017-01-24 17:36:15.502447544 +0100
@@ -164,7 +164,7 @@
 SSL_CTX_set_cert_store                  181 EXIST::FUNCTION:
 SSL_want                                182 EXIST::FUNCTION:
 SSL_library_init                        183 EXIST::FUNCTION:
-SSL_COMP_add_compression_method         184 EXIST::FUNCTION:COMP
+SSL_COMP_add_compression_method         184 EXIST::FUNCTION:
 SSL_add_file_cert_subjects_to_stack     185 EXIST:!VMS:FUNCTION:STDIO
 SSL_add_file_cert_subjs_to_stk          185 EXIST:VMS:FUNCTION:STDIO
 SSL_set_tmp_rsa_callback                186 EXIST::FUNCTION:RSA
@@ -219,13 +219,13 @@
 DTLSv1_client_method                    268 EXIST::FUNCTION:
 SSL_CTX_set_tmp_ecdh_callback           269 EXIST::FUNCTION:ECDH
 SSL_set_tmp_ecdh_callback               270 EXIST::FUNCTION:ECDH
-SSL_COMP_get_name                       271 EXIST::FUNCTION:COMP
-SSL_get_current_compression             272 EXIST::FUNCTION:COMP
+SSL_COMP_get_name                       271 EXIST::FUNCTION:
+SSL_get_current_compression             272 EXIST::FUNCTION:
 DTLSv1_method                           273 EXIST::FUNCTION:
-SSL_get_current_expansion               274 EXIST::FUNCTION:COMP
+SSL_get_current_expansion               274 EXIST::FUNCTION:
 DTLSv1_server_method                    275 EXIST::FUNCTION:
-SSL_COMP_get_compression_methods        276 EXIST:!VMS:FUNCTION:COMP
-SSL_COMP_get_compress_methods           276 EXIST:VMS:FUNCTION:COMP
+SSL_COMP_get_compression_methods        276 EXIST:!VMS:FUNCTION:
+SSL_COMP_get_compress_methods           276 EXIST:VMS:FUNCTION:
 SSL_SESSION_get_id                      277 EXIST::FUNCTION:
 SSL_CTX_sess_set_new_cb                 278 EXIST::FUNCTION:
 SSL_CTX_sess_get_get_cb                 279 EXIST::FUNCTION:
@@ -316,8 +316,55 @@
 SSL_get0_next_proto_negotiated          356 EXIST::FUNCTION:NEXTPROTONEG
 SSL_get_selected_srtp_profile           357 EXIST::FUNCTION:SRTP
 SSL_CTX_set_tlsext_use_srtp             358 EXIST::FUNCTION:SRTP
-SSL_select_next_proto                   359 EXIST::FUNCTION:NEXTPROTONEG
+SSL_select_next_proto                   359 EXIST::FUNCTION:TLSEXT
 SSL_get_srtp_profiles                   360 EXIST::FUNCTION:SRTP
 SSL_CTX_set_next_proto_select_cb        361 EXIST:!VMS:FUNCTION:NEXTPROTONEG
 SSL_CTX_set_next_proto_sel_cb           361 EXIST:VMS:FUNCTION:NEXTPROTONEG
 SSL_SESSION_get_compress_id             362 EXIST::FUNCTION:
+SSL_get0_param                          363 EXIST::FUNCTION:
+SSL_CTX_get0_privatekey                 364 EXIST::FUNCTION:
+SSL_get_shared_sigalgs                  365 EXIST::FUNCTION:TLSEXT
+SSL_CONF_CTX_finish                     366 EXIST::FUNCTION:
+DTLS_method                             367 EXIST::FUNCTION:
+DTLS_client_method                      368 EXIST::FUNCTION:
+SSL_CIPHER_standard_name                369 EXIST::FUNCTION:SSL_TRACE
+SSL_set_alpn_protos                     370 EXIST::FUNCTION:
+SSL_CTX_set_srv_supp_data               371 NOEXIST::FUNCTION:
+SSL_CONF_cmd_argv                       372 EXIST::FUNCTION:
+DTLSv1_2_server_method                  373 EXIST::FUNCTION:
+SSL_COMP_set0_compression_methods       374 EXIST:!VMS:FUNCTION:
+SSL_COMP_set0_compress_methods          374 EXIST:VMS:FUNCTION:
+SSL_CTX_set_cert_cb                     375 EXIST::FUNCTION:
+SSL_CTX_add_client_custom_ext           376 EXIST::FUNCTION:TLSEXT
+SSL_is_server                           377 EXIST::FUNCTION:
+SSL_CTX_get0_param                      378 EXIST::FUNCTION:
+SSL_CONF_cmd                            379 EXIST::FUNCTION:
+SSL_CTX_get_ssl_method                  380 EXIST::FUNCTION:
+SSL_CONF_CTX_set_ssl_ctx                381 EXIST::FUNCTION:
+SSL_CIPHER_find                         382 EXIST::FUNCTION:
+SSL_CTX_use_serverinfo                  383 EXIST::FUNCTION:TLSEXT
+DTLSv1_2_client_method                  384 EXIST::FUNCTION:
+SSL_get0_alpn_selected                  385 EXIST::FUNCTION:
+SSL_CONF_CTX_clear_flags                386 EXIST::FUNCTION:
+SSL_CTX_set_alpn_protos                 387 EXIST::FUNCTION:
+SSL_CTX_add_server_custom_ext           389 EXIST::FUNCTION:TLSEXT
+SSL_CTX_get0_certificate                390 EXIST::FUNCTION:
+SSL_CTX_set_alpn_select_cb              391 EXIST::FUNCTION:
+SSL_CONF_cmd_value_type                 392 EXIST::FUNCTION:
+SSL_set_cert_cb                         393 EXIST::FUNCTION:
+SSL_get_sigalgs                         394 EXIST::FUNCTION:TLSEXT
+SSL_CONF_CTX_set1_prefix                395 EXIST::FUNCTION:
+SSL_CONF_CTX_new                        396 EXIST::FUNCTION:
+SSL_CONF_CTX_set_flags                  397 EXIST::FUNCTION:
+SSL_CONF_CTX_set_ssl                    398 EXIST::FUNCTION:
+SSL_check_chain                         399 EXIST::FUNCTION:TLSEXT
+SSL_certs_clear                         400 EXIST::FUNCTION:
+SSL_CONF_CTX_free                       401 EXIST::FUNCTION:
+SSL_trace                               402 EXIST::FUNCTION:SSL_TRACE
+SSL_CTX_set_cli_supp_data               403 NOEXIST::FUNCTION:
+DTLSv1_2_method                         404 EXIST::FUNCTION:
+DTLS_server_method                      405 EXIST::FUNCTION:
+SSL_CTX_use_serverinfo_file             406 EXIST::FUNCTION:STDIO,TLSEXT
+SSL_COMP_free_compression_methods       407 EXIST:!VMS:FUNCTION:
+SSL_COMP_free_compress_methods          407 EXIST:VMS:FUNCTION:
+SSL_extension_supported                 409 EXIST::FUNCTION:TLSEXT

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

Re: [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2

Kurt Roeckx
In reply to this post by Ponomarenko Andrey
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
Reply | Threaded
Open this post in threaded view
|

Re: [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2

Ponomarenko Andrey
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#result
https://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
Reply | Threaded
Open this post in threaded view
|

Re: [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2

Benjamin Kaduk
In reply to this post by Kurt Roeckx
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
Reply | Threaded
Open this post in threaded view
|

Re: [openssl/openssl] ABI compatibility 1.0.0-->1.0.1-->1.0.2

Benjamin Kaduk
In reply to this post by Richard Levitte - VMS Whacker-2
On 02/26/2017 02:10 AM, Richard Levitte wrote:
In message [hidden email] on Fri, 27 Jan 2017 10:54:35 -0600, Benjamin Kaduk via openssl-dev [hidden email] 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 [hidden email]
    Date:   Sun Dec 1 23:06:33 2013 +0000
    
        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