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 +0000, Eduardo > Pérez <[EMAIL PROTECTED]> said: > eperez> On 2005-05-14 15:27:26 +0000, 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]
