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
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+
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:
On 21 August 2013 03:19, Patrick Pelletier c...@funwithsoftware.org 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-**
On Wed, Aug 21, 2013 at 2:19 AM, Patrick Pelletier
c...@funwithsoftware.org 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
On Wed, Aug 21, 2013 at 5:41 AM, Ben Laurie b...@links.org 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
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
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
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 routines
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 like we
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
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's been discussed,
e.g., here: http://www.mail
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
On Thu, Aug 15, 2013 at 10:58 PM, Patrick Pelletier
c...@funwithsoftware.org 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
14 matches
Mail list logo
