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

["Aron Rosenberg" <arosenberg@xxxxxxxxxxxxxx>]

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

 

Aron

 

---

From: Byron Campen [mailto:bcampen@xxxxxxxxxxxx]
Sent: Wednesday, January 24, 2007 8:16 AM
To: Aron Rosenberg
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxx]
Sent: Tuesday, January 23, 2007 1:22 PM
To: Aron Rosenberg
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
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);

Attachment: resiprocate_thread_random_callid.diff
Description: resiprocate_thread_random_callid.diff