On Thu, Sep 10, 2009 at 6:29 AM, Mark 2d3ww4...@sneakemail.com wrote:
I am always very concerned when I read questions like this. The
documentation says to implement the callbacks. Therefore you must
do so.
No offense, but that's what the mailing list is for. Granted, a
search might have
No offense, but I disagree. This list is for questions specific to OpenSSL
programming, not for questions like should I do what the documentation says.
Asking such a question shows a fundamental misunderstanding on correct
programming
techniques. Unfortunately this is all too common IME.
On Sun, Nov 9, 2008 at 4:06 PM, David Schwartz [EMAIL PROTECTED] wrote:
So what do you want to do if you run out of entropy?
Fail with an error condition stating that, rather than
the indeterminate hang in read() that was experienced.
I believe you need to compile with EGD support then.
On Sat, Nov 8, 2008 at 5:53 AM, David Schwartz [EMAIL PROTECTED] wrote:
That's a great question. Indeed, this platform (AIX) does have
/dev/random but apparently that too was exhausted because that
is checked first in our implementation. I think the fault is truly
with the system in
On Fri, Nov 7, 2008 at 9:38 AM, David Schwartz [EMAIL PROTECTED] wrote:
Sounds like the interface is badly thought out. Perhaps the best
reasonable
compromise, short of changing the interface, is to set a limit (maybe 3
seconds or so) to how long RANG_egd can block (this would mean it will
On Fri, Nov 7, 2008 at 3:56 PM, Kyle Hamilton [EMAIL PROTECTED] wrote:
There should be some means of determining how much entropy is actually
in the information obtained from the EGD. The return values should
reflect the number of bits stirred in, with 0 being we haven't gotten
anything yet.
Hi there,
I'm investigating a case where a customer's prngd service was blocking,
which by itself is not supposed to happen AFAIK. This was causing a
hard-to-diagnose startup hang for our code that uses OpenSSL. The call to
RAND_egd() was blocking in a call to read().
I would like to address
On Thu, Nov 6, 2008 at 9:11 PM, David Schwartz [EMAIL PROTECTED] wrote:
There needs to be a call to fcntl(fd,F_SETFL,O_NONBLOCK) just after
the socket() call and error status check.
That will just waste CPU. The code will spin in each loop while
(!success) loop until it gets what it
On Dec 20, 2007 9:47 PM, Jacob Barrett [EMAIL PROTECTED] wrote:
Following the instructions in the FIPS users guide I can build the FIPS
Object Module just fine. What I can't get to work is the Windows DLL build
of OpenSLL with the FIPS module. I can build that static libraries with
FIPS
and
On 7/17/07, Elia, Leonard F. [EMAIL PROTECTED] wrote:
The Solaris version fails on test_sha. I thought perhaps this was a
problem with the SUN toolchain, so I rebuilt it using gcc 3.4.6 but it
still fails:
FYI, I found it necessary to build gcc 4.1.2 on our Solaris machines for
FIPS support
On 12/9/06, Michal Trojnara [EMAIL PROTECTED] wrote:
The library is OpenSSL 0.9.8d configured with:
./Configure threads shared zlib debug-linux-elf
Can you help me find a solution or a better workaround?
Did you set the threading/locking callbacks to valid implementations? (for
reference,
On 3/18/06, Mark Slater [EMAIL PROTECTED] wrote:
After looking into the results others had (darwinports.org), Idiscovered that the Openssl-0.9.7i Configure script is broken in thatit assumes Intel-based macs are big endian like all other macs, when
in fact they are little endian.It seems that this
On 1/16/06, Felix Dorner [EMAIL PROTECTED] wrote:
this should be a oneliner, my first steps in openssl programming.the line EVP_CIPHER *blowfish_cbc = EVP_bf_cbc();gives me a warning that I do not understand:warning: initialization discards qualifiers from pointer target type
Felix,The return
13 matches
Mail list logo
