TLS/SSL and crypto library. http://git.bktus.com/gpgfrontend/openssl/atom?h=OpenSSL_1_0_0b 2008-10-14T08:10:52Z 2008-10-14T08:10:52Z Ben Laurie ben@openssl.org 2008-10-14T08:10:52Z urn:sha1:1ea6472e604ed0e411fa41fcb5f242729ee42cd6 2008-06-04T11:01:43Z Ben Laurie ben@openssl.org 2008-06-04T11:01:43Z urn:sha1:5ce278a77bd7d23bcf965cfa37afb7b937c1a17d 2004-10-04T16:30:12Z Dr. Stephen Henson steve@openssl.org 2004-10-04T16:30:12Z urn:sha1:2f605e8d24ac054a862e0fc4ea7e53196c99bb7e 2003-04-29T20:30:55Z Richard Levitte levitte@openssl.org 2003-04-29T20:30:55Z urn:sha1:26851b6b42260bdfd5c5b8332b5d3d00fa60f3df even if an exact match wasn't found. 2000-06-16T23:29:26Z Dr. Stephen Henson steve@openssl.org 2000-06-16T23:29:26Z urn:sha1:3aceb94b9e6ac4722b96d4fb1cf7e1a4358941e0 After some messing around this seems to work but needs a few more tests. Working out the syntax for sk_set_cmp_func() (cast it to a function that itself returns a function pointer) was painful :-( Needs some testing to see what other compilers think of this syntax. Also needs similar stuff for ASN1_SET_OF etc etc. 2000-06-01T02:15:40Z Geoff Thorpe geoff@openssl.org 2000-06-01T02:15:40Z urn:sha1:7bb7043580900b8f06cb418b46004b755ff0fc96 same one). However, the first will temporarily break things until the second comes through. :-) The safestack.h handling was mapping compare callbacks that externally are of the type (int (*)(type **,type **)) into the underlying callback type used by stack.[ch], which is (int (*)(void *,void *)). After some degree of digging, it appears that the callback type in the underlying stack code should use double pointers too - when the compare operations are invoked (from sk_find and sk_sort), they are being used by bsearch and qsort to compare two pointers to pointers. This change corrects the prototyping (by only casting to the (void*,void*) form at the moment it is needed by bsearch and qsort) and makes the mapping in safestack.h more transparent. It also changes from "void*" to "char*" to stay in keeping with stack.[ch]'s assumed base type of "char". Also - the "const" situation was that safestack.h was throwing away "const"s, and to compound the problem - a close examination of stack.c showed that (const char **) is not really achieving what it is supposed to when the callback is being invoked, what is needed is (const char * const *). So the underlying stack.[ch] and the mapping macros in safestack.h have all been altered to correct this. What will follow are the vast quantities of "const" corrections required in stack-dependant code that was being let "slip" through when safestack.h was discarding "const"s. These now all come up as compiler warnings. 2000-05-31T17:35:11Z Geoff Thorpe geoff@openssl.org 2000-05-31T17:35:11Z urn:sha1:e20d7d71677c6d56f9e486148a0d33cb639765eb Also, add in a couple of missing declarations in pkcs7 code. 2000-05-31T15:28:01Z Geoff Thorpe geoff@openssl.org 2000-05-31T15:28:01Z urn:sha1:01296a6de0f968d741d871efda8ab4ed5420442d cast their type-specific STACK into a real STACK and call the underlying sk_*** function. The problem is that if the STACK_OF(..) parameter being passed in has a "const *" qualifier, it is discarded by the cast. I'm currently implementing a fix for this but in the mean-time, this is one case I noticed (a few type-specific sk_**_num() functions pass in const type-specific stacks). If there are other errors in the code where consts are being discarded, we will similarly not notice them. yuck. 2000-05-15T22:54:43Z Ulf Möller ulf@openssl.org 2000-05-15T22:54:43Z urn:sha1:0e1c06128adbfd2d88dc304db2262140bad045fd 1999-11-26T00:27:07Z Dr. Stephen Henson steve@openssl.org 1999-11-26T00:27:07Z urn:sha1:d4cec6a13dfb2c1d1ddf66dff499aaf21bbbf002 Extend the X509_PURPOSE structure to include shortnames for purposed and default trust ids. Still need some extendable trust checking code and integration with the SSL and S/MIME code.