[openssl.org #1106]
Reply test __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1106]
Just a test request __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: 0.9.8 API/ABI compatibility with 0.9.7 ?
On Thursday 09 June 2005 12:37 pm, Eduardo Pérez wrote: > > see the fun people had in upgrading from 0.9.7e to 0.9.7[fg] on x86_64 > > linux > > Wow!!! I didn't know there were breakage even there. > But, that wasn't made on purpose, was it? no, i'm pretty sure it was just a simple mistake that is fixed in the current 0.9.7 branch ... then again i really havent researched beyond fixing it in Gentoo ... > Do you know if there are more people interested in keeping API/ABI > compatible? you're overlooking the fact that the soname is set to the full version of the library ... when you go to link with -lcrypto, the libname 'libcrypto.so.0.9.7' is recorded in the NEEDED section of the elf instead of 'libcrypto.so.0' ... so unless you have 0.9.8 install its library as 'libcrypto.so.0.9.8' (which it wont), applications are going to break -mike __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: 0.9.8 API/ABI compatibility with 0.9.7 ?
In message <[EMAIL PROTECTED]> on Thu, 9 Jun 2005 14:28:27 +, Eduardo Pérez <[EMAIL PROTECTED]> said: eperez> On 2005-05-14 15:27:26 +, Eduardo Pérez wrote: eperez> > I was wondering if openssl-0.9.8 is going to be API/ABI eperez> > compatible with the current stable branch of openssl-0.9.7 eperez> > I think keeping API/ABI compatible is a good idea and makes eperez> > programmer and users life easier. eperez> > Anyway, if you are not going to keep API/ABI compatibility eperez> > in openssl-0.9.8 with 0.9.7 I'd like to hear the reasoning eperez> > behind that. 0.9.8 and 0.9.7 aren't compatible in certain areas. The biggest changes have nothing to do with function and variable symbols. If you want to look at the real incompatibilities, you need to compare the different structures. I'll get into that below. eperez> In libcrypto I saw that in the newer version there are missing eperez> symbols so it may not be API/ABI compatible if that symbols eperez> were supposed to be public and used by applications. Those I saw in your diff were ECC symbols. ECC is still quite experimental in 0.9.7 and has evolved quite a lot in 0.9.8. eperez> It seems that openssl doesn't want to keep API/ABI eperez> compatibility between minor versions, ignoring the tremendous eperez> help that it brings to end users and distributions packagers, eperez> even knowing that compatibility could be achieved at no cost. I think you're making quite a harsch conclusion. One of the bigger problems with the foundation of OpenSSL is the open nature of almost all structures. To keep API/ABI compatibility, those would have to be frozen, but that would effectively stop all development that includes new methods with extended data, or certain security fixes, or... unless you want *really ugly* and *really insecure* hacks in OpenSSL. Trust me. For a comparison, I suggest you compare the RSA structures in crypto/rsa/rsa.h between 0.9.7 and 0.9.8. I suggest you compare simple little constants like EVP_MAX_KEY_LENGTH and EVP_MAX_BLOCK_LENGTH between 0.9.6 and 0.9.7. The biggest change that's needed in OpenSSL is to hide all the structures and all constants and have them available through functions (creator, destructors and information functions). So speaking of incompatibilites, we've really kept it low compared to what needs to be done and what could be done. Our version numbering is admitedly weird. Basically, we've treated '0.9.' as a prefix to signal that "this isn't a 1.0 yet, and drastic changes can be expected", and effectively trated the next digit as a classic major version. This is reflected in the soname we give the shared libraries. We probably should do some drastic changes in our version numbering (which is quite a lesson to me personally. I've been reluctant to make a move to 1.0 because OpenSSL hasn't felt ready for that). Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ "When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up." -- C.S. Lewis __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: 0.9.8 API/ABI compatibility with 0.9.7 ?
On 2005-06-09 11:24:22 -0400, Mike Frysinger wrote: > On Thursday 09 June 2005 10:28 am, Eduardo Pérez wrote: > > On 2005-05-14 15:27:26 +, Eduardo Pérez wrote: > > > I was wondering if openssl-0.9.8 is going to be API/ABI compatible > > > with the current stable branch of openssl-0.9.7 > > > I think keeping API/ABI compatible is a good idea and makes programmer > > > and users life easier. > > > Anyway, if you are not going to keep API/ABI compatibility in > > > openssl-0.9.8 with 0.9.7 I'd like to hear the reasoning behind that. > > > > I made a diff of the symbols in libssl and libcrypto in openssl 0.9.7 > > and 0.9.8 and found that libssl didn't remove any symbols from the > > previous version and therefore may be backwards compatible if none of > > the older symbols changed ABI/API > > symbol name means nothing if it expects the arguments passed to it are of > different sizes I know. > see the fun people had in upgrading from 0.9.7e to 0.9.7[fg] on x86_64 linux Wow!!! I didn't know there were breakage even there. But, that wasn't made on purpose, was it? Could you show me any reference to that? Why did that happen? Isn't there any testing made prior to release? Do you know if there are more people interested in keeping API/ABI compatible? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: 0.9.8 API/ABI compatibility with 0.9.7 ?
On Thursday 09 June 2005 10:28 am, Eduardo Pérez wrote: > On 2005-05-14 15:27:26 +, Eduardo Pérez wrote: > > I was wondering if openssl-0.9.8 is going to be API/ABI compatible > > with the current stable branch of openssl-0.9.7 > > I think keeping API/ABI compatible is a good idea and makes programmer > > and users life easier. > > Anyway, if you are not going to keep API/ABI compatibility in > > openssl-0.9.8 with 0.9.7 I'd like to hear the reasoning behind that. > > I made a diff of the symbols in libssl and libcrypto in openssl 0.9.7 > and 0.9.8 and found that libssl didn't remove any symbols from the > previous version and therefore may be backwards compatible if none of > the older symbols changed ABI/API symbol name means nothing if it expects the arguments passed to it are of different sizes see the fun people had in upgrading from 0.9.7e to 0.9.7[fg] on x86_64 linux -mike __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: 0.9.8 API/ABI compatibility with 0.9.7 ?
On 2005-05-14 15:27:26 +, Eduardo Pérez wrote: > I was wondering if openssl-0.9.8 is going to be API/ABI compatible > with the current stable branch of openssl-0.9.7 > I think keeping API/ABI compatible is a good idea and makes programmer > and users life easier. > Anyway, if you are not going to keep API/ABI compatibility in > openssl-0.9.8 with 0.9.7 I'd like to hear the reasoning behind that. I made a diff of the symbols in libssl and libcrypto in openssl 0.9.7 and 0.9.8 and found that libssl didn't remove any symbols from the previous version and therefore may be backwards compatible if none of the older symbols changed ABI/API In libcrypto I saw that in the newer version there are missing symbols so it may not be API/ABI compatible if that symbols were supposed to be public and used by applications. It seems that openssl doesn't want to keep API/ABI compatibility between minor versions, ignoring the tremendous help that it brings to end users and distributions packagers, even knowing that compatibility could be achieved at no cost. Is this true? --- libssl.so.0.9.7.symbols +++ libssl.so.0.9.8.symbols @@ -4,7 +4,47 @@ BIO_new_ssl_connect BIO_ssl_copy_session_id BIO_ssl_shutdown +check_srvr_ecc_cert_and_alg d2i_SSL_SESSION +do_dtls1_write +dtls1_accept +dtls1_buffer_message +dtls1_clear +dtls1_clear_record_buffer +dtls1_client_hello +dtls1_connect +dtls1_dispatch_alert +dtls1_do_write +dtls1_enc +dtls1_free +dtls1_get_ccs_header +dtls1_get_message +dtls1_get_message_header +dtls1_get_record +dtls1_new +dtls1_output_cert_chain +dtls1_read_bytes +dtls1_read_failed +dtls1_reset_seq_numbers +dtls1_retransmit_message +dtls1_send_certificate_request +dtls1_send_change_cipher_spec +dtls1_send_client_certificate +dtls1_send_client_key_exchange +dtls1_send_client_verify +dtls1_send_finished +dtls1_send_hello_request +dtls1_send_server_certificate +dtls1_send_server_done +dtls1_send_server_hello +dtls1_send_server_key_exchange +dtls1_set_message_header +dtls1_write_app_data_bytes +dtls1_write_bytes +dtlsv1_base_method +DTLSv1_client_method +DTLSv1_method +DTLSv1_server_method ERR_load_SSL_strings _fini i2d_SSL_SESSION @@ -46,26 +86,41 @@ ssl3_callback_ctrl ssl3_cert_verify_mac ssl3_change_cipher_state +ssl3_check_cert_and_algorithm +ssl3_check_client_hello ssl3_choose_cipher ssl3_cleanup_key_block ssl3_clear +ssl3_client_hello ssl3_comp_find ssl3_connect ssl3_ctrl ssl3_ctx_callback_ctrl ssl3_ctx_ctrl ssl3_dispatch_alert +ssl3_do_change_cipher_spec +ssl3_do_compress +ssl3_do_uncompress ssl3_do_write ssl3_enc ssl3_final_finish_mac ssl3_finish_mac ssl3_free ssl3_generate_master_secret +ssl3_get_certificate_request +ssl3_get_cert_verify ssl3_get_cipher ssl3_get_cipher_by_char +ssl3_get_client_certificate +ssl3_get_client_hello +ssl3_get_client_key_exchange ssl3_get_finished +ssl3_get_key_exchange ssl3_get_message ssl3_get_req_cert_type +ssl3_get_server_certificate +ssl3_get_server_done +ssl3_get_server_hello ssl3_init_finished_mac ssl3_mac ssl3_new @@ -76,17 +131,28 @@ ssl3_put_cipher_by_char ssl3_read ssl3_read_bytes +ssl3_read_n +ssl3_record_sequence_update ssl3_renegotiate ssl3_renegotiate_check ssl3_send_alert +ssl3_send_certificate_request ssl3_send_change_cipher_spec +ssl3_send_client_certificate +ssl3_send_client_key_exchange +ssl3_send_client_verify ssl3_send_finished +ssl3_send_hello_request ssl3_send_server_certificate +ssl3_send_server_done +ssl3_send_server_hello +ssl3_send_server_key_exchange ssl3_setup_buffers ssl3_setup_key_block ssl3_shutdown ssl3_write ssl3_write_bytes +ssl3_write_pending SSL_accept SSL_add_client_CA SSL_add_dir_cert_subjects_to_stack @@ -117,6 +183,7 @@ ssl_clear_cipher_ctx SSL_COMP_add_compression_method SSL_COMP_get_compression_methods +SSL_COMP_get_name SSL_connect SSL_copy_session_id ssl_create_cipher_list @@ -157,6 +224,7 @@ SSL_CTX_set_ssl_version SSL_CTX_set_timeout SSL_CTX_set_tmp_dh_callback +SSL_CTX_set_tmp_ecdh_callback SSL_CTX_set_tmp_rsa_callback SSL_CTX_set_trust SSL_CTX_set_verify @@ -184,6 +252,8 @@ ssl_get_ciphers_by_id SSL_get_client_CA_list SSL_get_current_cipher +SSL_get_current_compression +SSL_get_current_expansion SSL_get_default_timeout SSL_get_error SSL_get_ex_data @@ -236,6 +306,7 @@ SSL_SESSION_free SSL_SESSION_get_ex_data SSL_SESSION_get_ex_new_index +SSL_SESSION_get_id SSL_SESSION_get_time SSL_SESSION_get_timeout SSL_SESSION_hash @@ -266,6 +337,7 @@ SSL_set_shutdown SSL_set_ssl_method SSL_set_tmp_dh_callback +SSL_set_tmp_ecdh_callback SSL_set_tmp_rsa_callback SSL_set_trust SSL_set_verify @@ -278,6 +350,7 @@ SSL_state_string_long ssl_undefined_const_function ssl_undefined_function +ssl_undefined_void_function ssl_update_cache SSL_use_certificate SSL_use_certificate_ASN1 --- libcrypto.so.0.9.7.symbols +++ libcrypto.so.0.9.8.symbols @@ -2,6 +2,8 @@ a2i_ASN1_ENUMERATED a2i_ASN1_INTEGER a2i_ASN1_STRING +a2i_IPADDRESS +a2i_IPADDRESS_NC ACCESS_DESCRIPTION_free ACC
