>>> If the other EVP ciphers universally allow this then I think we must >> treat this >>> as a bug, because people may be relying on this behaviour. There is also >>> sporadic documentation in lower-level APIs (AES source and des.pod) that >> the >>> buffers may overlap. >>> >>> If it's inconsistent then, at the very least, we must document that it >> is not >>> allowed. >> >> I'd like to argue that EVP is not place to provide any guarantees about >> partially overlapping buffers. Even though all current ciphers process >> data in ascending address order, we shouldn't make assumption that there >> won't be one that processes data in reverse order. > > > I'm afraid that, since we haven't documented it, the world may already have > made that assumption.
Fear is irrational and destructive feeling. Having faith that world is better than that it nothing but healthy :-) What I'm saying is that let's put a little bit more substance into discourse. Would anybody consider it *sane* programming practice to rely on partially overlapping buffers in *general* case? I.e. without actually *knowing* (as opposite to *assuming*) what's gong on? [Control question: does compiler guarantee order of references to memory?] As said in last message I don't consider it sane and even consider it natural [which means that I'd expect majority to not consider it sane too]. Once again, I'm not saying that nothing would be done, I simply want to figure out where does line go. From my personal view point I'd say that nothing *has to* be done, but it's just me. You seem to say that we're obliged to support partially overlapping buffers. My question then is *any* overlap, *any* cost? Shall we settle for simply writing down that application developer may not rely on partially overlapping buffers? If so, do we fix the modules in question arguing that this quality might be desirable in different context [where modules in question can be used]? -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4362 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
