> From: Jeffrey Altman <[EMAIL PROTECTED]> > > jaltman> I prefer that des_old.h be compatible with libdes since that apps that > jaltman> are built using it assume that the api they were using was constant > jaltman> and unchanging. > > The way things work now, there is at least no clash with libdes on the > symbol level. > > The whole situation is otherwise a lose-lose one. There will always > be someone loseing from the changes we make. Either we lose libdes > compatibility by default or we lose the openssl 0.9.6 one. Take your > pick. It has been pointed out (and I think I agree) that OpenSSL > should prefer to be as compatible with the previous version of itself > before being compatible with anything external (like libdes).
Yes, but let's remember the reason this whole situation came up in the first place. There are a large number of applications that link to both Kerberos 4 and OpenSSL in place of libdes.a. These applications are not likely to be updated nor supported and yet we don't want to see all of them break simply because they load des.h. > jaltman> The apps that were designed to use OpenSSL were warned many times that > jaltman> the API set would change with each build. There are many other things > jaltman> I need to change in my app to make it build with earlier versions of > jaltman> OpenSSL. Adding an additional #define to that list is not a big > jaltman> deal. > > That makes the decision even easier. Thanks. I'm not sure I made myself clear. The point I was trying to make is that it is very difficult to support in the general sense different OpenSSL versions such as 0.9.5, 0.9.6, and 0.9.7 with a common code base that is unaware of the OpenSSL version number. The reason is that there are too many subtle changes that have taken place over the years. Most of this is primarily due to bug fixes. Some of it is due to the increased feature set. Especially when dealing with questions of certificate verification; available cipher suites; replacement of functions with macros or vice versa; and the new ASN.1 library. Therefore, any attempt to try to maintain compatibility between OpenSSL releases at this point is fool hardy. At best it leads developers into a false sense that their code will just work without actually looking at the semantic changes that have taken place within the API. > jaltman> > And oh, I wrote another blurb about DES_INT a while ago. > jaltman> No reaction at all. I'd like a reaction, very much even... > jaltman> > jaltman> I must have missed this one. Please repost or send the archive link. > > http://marc.theaimsgroup.com/?t=101512079300001&r=1&w=2 In this post you wrote: > After some discussion with OpenBSD folks, I've been convinced that > DES_INT should be norm rather than not on most platforms, since int > is 32 bits most often, at least on 32- and 64-bit architectures. > The blatant exception that I know of would be DOS, where int is > usually a 16-bit quantity, and where DES_LONG should be 'unsigned > long' rather than 'unsigned int'. > As far as I know, DES_LONG is supposed to be a 32-bit quantity. > Have I gotten this wrong? If not, I'll make appropriate changes to > Configure, and some problems on some 64-bit architectures may go > away. I'm not sure I understand the question you are looking for an answer to. Currently there is no reference to DES_INT in any of the DES code. The only reference is to DES_LONG. As far as I can tell by looking at the code, the code assumes that DES_LONG == 32-bits. It would probably make most sense to replace DES_LONG with DES_UINT32 to indicate exactly what is meant by it. Then DES_UINT32 can be defined on a per platform basis to choose the appropriate 32-bit unsigned integer type. Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 available now!!! The Kermit Project @ Columbia University includes Telnet, FTP and HTTP http://www.kermit-project.org/ secured with Kerberos, SRP, and [EMAIL PROTECTED] OpenSSL. Interfaces with OpenSSH ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
