As part of LSB standardization process, we look at the interfaces and corresponding data types and make it part of the specification. If the data types are expected to change and the interfaces do not hide them, then that part of the library may not be a candidate for LSB.
Given this, I am just wondering (as I do not know enough details yet) if it makes sense to partially include the crypto library in LSB. I assume at least parts of this library may be stable and not expected to change much. E.g. some of the crypto algorithms. Is that a possibility? From our current analysis of some of the existing OSS applications, function sets like EVP*, RSA*, DSA* etc are quite commonly used. It may be a good idea to identfy some of the "stable" interfaces from crypto library for inclusion in LSB. Any thoughts/comments? Thanks, -Rajesh -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dr. Stephen Henson Sent: Wednesday, June 29, 2005 1:01 PM To: openssl-dev@openssl.org Subject: Re: Considering SSL and Cryto libraries for LSB On Wed, Jun 29, 2005, Banginwar, Rajesh wrote: > We recently started looking at some of Desktop specific libraries for > including them as part of next LSB (Linux Standard Base > www.linuxbase.org) release. This is part of the effort in the newly > formed Desktop working group in LSB to focus on the Desktop Linux > applications. > > As a part of this effort we have started looking at the OpenSSL > libraries and found the thread > http://www.mail-archive.com/openssl-dev@openssl.org/msg19158.html > discussing ABI compatibility across different releases. I am > specifically referring to comments from Richard below. > > I will like to find out what the Openssl community think about making > the libraries part of next LSB release. Of course, the ABIs will need to > become stable before that. What are the plans to achieve this ABI > stability (including releasing 1.0 version of the package)? > This "ABI stability" is not something which can be done quickly and not without some rather large levels of incompatibility with existing applications itself. One of many reason for this is that some APIs, which have been around since the SSLeay days, make use of structures like this: FOO_CTX foo; FOO_CTX_something(&foo); Examples of this are the EVP digest and cipher APIs. This is a problem if the size of the structure FOO_CTX increases. There are several reasons why the size of FOO_CTX might change including additional features being added. There are several features which are needed in the digest and cipher APIs which would have this effect. There is a solution which already exists which is instead to do this: FOO_CTX *foo; foo = FOO_CTX_new(); FOO_CTX_something(foo); However, very few applications (at present) use this technique. This means that changing this in the short term is likely to cause widespread application breakage which wouldn't be too popular :-( Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
