In message <[EMAIL PROTECTED]> on Mon, 17 May 2004 00:44:53 +0200, Andy Polyakov <[EMAIL PROTECTED]> said:
appro> > appro> > appro> Log: appro> > appro> > appro> size_t-fication of message digest APIs. We should size_t-fy more appro> > appro> > appro> APIs... appro> > appro> > Well, I think I've worked in a different way than you. appro> appro> I simply had different "excuse," introduction of fresh code, appro> SHA-512 and co:-) OBTW, you should add license texts in all the files you committed. appro> > I started with appro> > the memory allocation functions and let the effects spread. I've also appro> > taken a look at some header files and adjusted what needed to be appro> > adjusted, then modified all C files where the compiler complained. appro> > This work is still going on... appro> ^^^^^ That's the problem with this approach. It appro> gets so big, you start feeling insecure, don't you? Not at all. Think about it a little bit, if I change one cipher, I have to change them all. Oh, and I have to change the macros BLOCK_CIPHER_func_ofb, BLOCK_CIPHER_func_cbc and BLOCK_CIPHER_func_cfb, because they're casting inl to long (I removed the cast), meaning you need to change the EVP layer functions, and why should one stop there and introduce some temporary casts? As soon as the EVP layer is affected, it ramifies to the rest of OpenSSL. Note that we *need* to make sure there are no unsigned vs. signed clashes, or we will have the Windows horde on our backs more or less immediately. appro> Not that is's wrong approach, it just takes more guts to attack appro> the problem... AND time. The only reason that I haven't done more (and as you could see, there's a lot done) is that I've had other priorities. The size_t stuff is something I've done in between other things. Also, there are a few cases when I'm not entirely sure that converting to size_t is the right thing... appro> Yet I'd prefer to see changes applied in "zones," say ciphers, appro> bio, asn1, etc., not as monolith mumbo-jumbo. You do have a point, and sure, I can commit things that I've finished, no problems. The ciphers with the EVP-level remifications could be a good start, for example... appro> It would be easier to grasp and audit. And I don't think appro> everything has to be size_t-fied. In some situations it might appro> be easier and in a sense more appropriate to leave API appro> unchanged. appro> BN and PKI stuff for example. In a cipher case there is a appro> *remote* possibility that someone would like to take full appro> advantage of size_t. But in BN or PKI case on the other it appro> would/should be considered as a DoS attack. A. There's gonna be quite a lot of new casts with that approach... ----- Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte \ Tunnlandsv�gen 52 \ [EMAIL PROTECTED] [EMAIL PROTECTED] \ S-168 36 BROMMA \ T: +46-708-26 53 44 \ SWEDEN \ 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]
