From: Jeffrey Altman <[EMAIL PROTECTED]> jaltman> > From: Jeffrey Altman <[EMAIL PROTECTED]> jaltman> > jaltman> > jaltman> I prefer that des_old.h be compatible with libdes since that apps that jaltman> > jaltman> are built using it assume that the api they were using was constant jaltman> > jaltman> and unchanging. jaltman> > jaltman> > The way things work now, there is at least no clash with libdes on the jaltman> > symbol level. jaltman> > jaltman> > The whole situation is otherwise a lose-lose one. There will always jaltman> > be someone loseing from the changes we make. Either we lose libdes jaltman> > compatibility by default or we lose the openssl 0.9.6 one. Take your jaltman> > pick. It has been pointed out (and I think I agree) that OpenSSL jaltman> > should prefer to be as compatible with the previous version of itself jaltman> > before being compatible with anything external (like libdes). jaltman> jaltman> Yes, but let's remember the reason this whole situation came up in the jaltman> first place. There are a large number of applications that link to jaltman> both Kerberos 4 and OpenSSL in place of libdes.a. These applications jaltman> are not likely to be updated nor supported and yet we don't want to jaltman> see all of them break simply because they load des.h.
The problem is if kerb4 requires linking with -ldes, both at a symbol and semantic level. Applications linking with krb4 have to link with -ldes as well as -lcrypto. This is possible since -lcrypto doesn't clash with the -ldes symbols any more. To include libdes' des.h and link with -lcrypto from OpenSSL 0.9.6 is supperbly dangerous, *especially* on most 64bit architectures, where the size of DES_LONG differ (this is true for libdes vs. SSLeay as well, BTW). I only see one scenario where there might be trouble: including libdes' des.h before openssl/des.h, since they most likely use the same macro to mark that des.h has been included. This will also happen if one includes krb4's krb.h (which includes des.h, most likely) before openssl/des.h. I guess renaming that macro in OpenSSL's des.h might be the answer. jaltman> > jaltman> The apps that were designed to use OpenSSL were warned many times that jaltman> > jaltman> the API set would change with each build. There are many other things jaltman> > jaltman> I need to change in my app to make it build with earlier versions of jaltman> > jaltman> OpenSSL. Adding an additional #define to that list is not a big jaltman> > jaltman> deal. jaltman> > jaltman> > That makes the decision even easier. Thanks. jaltman> jaltman> I'm not sure I made myself clear. The point I was trying to make is jaltman> that it is very difficult to support in the general sense different jaltman> OpenSSL versions such as 0.9.5, 0.9.6, and 0.9.7 with a common code jaltman> base that is unaware of the OpenSSL version number. The reason is jaltman> that there are too many subtle changes that have taken place over the jaltman> years. Most of this is primarily due to bug fixes. Some of it is due jaltman> to the increased feature set. Especially when dealing with questions jaltman> of certificate verification; available cipher suites; replacement of jaltman> functions with macros or vice versa; and the new ASN.1 library. jaltman> jaltman> Therefore, any attempt to try to maintain compatibility between jaltman> OpenSSL releases at this point is fool hardy. At best it leads jaltman> developers into a false sense that their code will just work without jaltman> actually looking at the semantic changes that have taken place within jaltman> the API. Well, introducing libdes compatibility by default is then a bad thing, isn't it? It would introduce the false sense that OpenSSL is completely libdes-compatible :-). jaltman> > http://marc.theaimsgroup.com/?t=101512079300001&r=1&w=2 jaltman> jaltman> In this post you wrote: jaltman> jaltman> > After some discussion with OpenBSD folks, I've been convinced that jaltman> > DES_INT should be norm rather than not on most platforms, since int jaltman> > is 32 bits most often, at least on 32- and 64-bit architectures. jaltman> > The blatant exception that I know of would be DOS, where int is jaltman> > usually a 16-bit quantity, and where DES_LONG should be 'unsigned jaltman> > long' rather than 'unsigned int'. jaltman> jaltman> > As far as I know, DES_LONG is supposed to be a 32-bit quantity. jaltman> > Have I gotten this wrong? If not, I'll make appropriate changes to jaltman> > Configure, and some problems on some 64-bit architectures may go jaltman> > away. jaltman> jaltman> I'm not sure I understand the question you are looking for an answer jaltman> to. Currently there is no reference to DES_INT in any of the DES jaltman> code. The only reference is to DES_LONG. As far as I can tell by jaltman> looking at the code, the code assumes that DES_LONG == 32-bits. jaltman> It would probably make most sense to replace DES_LONG with DES_UINT32 jaltman> to indicate exactly what is meant by it. Then DES_UINT32 can be jaltman> defined on a per platform basis to choose the appropriate 32-bit jaltman> unsigned integer type. DES_INT is a configuration option. If given, DES_LONG will be defined as 'unsigned int', otherwise it will be 'unsigned long'. This has no impact whatsoever on 32bit machines. However, on pure 64bit machines, there is a size difference. -- Richard Levitte \ Spannv�gen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See <http://www.stacken.kth.se/~levitte/mail/> for more info. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
