Darren J Moffat writes: > > How can we change this constant if we don't know who previously used > > The only hits google returns are: > > * The OpenSolaris source (all consumers are in ON), > * The Sun man pages on docs.sun.com or other sites hosting them. > * The synopsis on the opensolaris.org ARC community for PSARC/2002/657 > which is the case that added it. > * Someone hosting the Solaris 9 recommended patch set in an unpacked > form (it contains an updated SUNWhea and thus crypt.h).
So, it's a calculated risk. > > it and why wasn't this change mentioned in 2007/642? > > It wasn't mentioned in 2007/542 because I didn't know until testing the > SHA512 variant with the spec provided test vectors that it needed to be > increased. I ARC'd early! Before I wrote any code! This looks like a good reason to update 2007/542: the ARC'd project doesn't match what is being delivered. It's great that you ARC'd early, but I don't think that somehow negates the review requirement for things that might be discovered later. > If we don't increase CRYPT_MAXCIPHERTEXTLEN we can't ship > crypt_sha512.so because it won't work in many cases. Indeed. > > Won't existing > > callers that sized buffers based on that constant break when faced > > with an unexpected SHA512 digest? > > Yes they will but based on the above research it seems that it might not > be being used - at least not by anything google can find. > > What do you suggest I do with respect CRYPT_MAXCIPHERTEXTLEN. I'd either update 2007/542 or run a new fast-track indicating what you're doing and why. It's a potentially (though remotely) risky interface change that ought to be on record, particularly if you're asserting a patch/micro release binding. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
