Re: 0.9.8 API/ABI compatibility with 0.9.7 ?
On 2005-06-09 19:54:13 +0200, Richard Levitte - VMS Whacker wrote: 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. That's other problem. Internal structures shouldn't be exposed through a stable API. 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. So, if there weren't any external application users, it may not cause problems to anyone, may it? 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. That doesn't need to be true. The http://www.gtk.org/ people keep API/ABI compatibility from 2.0 (they are now at 2.6) and they add new methods and extended data every release. For a comparison, I suggest you compare the RSA structures in crypto/rsa/rsa.h between 0.9.7 and 0.9.8. If those RSA structures where only accessible through public methods there wouldn't be any problem with any change on them. 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. Sure, to keep API/ABI compatibility those constants shouldn't change their value between compatible releases. 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 incompatibilities, we've really kept it low compared to what needs to be done and what could be done. So is there any plans to make internal structures only accessible from public methods? Our version numbering is admittedly 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). When do you feel OpenSSL will be ready for a 1.0 release and API/ABI stabilization? Is there any roadmap of the work that needs to be done? __ 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 13:59:22 -0400, Mike Frysinger wrote: On Thursday 09 June 2005 12:37 pm, Eduardo Pérez wrote: 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 The quick hack to get it working is just to keep libcrypto.so.0.9.7 for the new 0.9.8 code, as easy as that. It may create some confusion for programmers but users don't see that files. __ 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
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]
0.9.8 API/ABI compatibility with 0.9.7 ?
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. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL and DTLS
On 2005-03-04 07:05:01 -0800, Prashant Kumar wrote: Does OpenSSL has plans to support DTLS ? Is there any good open source prototype implementation? In: http://www.sipfoundry.org/reSIProcate/ there's the DTLS implementation: http://scm.sipfoundry.org/viewsvn/resiprocate/main/sip/contrib/dtls/ of the DTLS spec authors. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [CVS] OpenSSL: OpenSSL_0_9_7-stable: openssl/ CHANGES openssl/crypto/a...
This patch seems to have introduced some code duplication:
It seems harmless, but still.
I tried to look line by line of the patch but I may have left something.
On 2004-12-05 02:04:45 +0100, Dr. Stephen Henson wrote:
--- openssl/crypto/asn1/a_bitstr.c 12 Nov 2002 13:21:19 - 1.13.2.3
+++ openssl/crypto/asn1/a_bitstr.c 5 Dec 2004 01:04:33 - 1.13.2.4
@@ -194,7 +194,12 @@
c=(unsigned char *)OPENSSL_realloc_clean(a-data,
a-length,
w+1);
- if (c == NULL) return(0);
+ if (c == NULL)
+ {
+
ASN1err(ASN1_F_ASN1_BIT_STRING_SET_BIT,ERR_R_MALLOC_FAILURE);
+ return 0;
+ }
+ if (w+1-a-length 0) memset(c+a-length, 0, w+1-a-length);
Duplication
if (w+1-a-length 0) memset(c+a-length, 0, w+1-a-length);
a-data=c;
a-length=w+1;
--- openssl/crypto/asn1/a_utctm.c 27 Jan 2004 01:16:09 - 1.24.2.3
+++ openssl/crypto/asn1/a_utctm.c 5 Dec 2004 01:04:33 - 1.24.2.4
@@ -203,7 +204,12 @@
if ((p == NULL) || ((size_t)s-length len))
{
p=OPENSSL_malloc(len);
- if (p == NULL) return(NULL);
+ if (p == NULL)
+ {
+ ASN1err(ASN1_F_ASN1_UTCTIME_SET,ERR_R_MALLOC_FAILURE);
+ return(NULL);
+ }
+ if (s-data != NULL)
Duplication
if (s-data != NULL)
OPENSSL_free(s-data);
s-data=(unsigned char *)p;
--- openssl/crypto/asn1/x_pubkey.c 30 May 2002 16:50:36 - 1.21.2.2
+++ openssl/crypto/asn1/x_pubkey.c 5 Dec 2004 01:04:33 - 1.21.2.3
@@ -143,7 +166,12 @@
}
p=s;
i2d_PublicKey(pkey,p);
- if (!M_ASN1_BIT_STRING_set(pk-public_key,s,i)) goto err;
+ if (!M_ASN1_BIT_STRING_set(pk-public_key,s,i))
+ {
+ X509err(X509_F_X509_PUBKEY_SET,ERR_R_MALLOC_FAILURE);
+ goto err;
+ }
+ /* Set number of unused bits to zero */
Duplication
/* Set number of unused bits to zero */
pk-public_key-flags= ~(ASN1_STRING_FLAG_BITS_LEFT|0x07);
pk-public_key-flags|=ASN1_STRING_FLAG_BITS_LEFT;
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
