Darryl Miles wrote:
Nanno Langstraat wrote:
The intended use of the patch is to call SHA1_Load_State() directly,
not SHA1_Init() followed by SHA1_Load_State().
In other words:
* The application starts by freely choosing either SHA1_Init() or
SHA1_Load_State()
* The application ends by freely choosing either SHA1_Final() or
SHA1_Drop()
This makes the API lifecycle distinct, either you are using the
SHA_CTX for Init/Final or Load_State/Drop you cant mix, is there a
technical reason why this is so? Like I pointed out you used to be
able to memcpy() the SHA_CTX with OpenSSL before the concept of an
'engine' was around.
I think you may have misread my quoted text. It specifically says that
the application can choose the beginning operation freely and choose the
ending operation freely.
I.e. that the application can mix freely.
SHA1_Drop() still seems like a bad naming choice to me and is not
self-documenting. Maybe these sorts of voodoo issues can be cleared
up with good documentation in the man-page. Maybe SHA1_End() is a
better than than SHA1_Drop(). init/end create/destroy load/save
pickup/drop have clear self documenting meaning.
I'll take any other name if there is a semi-consensus.
The thought behind the name "Drop()" is to signal the premature end of
the context (versus the "normal, full" lifecycle that ends with Final()).
I do personally think "End" would be more, not less, confusing, it is
has no distinct connotation to contrast with the existing "Final".
--
By the way, I have added documentation to the SHA1 man page, I will post
v2 of the patch shortly.
Nanno
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
