get current time
How can I get current time inside Apache-OpenSSL (in ssl_engine_kernel.c) and also sum a value in time format ? Thanks everybody Andrea __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: solaris config... fyi
In the Change log for gcc 2.8.0 there is an entry for "Mon Oct 20 17:29:55 1997" where Doug Evans added the ultrasparc case. At ftp://ftp.gnu.org/pub/gnu/gcc/, the file gcc-2.9.0.tar.gz is dated "Wed Jan 14 00:00:00 1998" I'd picked up gcc 2.7.2.3 because it was all that I saw on solaris-freeware earlier in the year... but now they've got up to gcc-2.8.1... Sean Andy Polyakov wrote: Ulf Möller wrote: $ gcc --version 2.7.2.3 cc1: Invalid option `cpu=ultrasparc' Thanks for pointing that out. Since which version does gcc support ultrasparc? Since 2.8 I believe. In either case note that those UltraSPARC-specific assembler modules can be perfectly "compiled" with 2.7 as it's only preprocessor that is hired anyway. Andy. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: version number
Ulf Möller wrote: release without change if they track all the way to the end. We don't support distinguishing an arbitrary snapshot of a development version, though; only the latest. So, if you have support for a feature in 0.9.4, then you test like this: #if OPENSSL_VERSION = 0x00904000 In that case I would just test for the release version number OPENSSL_VERSION = 0x000904100, ignoring that the feature already is present in some of the development versions. But we're talking about a change that breaks existing code here, not about new features. I don't want to infer what was done in the past is necessarily right but just about every version change major or minor has broken *some* existing code. The typesafe stack stuff in the current release for example breaks some stuff I have (not just a warning actual compiler choking). Thats probably just an indication that I tend to do weirder stuff in my code though :-) Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: [EMAIL PROTECTED] PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: X509_STORE_load_locations
Ron Ramsay wrote: Thanks for the extensive reply. A part of your answer is reproduced below. I don't think handling the depth internally (which is a good thing) completely removes the need for a callback. I agree, sometimes you need to handle "special" situations when verifying certificates. And its in the callback, where you can actually check why a certificate failed, and hence act on the failure, or pass back some useful information back to your application. Another reason for requiring a callback is to obtain the certificate status. This could be achieved with a certificate status callback. With the code as it stands today, however, the best place to verify the status of the certificate would seem to be in the verify callback. Ron. -- But anyway I think that it shouldn't be necessary to use a verify callback function. I've recently added functions to the SSL API that allow defining a verification depth, because this is something that the library should be able to do, and there _is_ support for it in the X.509 library (but the X.509 library does not yet produce the right error code when the length is exceeded). __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
about unsigned char **pp
in crypto/asn1 , many "unsigned char **pp", like in crypto/asn1/asn1_lib.c ,define void ASN1_put_object(unsigned char **pp, int constructed, int length, int tag,int xclass) why not just "unsigned char *pp" ? __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: version number
And I'm talking about a versioning system than handles that so long as you remember that we don't support code based on development versions. Of course that is reasonable. But then it would be nice if bugs in the release versions were fixed faster. For example, version 0.9.2 has been distributed with a broken config for most non-Intel platforms for two months. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: version number
"Ralf S. Engelschall" [EMAIL PROTECTED]: Yes, Ben is right: At the release level people can use OPENSSL_VERSION_NUMBER and that should be enough. When we start at the development level to increase a number for every API change we get the same chaos as for Apache: it's often forgotten, people complain about two much such numbers to check for, etc. pp. We *could* add a file with an extra #define that is automatically set to the current date each time a snapshot is tar'ed -- e.g. #define OPENSSL_VERSION_DATE 0x19990518 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: version number
Bodo Moeller wrote: "Ralf S. Engelschall" [EMAIL PROTECTED]: Yes, Ben is right: At the release level people can use OPENSSL_VERSION_NUMBER and that should be enough. When we start at the development level to increase a number for every API change we get the same chaos as for Apache: it's often forgotten, people complain about two much such numbers to check for, etc. pp. We *could* add a file with an extra #define that is automatically set to the current date each time a snapshot is tar'ed -- e.g. #define OPENSSL_VERSION_DATE 0x19990518 Yes, I'd have zero objection to that! Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: X509_STORE_load_locations
But anyway I think that it shouldn't be necessary to use a verify callback function. I've recently added functions to the SSL API that allow defining a verification depth, because this is something that the library should be able to do, and there _is_ support for it in the X.509 library (but the X.509 library does not yet produce the right error code when the length is exceeded). I don't think handling the depth internally (which is a good thing) completely removes the need for a callback. Another reason for requiring a callback is to obtain the certificate status. This could be achieved with a certificate status callback. With the code as it stands today, however, the best place to verify the status of the certificate would seem to be in the verify callback. For very special needs you will always have to use (and will be able to use) an application-defined callback function, of course. But commonly used functionality should be in the library. What you can do without a callback now is get the verification result (SSL_get_verify_result, with return values such as X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT, X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT[_LOCALLY], X509_V_ERR_CERT_HAS_EXPIRED, and in the future also X509_V_ERR_CERT_CHAIN_TOO_LONG [you'll now get X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT[_LOCALLY] instead of this one]) and the peer's certificate and certificate chain (SSL_get_peer_certificate, SSL_get_peer_cert_chain). For typical applications these functions should be enough. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: solaris config... fyi
On Wed, May 19, 1999 at 09:39:36AM +0100, Seán ó Ríordáin wrote: In the Change log for gcc 2.8.0 there is an entry for "Mon Oct 20 17:29:55 1997" where Doug Evans added the ultrasparc case. At ftp://ftp.gnu.org/pub/gnu/gcc/, the file gcc-2.9.0.tar.gz is dated "Wed Jan 14 00:00:00 1998" I'd picked up gcc 2.7.2.3 because it was all that I saw on solaris-freeware earlier in the year... but now they've got up to gcc-2.8.1... Does that mean that there's now no-one left to test the compatibility with gcc 2.7.* on Solaris :-)? (I've added a new entry solaris-usparc-oldgcc for this which is the same as solaris-usparc-gcc except that -mcpu=ultrasparc is not set. If everything works that way, it's saner than stepping down to solaris-sparc-gcc.) __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: about unsigned char **pp
gang cao wrote: in crypto/asn1 , many "unsigned char **pp", like in crypto/asn1/asn1_lib.c ,define void ASN1_put_object(unsigned char **pp, int constructed, int length, int tag,int xclass) why not just "unsigned char *pp" ? After reading/writing an ASN1 structure you almost always want to read/write another one after the first. As a result the pointer to the DER encoding is incremented to point to the "next" structure if the current one is read/written correctly. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: [EMAIL PROTECTED] PGP key: via homepage. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: about unsigned char **pp
in crypto/asn1 , many "unsigned char **pp", Pointer to array of pointers to unsigned char Sigh. Wrong. It's the address of a character pointer. As Dr. Henson pointed out, the ASN1 routines typically take a buffer pointer, parse some bytes, and update the pointer. Hence the indirection. (In C++ you'd use pass-by-reference, "unsigned char* pp", which is easier to understand, but ends up being the same implementation-wise :) You might want to find the "cdecl" program: cdecl explain unsigned char **pp declare pp as pointer to pointer to unsigned char cdecl declare ppp as pointer to array of pointer to unsigned char Warning: Unsupported in C -- 'Pointer to array of unspecified dimension' (maybe you mean "pointer to object") unsigned char *(*ppp)[] Pedantically, /r$ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: version number
In article [EMAIL PROTECTED] you wrote: "Ralf S. Engelschall" [EMAIL PROTECTED]: Yes, Ben is right: At the release level people can use OPENSSL_VERSION_NUMBER and that should be enough. When we start at the development level to increase a number for every API change we get the same chaos as for Apache: it's often forgotten, people complain about two much such numbers to check for, etc. pp. We *could* add a file with an extra #define that is automatically set to the current date each time a snapshot is tar'ed -- e.g. #define OPENSSL_VERSION_DATE 0x19990518 Yes, an automatic and simple approach like this is ok. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: solaris config... fyi
In the Change log for gcc 2.8.0 there is an entry for "Mon Oct 20 17:29:55 1997" where Doug Evans added the ultrasparc case. At ftp://ftp.gnu.org/pub/gnu/gcc/, the file gcc-2.9.0.tar.gz is dated "Wed (I've added a new entry solaris-usparc-oldgcc for this which is the same as solaris-usparc-gcc except that -mcpu=ultrasparc is not set. Wow-wow-wow! The least you could do is to say -mv8 instead:-) Why leave hardware multiplication out? In either case I actually won't be suprised if gcc-27 will currently generate sligtly faster code with -mv8. The catch is that it's not many of ultrasparc features that get actually engaged when you say -mcpu=ultrasparc. From from I've seen it doesn't dare to go much further than using of branch with prediction and it almost always generated "predict not taken" when it should say "predict taken". No, it doesn't mean that I suggest to put -mv8 even to solaris-usparc-gcc. Just a comment:-) Andy. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: solaris config... fyi
Andy Polyakov [EMAIL PROTECTED]: (I've added a new entry solaris-usparc-oldgcc for this which is the same as solaris-usparc-gcc except that -mcpu=ultrasparc is not set. Wow-wow-wow! The least you could do is to say -mv8 instead:-) Er, yes. I've added -mv8 now. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Session ID Caching?
I'm currently using openssl 0.9.2b, and would like the ability to enable/disable session ID caching. Is there a command or particular source file I need to deal with in order to make this happen. Thanks, Vince __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
