FYI, in a few weeks I'll have some time to actually implement and
submit patches. I'll attempt to identify useful points for automatic
self-initialization (any hints as to commonly used first calls, not
counting the callback setters, would be welcomed). I'll also have to
spend sometime with the b
On Wed, Aug 21, 2013 at 5:41 AM, Ben Laurie wrote:
> Something needs to be done, but won't this re-introduce the problem of
> /dev/random starvation, leading to more use of /dev/urandom (on platforms
> where this is a problem)?
>
> Mixing in the time seems like a safer solution that should also fi
On Wed, Aug 21, 2013 at 2:19 AM, Patrick Pelletier
wrote:
> An easy way to work around this, if you don't mind linking against pthreads,
> is to do this at the start of your application, after initializing OpenSSL:
>
> typedef void (*voidfunc) (void);
>
> if (ENGINE_get_default_RAND () == NULL)
>
On 21 August 2013 03:19, Patrick Pelletier wrote:
> On 8/15/13 11:51 PM, Patrick Pelletier wrote:
>
>> On Aug 15, 2013, at 10:38 PM, Nico Williams wrote:
>>
>> Hmm, I've only read the article linked from there:
>>> http://android-developers.**blogspot.com/2013/08/some-**
>>> securerandom-thought
On 8/21/13 12:19 AM, Patrick Pelletier wrote:
Nikolay Elenkov wrote a proof-of-concept that shows the pid-wrapping bug
on Android, and then I took it one step further and wrote a
proof-of-concept using OpenSSL in C, demonstrating that this is an
underlying OpenSSL bug:
https://gist.github.com/p
On 8/15/13 11:51 PM, Patrick Pelletier wrote:
On Aug 15, 2013, at 10:38 PM, Nico Williams wrote:
Hmm, I've only read the article linked from there:
http://android-developers.blogspot.com/2013/08/some-securerandom-thoughts.html
Yeah, that's the only place I've seen it, and then the Google+ th
On Fri, Aug 16, 2013 at 02:44:23PM +, Viktor Dukhovni wrote:
> On Fri, Aug 16, 2013 at 07:17:22AM -0700, Thomas J. Hruska wrote:
> > I think a lot of the init logic heralds from the original SSLeay
> > days. There seems to be intent that initialization is supposed to
> > happen in main() in the
On Thu, Aug 15, 2013 at 11:51:05PM -0700, Patrick Pelletier wrote:
> >Oh. Is there any reason not to blow that away, or at least build-time
> >select which to use?
>
> I'm in agreement with you; I just don't think you're going to get
> the OpenSSL folks on board. They'll probably say something l
On Fri, Aug 16, 2013 at 07:17:22AM -0700, Thomas J. Hruska wrote:
> I think a lot of the init logic heralds from the original SSLeay
> days. There seems to be intent that initialization is supposed to
> happen in main() in the application and libraries shouldn't be
> calling initialization routine
On 8/15/2013 10:24 AM, Nico Williams wrote:
Hi, I'm sorry if this has all been discussed extensively before. A
brief search for "DLL hell" in the archives turns up disappointingly
(and surprisingly) little. I do see a thread with messages from my
erstwhile colleagues at Sun/Oracle, so I know it
On Aug 15, 2013, at 10:38 PM, Nico Williams wrote:
Hmm, I've only read the article linked from there:
http://android-developers.blogspot.com/2013/08/some-securerandom-thoughts.html
Yeah, that's the only place I've seen it, and then the Google+ thread
I linked to is essentially the comment ar
On Thu, Aug 15, 2013 at 10:58 PM, Patrick Pelletier
wrote:
> On 8/15/13 10:24 AM, Nico Williams wrote:
>> . Recent developments, like Android's failure to properly initialize
>> OpenSSL's PRNG make me think it's time to table (in the British sense)
>> the issue once more.
>
> Can you point to any
On 8/15/13 10:24 AM, Nico Williams wrote:
. Recent developments, like Android's failure to properly initialize
OpenSSL's PRNG make me think it's time to table (in the British sense)
the issue once more.
Can you point to any article or post which explains exactly what the
OpenSSL half of the
13 matches
Mail list logo