"
Currently the ABI changes depending on compile time options.
New functionally ussually means that some struct needs to get
new members, and all those structs are public, and applications
make direct use of them. And compile time options will
add those members.
The API for those functions on the other hand might be more
stable, but I'm afraid you won't be able to use them
without knowing the members of the structs.
"
Which is pretty easy to fix in most cases. Just make sure you have
allocators/deallocators for all internal objects, add functions to access
any internal object members that really need direct access (there are very
few cases where this is needed) and treat the internal objects as "blobs"
I did this for the bastard son of OpenSSL IBM uses.
About the only thing that gives us some grief is access to some object
members to hanlde the data conversions needed for the formal NIST
compliance tests - which is "internal" functional testing anyway, it's not
something end users of the API would normally need to do
Peter
From: Kurt Roeckx <k...@roeckx.be>
To: openssl-dev@openssl.org
Date: 09/11/2009 08:07 AM
Subject: Re: interface stability
Sent by: owner-openssl-...@openssl.org
On Tue, Sep 01, 2009 at 02:23:38PM +0200, Mark Phalan wrote:
>
> In OpenSolaris we follow an interface stability classification system
> which marks interfaces according to how stable they are believed to be.
> You can see more information here if interested:
> http://opensolaris.org/os/community/arc/policies/interface-taxonomy/
>
> Currently OpenSSL APIs are classified as "External" which basically
> means that no stability guarantees are made and ABI and API
> compatibility may break at any time. In order to use these interfaces
> within OpenSolaris a contract is required. The interfaces covered by the
> contract believed to be fairly stable are:
>
> Interface
> ---------
> ASN1_
> BN_
> BIO_
> CRYPTO_
> EVP_
> HMAC
> OpenSSL_
> OBJ_
> PEM_
> PKCS7
> PKCS12_
> RAND_
> SMIME_
> SSL_
> X509_
>
> We'd like to "promote" the above interfaces to a slightly higher level
> of stability so that contracts for use are no longer required in
> OpenSolaris. Is the above list of APIs fairly stable? within lettered
> releases only? any missing APIs or APIs which probably shouldn't be
> there? will 1.0 change things a lot?
Going from 0.9.8 to 1.0.0 they change the soname, so they clearly
want to indicate that it's not binary compatible. If it was compatible
there would be no need to change the soname.
This issue has been brought up a few times already, and it seems
to me that they want to go to a stable API/ABI but on the other
hand don't want to make any changes to get there.
Currently the ABI changes depending on compile time options.
New functionally ussually means that some struct needs to get
new members, and all those structs are public, and applications
make direct use of them. And compile time options will
add those members.
The API for those functions on the other hand might be more
stable, but I'm afraid you won't be able to use them
without knowing the members of the structs.
Kurt
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
