|
»
interface stability
|
View:
New views
8 Messages
—
Rating Filter:
Alert me
|
 |
interface stability
by Mark Phalan-2
::
Rate this Message:
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? Thanks, -Mark ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@... Automated List Manager majordomo@... |
|
|
Re: interface stability
by Kurt Roeckx
::
Rate this Message:
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@... Automated List Manager majordomo@... |
|
|
Re: interface stability
by Peter Waltenberg
::
Rate this Message:
"
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 <kurt@...> To: openssl-dev@... Date: 09/11/2009 08:07 AM Subject: Re: interface stability Sent by: owner-openssl-dev@... 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@... Automated List Manager majordomo@... ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@... Automated List Manager majordomo@... |
|
|
Re: interface stability
by Mark Phalan-2
::
Rate this Message:
On 09/10/09 11:56 PM, Kurt Roeckx wrote:
> 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. Right. I understand that major version change implies ABI incompatibility. > > 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. This is something I can mostly control and maintain (thankfully). > 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. > I understand this. I'd like to know if 0.9.8l will be ABI/API compat with 0.9.8k - or at least that it is considered a bug if they are not ABI/API compat. I'm unclear as to what restrictions a 0.9.9x release would have regarding compatibility with the 0.9.8 series. I fully understand that 1.0 will not be compatible with 0.9.x. Thanks, -M ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@... Automated List Manager majordomo@... |
|
|
Re: interface stability
by Dr. Stephen Henson
::
Rate this Message:
On Fri, Sep 11, 2009, Mark Phalan wrote:
> On 09/10/09 11:56 PM, Kurt Roeckx wrote: > > I understand this. I'd like to know if 0.9.8l will be ABI/API compat with > 0.9.8k - or at least that it is considered a bug if they are not ABI/API > compat. I'm unclear as to what restrictions a 0.9.9x release would have > regarding compatibility with the 0.9.8 series. I fully understand that 1.0 > will not be compatible with 0.9.x. > Under the new versioning scheme letter changes will retain binary compatibility. They will be bugfix only and no new features will be added. There wont be a 0.9.9 to avoid confusion with what we used to call "0.9.9" which is now 1.0.0. So after 0.9.8 there may be a 0.9.10. Changes to the last number i.e. 1.0.1 or 0.9.10 will retain backwards compatibiity but new features can be added. The middle number as has been noted wont guarantee binary compatibility, however source compatibility will be largely maintained though use of some deprecated features may be phased out long term. We only make such releases every few years. The old versioning scheme changed the final number for major releases as the 0.9 bit was set by its SSLeay predecessor. So the last major release before 0.9.8 was 0.9.7. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@... Automated List Manager majordomo@... |
|
|
Re: interface stability
by Mark Phalan-2
::
Rate this Message:
On 09/11/09 05:59 PM, Dr. Stephen Henson wrote:
> On Fri, Sep 11, 2009, Mark Phalan wrote: > >> On 09/10/09 11:56 PM, Kurt Roeckx wrote: >> >> I understand this. I'd like to know if 0.9.8l will be ABI/API compat with >> 0.9.8k - or at least that it is considered a bug if they are not ABI/API >> compat. I'm unclear as to what restrictions a 0.9.9x release would have >> regarding compatibility with the 0.9.8 series. I fully understand that 1.0 >> will not be compatible with 0.9.x. >> > > Under the new versioning scheme letter changes will retain binary > compatibility. They will be bugfix only and no new features will be added. > > There wont be a 0.9.9 to avoid confusion with what we used to call "0.9.9" > which is now 1.0.0. So after 0.9.8 there may be a 0.9.10. > > Changes to the last number i.e. 1.0.1 or 0.9.10 will retain backwards > compatibiity but new features can be added. > > The middle number as has been noted wont guarantee binary compatibility, > however source compatibility will be largely maintained though use of some > deprecated features may be phased out long term. We only make such releases > every few years. > > The old versioning scheme changed the final number for major releases as the > 0.9 bit was set by its SSLeay predecessor. So the last major release before > 0.9.8 was 0.9.7. Thanks for the compat info. Are the listed APIs I mentioned earlier in the thread less likely to break accross upgrades or is everything basically in the same boat? -M ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@... Automated List Manager majordomo@... |
|
|
Re: interface stability
by David Woodhouse
::
Rate this Message:
On Fri, 2009-09-11 at 17:59 +0200, Dr. Stephen Henson wrote:
> Under the new versioning scheme letter changes will retain binary > compatibility. They will be bugfix only and no new features will be added. > > There wont be a 0.9.9 to avoid confusion with what we used to call "0.9.9" > which is now 1.0.0. So after 0.9.8 there may be a 0.9.10. > > Changes to the last number i.e. 1.0.1 or 0.9.10 will retain backwards > compatibiity but new features can be added. > > The middle number as has been noted wont guarantee binary compatibility, > however source compatibility will be largely maintained though use of some > deprecated features may be phased out long term. We only make such releases > every few years. I'm still trying to understand what this actually means in practice, and who the target audience is for the various branches. Presumably, most of the conservative OS distributions (Solaris, "Enterprise" Linux distros, various BSDs) will stick with 0.9.8 for the time being. Those who are more versatile will be updating to 1.0.x -- some of them like Fedora are there already, in fact. So is there really any point in a 0.9.10 release? Who would actually want to use that, and what would be in it? In the meantime, there are people who are trying to get features into the codebase that people actually use -- Intel's AES-NI support, IBM's AES-GCM/AES-CCM/CMAC, etc. The normal response from distributions is, quite reasonably, "get it into 0.9.8 upstream and then we'll talk". Which is obviously not such a realistic proposition any more -- so what happens next? -- dwmw2 ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@... Automated List Manager majordomo@... |
|
|
Re: interface stability
by Dr. Stephen Henson
::
Rate this Message:
On Sun, Nov 08, 2009, David Woodhouse wrote:
> I'm still trying to understand what this actually means in practice, and > who the target audience is for the various branches. > > Presumably, most of the conservative OS distributions (Solaris, > "Enterprise" Linux distros, various BSDs) will stick with 0.9.8 for the > time being. > > Those who are more versatile will be updating to 1.0.x -- some of them > like Fedora are there already, in fact. > > So is there really any point in a 0.9.10 release? Who would actually > want to use that, and what would be in it? > > In the meantime, there are people who are trying to get features into > the codebase that people actually use -- Intel's AES-NI support, IBM's > AES-GCM/AES-CCM/CMAC, etc. > > The normal response from distributions is, quite reasonably, "get it > into 0.9.8 upstream and then we'll talk". Which is obviously not such a > realistic proposition any more -- so what happens next? > The aim of the 0.9.10 release (and the 1.0.1 release) is to allow new features to be added more quickly than a major release and to reduce the possibility of introducing problems in a stable release. When we want to add a new feature to OpenSSL in the old scheme it could go into HEAD and it would become part of the next major release. However major releases only occur every few years and there was a need to be able to add features more quickly which didn't break binary compatibility. So the idea was to separate the bugfix and "timely new feature" versions. So someone who wishes maximum compatibility and least risk of any problems would stick with the letter changes. Those who want newer features with small risk issues would go with final number changes that is 1.0.1, 1.0.2. If there was a need to add such features to the 0.9.8-stable branch (for example that's the only version which can be currently used with the FIPS140-2 validated module) it would go into 0.9.10 that may not happen and there may not be a 0.9.10 at all. Finally bleeding edge major changes for developers or users who can live with possibly unstable and occasionally uncompilable code can stick with the unstable branch which will be 1.1.0 and later. The various AES features you mentioned would be candidates for 1.0.1. It was hoped that the final or penultimate beta of 1.0.0 would be out by now but the renegotiation issues have thrown everyones schedules off. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@... Automated List Manager majordomo@... |
| Free embeddable forum powered by Nabble | Forum Help |
