RE: OpenSSL and LSB (patch)
For 0.9.9-dev I would prefer making the parameter (and hence the return type) in the X509_foo_get() functions const but I'm not sure if we should change this behaviour in 0.9.8-stable. Comments are welcome. I think I had experimented with making things const at one point but had concluded that might break things in the manner you describe since macros are implicily always non-const. For the purposes of the LSB exersize, making the change in 0.9.9 with const declarations sounds like a reasonable thing to do, since the timing of LSB probably indicates a 0.9.9 release will be available (and hopefully in distros) before LSB 4.0. Thanks, Tracy Camp Cheers, Nils __ 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]
LSB patch status update?
Awhile back I posted a patch to de-macrotize a number of interfaces in OpenSSL to assist my efforts to get OpenSSL into the LSB. I saw a number of comments along the lines of 'this seems to be a good thing', but that was it Can anybody tell me where this stands? If the patch needs changes before it could be checked in let me know, I've got the time... Thanks, Tracy Camp __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: OpenSSL and LSB (patch)
I'm very much in favour of this. One comment, though - if you're going to make structure opaque, then why not make them truly opaque by removing their definitions from the public headers? In LSB they would be truly opaque. LSB works by producing a set of stub libraries and generated headers that contain the defined interfaces. In those generated headers, the types would be opaque. These stub libs and headers however are only used by applications attempting to build with the LSB environment, the real openssl remains unchanged and is utilized at runtime. I don't really see changing all of openssl directly as a reasonable solution however since a vast mountain of software is already written with those structures defined. Tracy Camp -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff __ 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]
RE: OpenSSL and LSB (patch)
How is that vast amount of software going to work under LSB, then? LSB does not support all applications anyways (for example, anything that has a direct kernel dependency is not a LSB application), and we are not trying to do so here either. Instead I'm attempting to be able to support something close to 70% of existing applications (i.e. they will 'just work' or only require minor tweaks to be LSB compliant), whereas it might be a bit rude to entirely break the last 30% in the more general openssl distribution case. In any case, ABI stability is not a problem unique to LSB, and I'm not sure why we'd want to solve it for only that project. I'm personally totally okay with that, but I'm also really motived from an LSB perspective and presume minimally invasive change would be the most acceptable in the upstread OpenSSL distributions. The difference really is that with this patch you are more able to create ABI stable applications by following good practice, but the choice is really yours, but when using LSB you have to because LSB would force that upon you. Tracy Camp Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff __ 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]
OpenSSL and LSB
Id like to re-start some discussion about including OpenSSL in LSB (acronym expansion: Linux Standards Base see: http://www.freestandards.org). There is apparently general interest in seeing OpenSSL in LSB both for its SSL functionality as well as its utility as a general cryptographic library. In particular applications that wish to be LSB compliant would benefit from security bug fixes. Currently applications that use OpenSSL and wish to be LSB compliant are forced to statically link OpenSSL and in theory at least, may need to re-release binaries for each OpenSSL release (or at least evaluate if a re-release is necessary), something that is typically just not practical for most LSB applications. The general issues with incorporating OpenSSL into LSB are ABI stability since the magic 1.0.0 release (while closer) has not happened yet, and just the shear size of the OpenSSL API. I spent quiet a bit of time conducting an analysis of 0.7.x-0.9.8d OpenSSL releases. (documented at http://www.freestandards.org/en/OpenSSL_stability_analysis) The analysis attempted to determine three things: What APIs are actually used by released applications and can a sub-set of the total OpenSSL API be created that is functionally useful and finally is that API subset ABI stable across many releases of OpenSSL. The answers are generally, yes it is possible to determine an API subset that will work for most applications that make use of OpenSSL (language bindings and the like are ignored here), and more-or-less yes that subset is ABI stable. Further experiments attempted to determine if by treating all or most OpenSSL structure types as opaque types (i.e. no stack allocations or direct structure manipulations) would give ABI stability. The quick answer there again is yes this provided almost perfect ABI stability, but with a loss of functionality. The loss of functionality was because a fairly large portion of the OpenSSL API is implemented as macros that perform trivial manipulations on OpenSSL data types. However since these are macros, it is not also possible to force the data types they manipulate to be opaque. In almost all cases it is fairly trivial to convert the macros into functions and remove the dependency on fully typed data types. Which brings me to my questions for the OpenSSL developer community: 1) First and most fundamentally: Is the general idea of attempting to only incorporate an API subset into the LSB ABI a good or acceptable one? LSB ABIs typically do not include every last interface of most libraries that are standardized either because the non-included APIs are really library internals, the API is not stable or is only useful in specialized cases. In this case the APIs I didnt include are as far as I can tell only useful in specialized cases, or have higher level APIs that provide the same functionality (EVP vs. DES). 2) Is my concern about API stability going forward using fully typed structures unfounded? 3) Are there concerns about converting large numbers of macros into functions? (Performance etc.) Thanks, Tracy Camp
Missing? EVP_CIPHER_CTX_create()/destroy() patch
Im working on an experiment to see if I can build applications that treat openssl data structures as opaque, so that they will be more binary compatible between openssl releases that may or may not change structure sizes. EVP_MD_CTX has a create/destroy interface so I can just have a pointer to a EVP_MD_CTX rather than actually embed one in my stack, EVP_CIPHER_CTX seems to be lacking these interfaces. So attached in a patch that adds them. Thanks, Tracy Camp evp_cipher_ctx.patch Description: evp_cipher_ctx.patch
