Re: OPENSSL_gmtime on platforms that don't have a safe gmtime function
On Aug 11 12:29, Joe Gluck wrote:
The OPENSSL_gmtime in o_time.c (that gets called from other places like
ASN1_UTCTIME_cmp_time_t in a_utctm.c) does not use the safe version of
gmtime in lots of platforms including:
OPENSSL_SYS_WIN32
OPENSSL_SYS_OS2
__CYGWIN32__
OPENSSL_SYS_MACOSX
OPENSSL_SYS_SUNOS
This could cause problems in multi-thread environments, why not use mutexes
to wrap the gmtime and memcpy, like other places in the library?
Please drop Cygwin from this list since it has gmtime_r for ages. I'm
sorry that I missed that. See patch below.
Corinna
--- crypto/o_time.c.orig2006-08-13 10:23:23.815738500 +0200
+++ crypto/o_time.c 2006-08-13 10:23:34.211600500 +0200
@@ -73,7 +73,7 @@ struct tm *OPENSSL_gmtime(const time_t *
{
struct tm *ts = NULL;
-#if defined(OPENSSL_THREADS) !defined(OPENSSL_SYS_WIN32)
!defined(OPENSSL_SYS_OS2) !defined(__CYGWIN32__)
(!defined(OPENSSL_SYS_VMS) || defined(gmtime_r))
!defined(OPENSSL_SYS_MACOSX) !defined(OPENSSL_SYS_SUNOS)
+#if defined(OPENSSL_THREADS) !defined(OPENSSL_SYS_WIN32)
!defined(OPENSSL_SYS_OS2) (!defined(OPENSSL_SYS_VMS) || defined(gmtime_r))
!defined(OPENSSL_SYS_MACOSX) !defined(OPENSSL_SYS_SUNOS)
/* should return data, but doesn't on some systems,
so we don't even look at the return value */
gmtime_r(timer,result);
--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
RE: OPENSSL_gmtime on platforms that don't have a safe gmtime function
Hi, why not use mutexes to wrap the gmtime and memcpy, like other places in the library? Because it is either needless or insufficient. (snipp) On platforms where thread-specific data is not used, the mutexes would not prevent other code (not part of OpenSSL) from calling these functions in-between when OpenSSL calls them and when the returned data can be used or copied. Well, while it is still insufficient, mutexes would allow a user calling OpenSSL functions from multiple threads to do so without having to worry about all the internals, like do function a() and b() both use gmtime internally, so a common mutex around those two function calls is needed? Not to mention that in a cross-platform application it's going to be needed on a few platforms only, while on most it will work without them. Ensures interesting testing and debugging sessions, IMO. Of course, if the user is calling gmtime himself, he still needs to know such stuff, but that might be less common than calling two openssl functions that end up calling gmtime. Also, you could add a warning in such case that any multi-threaded application needs to wrap their gmtime calls with such and such mutex. OTOH, if you have two or more libraries taking this approach, each using a gmtime wrapper with its own mutex, that's possibly going to be more confusing than helpful. Regards, Stefan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: OPENSSL_gmtime on platforms that don't have a safe gmtime function
All, David cam up with a solution that looks to me as some thing that would be really nice, he suggested that OpenSSL would allow the developer to register a callback function to do the unsafe functions. However while he thinks OpenSSL should default to the OS 'best' function available, I am not sure, could be that it still could be good to have at least the OpenSSL functions clean with mutex. Q. What do we (Me or some one else) needs to do to get this callback function thing rolling into the CVS? Joe On 8/12/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, why not use mutexes to wrap the gmtime and memcpy, like other places in the library? Because it is either needless or insufficient.(snipp) On platforms where thread-specific data is not used, the mutexes would not prevent other code (not part of OpenSSL) from calling these functions in-between when OpenSSL calls them and when the returned data can be used or copied.Well, while it is still insufficient, mutexes would allow a user callingOpenSSL functions from multiple threads to do so without having to worry aboutall the internals, like do function a() and b() both use gmtime internally, so a common mutex around those two function calls is needed? Not to mentionthat in a cross-platform application it's going to be needed on a few platformsonly, while on most it will work without them. Ensures interesting testing and debugging sessions, IMO.Of course, if the user is calling gmtime himself, he still needs to know suchstuff, but that might be less common than calling two openssl functions thatend up calling gmtime. Also, you could add a warning in such case that any multi-threaded application needs to wrap their gmtime calls with such and suchmutex.OTOH, if you have two or more libraries taking this approach, each using agmtime wrapper with its own mutex, that's possibly going to be more confusing than helpful. Regards, Stefan__OpenSSL Project http://www.openssl.orgDevelopment Mailing List openssl-dev@openssl.orgAutomated List Manager [EMAIL PROTECTED]
OPENSSL_gmtime on platforms that don't have a safe gmtime function
The OPENSSL_gmtime in o_time.c (that gets called from other places like ASN1_UTCTIME_cmp_time_t in a_utctm.c) does not use the safe version of gmtime in lots of platforms including:OPENSSL_SYS_WIN32OPENSSL_SYS_OS2 __CYGWIN32__OPENSSL_SYS_MACOSXOPENSSL_SYS_SUNOS This could cause problems in multi-thread environments, why not use mutexes to wrap the gmtime and memcpy, like other places in the library? Is there any one that can add this to CVS? Thanks Joe
RE: OPENSSL_gmtime on platforms that don't have a safe gmtime function
The OPENSSL_gmtime in o_time.c (that gets called from other places like ASN1_UTCTIME_cmp_time_t in a_utctm.c) does not use the safe version of gmtime in lots of platforms including: OPENSSL_SYS_WIN32 OPENSSL_SYS_OS2 __CYGWIN32__ OPENSSL_SYS_MACOSX OPENSSL_SYS_SUNOS This could cause problems in multi-thread environments, why not use mutexes to wrap the gmtime and memcpy, like other places in the library? Because it is either needless or insufficient. On platforms like Win32 that already use thread-specific data for functions like gmtime, it is needless. The functions are thread-safe anyway. On platforms where thread-specific data is not used, the mutexes would not prevent other code (not part of OpenSSL) from calling these functions in-between when OpenSSL calls them and when the returned data can be used or copied. In a library, I don't think you can do better than using the thread-safe functions where they exist. DS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
