[reSIProcate] [PATCH] Add more and better salt values to callid computation

[Aron Rosenberg]

Here is a revised patch using the append method with proper Win32 types.

 

Aron

 

________________________________

From: Byron Campen [mailto:bcampen at estacado.net] 
Sent: Wednesday, January 24, 2007 8:16 AM
To: Aron Rosenberg
Cc: resiprocate-devel at list.resiprocate.org
Subject: Re: [reSIProcate] [PATCH] Add more and better salt values to
callid computation

 

            The kind of thing I would probably do is 

 

Data

Helper::computeCallId()

{

static Data hostname = DnsUtil::getLocalHostName();

Data hostAndSalt(hostname + Random::getRandomHex(16));

 

#ifndef USE_SSL //!bwc! we don't need this code if we're using openssl

#if defined(__linux__) || defined(__APPLE__)

       pid_t pid=getpid();

hostAndSalt.append((char*)(&pid),sizeof(pid));

#endif

#ifdef __APPLE__

       pthread_t thread=pthread_self();

hostAndSalt.append((char*)(&thread),sizeof(thread));

#endif

#ifdef WIN32

       WindowsPidTypeWhateverThatMightBeIAmNotAWindowsPerson
pid=::GetCurrentProcessId();

hostAndSalt.append((char*)(&pid),sizeof(pid));

#endif //Of ifdef WIN32

#endif //Of ifndef USE_SSL

return hostAndSalt.md5().base64encode(true);

}

 

 

Calling Data(int) does a int-to-string conversion, which is what I'm
trying to avoid. Otherwise, this patch looks good, except for the
windows pid type, but that is my fault :P

 

Best regards,

Byron Campen





 

________________________________

From: Byron Campen [mailto:bcampen at estacado.net] 
Sent: Tuesday, January 23, 2007 1:22 PM
To: Aron Rosenberg
Cc: resiprocate-devel at list.resiprocate.org
Subject: Re: [reSIProcate] [PATCH] Add more and better salt values to
callid computation

We should determine whether openssl has this problem. If it does not, we
could avoid this extra work when we have compiled with openssl. I do
agree that we need to patch the code to generate a longer sequence of
hex digits (or, at the very least, make it configurable).

Anyone know off the top of their head whether openssl has this
reentrancy problem?

OpenSSL does not have the concurrency problem. Their random number
functionality is available through <openssl/rand.h>, but that still
requires seeding and can have starvation issues if you request too much
data. On different platforms they make use of all sorts of tricks
including what I was doing above.

Also, it would take a lot less CPU to just append the raw bits to the
hostAndSalt than to do an int-to-string(Data) conversion.

Does this look a little cleaner / more efficient? If so, I will submit a
revised patch.

Helper::computeCallId()

static Data hostname = DnsUtil::getLocalHostName();

#if defined( hostAndSalt += Data(getpid());

#ifdef hostAndSalt += Data(pthread_self());

#ifdef hostAndSalt += Data(::GetCurrentProcessId()) +
Data(::GetCurrentThreadId());

return hostAndSalt.md5().base64encode(true);

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070124/c6391a2a/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: resiprocate_thread_random_callid.diff
Type: application/octet-stream
Size: 971 bytes
Desc: resiprocate_thread_random_callid.diff
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070124/c6391a2a/attachment.obj>