James Carlson wrote: > Darren J Moffat writes: >> The reason for increasing CRYPT_MAXCIPHERTEXTLEN is because crypt_sha512 >> produces output greater than 100 chars in some cases. This requires an >> updated libc for testing on a live system (and will require that >> crypt_sha512 depends on the libc patch for S10 delivery). > > It's not quite clear to me how this is supposed to work, but the > <crypt.h> CRYPT_MAXCIPHERTEXTLEN constant is described in shadow(4), > so it appears it might possibly have been intended as a constant for > public use. It's certainly mixed in with a bunch of other public > symbols in the same header file,
Correct, it was defined in PSARC/2002/657 and in hindsight doing it that way was poor architecture on my part - but nobody in ARC commented on it so it got approved. > 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). > 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! If we don't increase CRYPT_MAXCIPHERTEXTLEN we can't ship crypt_sha512.so because it won't work in many cases. > 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. -- Darren J Moffat
