YUN GAO wrote:
Hi there:
SSL_shutdown used to have a problem that in some instances it always
returns 0 no matter how many time it is called before 0.9.8l.
To solve the issue, I have to call SSL_shutdown() twice and check the
error number and return code at the second time: if the return code
is
Priyaranjan Nayak wrote:
I am using openssl-1.0.1c in our project.when SSL_shutdown(ssl)
get executed it returns 0.If I get return value zero then calling the
same SSL_shutdown(ssl) again.In 2nd time it return -1. Can any one tell
me how to shutdown ssl context ? How can I execute
Dave Mitchell wrote:
Can calls to non-blocking SSL_read() and SSL_write() be interleaved?
I'm doing select() / event driven IO, and using a BIO pair to handle the
underlying socket IO myself.
Yes, but not from 2 threads working on the same SSL * at the same time.
So your single threaded
Rahila Syed wrote:
I am using OpenSSH compression for compressing data between
PostgreSQL servers. I am using following command,
ssh -c arcfour,blowfish-cbc -4 -2 -v -C -L 3304:localhost:5432 user@server2
I want to know if vulnerability CRIME which attacks SSL deflate
compression
Salz, Rich wrote:
The common practice is for clients to connect in the clear, then issue a command to turn
on TLS, such as the SMTP STARTTLS command.
It is only common practice for a small number of well known protocols.
This doesn't mean it is the best solution.
If you have a bespoke
Rajeswari K wrote:
In our application we open non blocking socket for read and write
operation and pass the fd to openssl through BOI API's like this
bio = BIO_new(BIO_s_socket());
BIO_set_fd(bio, socket_fd, BIO_NOCLOSE);
And
we update this bio to SSL using SSL_set_bio() function.
My query
Bobby Krupczak wrote:
1) In bn_rand.c add at line 141: memset(buf, 0, bytes); =20
buf = (unsigned char *)OPENSSL_malloc(bytes);
if (buf == NULL)
{
BNerr(BN_F_BNRAND,ERR_R_MALLOC_FAILURE);
goto err;
}
memset(buf, 0, bytes);
2) bn_mont.c: Initialize
Jinsong Du wrote:
I have a simple server using blocked socket and OpenSSL, its only
function is for user registering an account. When an user connect to
this server, it spawns a child process to handle the request. I found
sometime child processes got stuck.
The problem here is that what if 2
Mark wrote:
Presumably you can use multiple threads for reading and writing as long
as you
ensure that they are not both calling an SSL function at the same time?
Function ???
The important aspect is the principal object/handle you are passing the
function. For most of the API that an
[EMAIL PROTECTED] wrote:
I have an application which is occasionally hanging. I have tracked it
down to an SSL_shutdown call.
There is an issue with SSL_shutdown() on non-blocking sockets in respect
of knowing when to use the shutdown() call.
I'm not exactly sure if you have run into this
David Schwartz wrote:
Which is pretty much the same as every other operation. If you call 'send'
or 'write' on a blocking TCP socket, and you get a zero return, does that
mean the data has been sent? No. It means the data is queued and the send is
in progress. If you call 'shutdown' on a
==13777== 128 bytes in 1 blocks are still reachable in loss record 1 of 2
==13777==at 0x4004BEC: realloc (vg_replace_malloc.c:306)
==13777==by 0x8052515: default_realloc_ex (mem.c:86)
==13777==by 0x8052B3E: CRYPTO_realloc (mem.c:331)
==13777==by 0x8062B64: contract (lhash.c:369)
Stanislav Mikhailenko wrote:
CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_ON);
SSLeay_add_ssl_algorithms();
SSL_load_error_strings();
ERR_remove_state(0);
ERR_free_strings();
EVP_cleanup();
CRYPTO_cleanup_all_ex_data();
ENGINE_cleanup();
CONF_modules_unload(1);
This code
Steve West wrote:
I get the message unsupported methods from ssl_accept() bio_read. I
get this message from my server when I try to connect using openssl
s_client. Any suggestions?
Steve
It is possible to implement STARTTLS with OpenSSL.
This is where you connect your
Steve West wrote:
I now get the message unsupported methods from bio_read. I get this
message from my server when I try to connect using openssl s_client. Any
suggestions?
Steve
Have you added options like -msg and -debug to your s_client invocation ?
Did you then post your data to the
Kyle Hamilton wrote:
If SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE are returned, the
arguments *must* be *exactly* the same. This includes the data
pointed to by the buffer. There is a way to set a mode on the SSL
connection to allow a moving buffer, but that's it. SSL will not
buffer the
Andrew Sumner wrote:
The client can then send messages to the server worker process using
SSL_write, and the worker receives them ok. However, when the worker
sends something to the client, nothing comes through - SSL_read fails.
In summary, is there any way of closing an SSL session on a
David Schwartz wrote:
Jason Pettiss wrote:
I have a server which reads/writes a socket independently; that is to
say, at the same time (not a request-response model). I note in the
FAQ it says I must not allow multiple threads to use an SSL connection,
so clearly if my sockets are blocking I
David Schwartz wrote:
Darryl Miles wrote:
But this flag (while documented to the contrary) does nothing inside
libssl. So yes the documentation says you should set it, prove to me
that OpenSSL behaves in a different way because you set it.
One of the biggest downsides of open source
David Schwartz wrote:
Darryl Miles wrote:
This is how everything else works, it's odd to say it's somehow a limitation
of OpenSSL that it works the same way everything else works. Try to read to
a string in one thread while you write to it from another. The general rule
of thread
Victor Duchovni wrote:
SSL is a state-machine, not a pipe. Reading data may require writes, and
writing data may require reads (e.g. when re-negotiating). If you want
to write and read as data arrives in either direction, don't block, and
enter the state machine to move data in either direction
The issue is down to the OpenSSL API thread-safety rules (which are
dictated to by the internal design of OpenSSL).
I covered those thread-safety rules in a previous posting.
Yes the common application design pattern for full-duplex SSL streams is
to only ever have one thread doing the
David Schwartz wrote:
Darryl Miles wrote:
I do not believe the SSL_write() call is allowed to access the
underlying BIO/kernel-socket to read in more data. I think SSL_write()
is allowed to process any data already read into buffer (from kernel to
OpenSSL library internal buffer
Kyle Hamilton wrote:
My understanding is that if SSL_ERROR_WANT_WRITE happened with
SSL_read(), the next SSL_read() would actually call write() to make
the forward progress.
Yes that is possible, as the data for the write is already inside
OpenSSL library. Infact all the write to BIO/kernel
Konstantin Ivanov wrote:
I am developing a server application which is based on Windows IO
Completion ports which basically means that the reads and write to the
socket are asynchronous. This also means that I cannot use the SSL_read
and SSL_write functions which are tied to the socket fd if
after wakeup from sleep ? What do you mean ?
Do you mean you used an API like poll() or select() to put the thread to
sleep and then it wakes up and the socket readability was indicated ?
If so please post an outline of the code your sleep/wake mechanism you
are using.
Do you mean your
Parimal Das wrote:
Its the second case Darry,
Here the 'sleep' is Operating System Sleep mode induced by closing the
lid of laptop.
After opening the laptop, when the system wakes up,
My application is always hanging at the same place.
It is possible there is something specific OSX does in
Mark wrote:
There is one added complication in that the protocol is a datagram
protocol at a
higher level (although it uses TCP). I am concerned that the whole
protocol could
block if there is not enough data to encrypt a whole outgoing message
but the peer cannot
continue until it gets the
Ger Hobbelt wrote:
It is presumed that every SSL_write() requires a flush (at TCP level this
mechanism is called a Push). This basically means the data needs to flush
to the reading API at the far end on exactly the byte boundary (or more)
data than you sent. This mean you have a guarantee to
Please provide a simple testcase program exhibiting the memory leak.
Please try with the most recent OpenSSL release. There are no known
issue with normal usage, however some recent patches have been added for
theoretical failure path memory leaks.
It is possible for memory leaks to still
Victor Stinner wrote:
I'm trying to fix a bug in Python which is specific to OpenSSL 0.9.8m. The
problem is in a FTP test using a blocking socket (client) and a non blocking
socket (server). There are different tests, some tests use a timeout of 2
seconds on the client socket.
Pseudo-code of
Claus Assmann wrote:
It should probably be
ssl_errno = SSL_get_error(ssl, rc);
Ah yes you could be correct on that, please consult the SSL_get_error()
documentation for correct usage.
but even then I get SSL_ERROR_SYSCALL and errno=EBADF using sendmail
8, while previously it
Would you please confirm to the list the name of the Python module, the
download site for it and the version you are currently working with.
This just helps up provide assistance to this same question in future.
Please read up on this recent thread. I do not know anything about
Python
Long info because I fear the Python module maybe misunderstanding what
SSL_shutdown() actually does and why it exists. Which in turn mean that
users of the Python module also misuse it (sandcastles in the sand and
all that).
Antoine Pitrou wrote:
While testing Python's SSL support with
Antoine Pitrou wrote:
These issues are tracked together at http://bugs.python.org/issue8108 ,
because they both appeared when someone tried OpenSSL 0.9.8m.
I have read through the discussion first I'd like to confirm the
scenario for the errno==0 situation through particular sequence of
Antoine Pitrou wrote:
What I'm specifically interested in is SSL_ERROR_SYSCALL with errno==0.
I have investigated this issue of -1/SSL_ERROR_SYSCALL with errno==0.
From the SSL_get_error(3) man page:
SSL_ERROR_SYSCALL
Some I/O error occurred. The OpenSSL error queue may contain more
Antoine Pitrou wrote:
Well, in our case, and unless I'm mistaken,
ret == -1, ERR_get_error() == 0 and then errno (the Unix errno) == 0.
SSL_shutdown() by virtue of its unique mechanic you will not see ret ==
0 (in the way the SSL_get_error man page describes) since that has a
different and
Matthew Allen wrote:
if (Ssl)
{
SSL_shutdown(Ssl);
SSL_free(Ssl);
}
Yes as the other writer says, you may need to close out the BIO (which
is the thing holding the socket descriptor/handle). So the Bio object
you created you may need to clean
I thought they were the same thing ? Checkout http://www.zlib.net/
notice the Authors credited and the authors of Gzip http://www.gzip.org/
and deflate methods.
Alternatively you can use the BIO implementation for doing compression
as a template to write your own compression by bolting in
I think the FAQ point is trying to highlight that the GZIP format as-is
was designed for single file compression (a compress replacement). So
therefore the extra tiny header at the start of the GZIP data that you
find in *.gz files is not necessary for zlib and streaming compressors.
Also
Dr. Stephen Henson wrote:
Using the low level APIs had been strongly discouraged for some time.
This is an unfortunate choice.
OpenSSL used to have very usable digest and encryption lowlevel
routines. Such that an application could pick and choose to make use of
just a few routines.
I
Amit Ben Shahar wrote:
Does anyone know if a buffer passed to ssl_write (or any other method)
must remain valid (i.e not freed) for any period.
for example, if i have this code:
// allocate buffer
char* tmpBuff = (char*)malloc(1024);
// .. some code to put data in buff
// write
Amit Ben Shahar wrote:
The documentation specifies that SSL_ERROR_ZERO_RETURN is returned if
the transport layer is closed normally.
My question is, how should i handle this return code?
specifically should i call SSL_free normally to free resources, or are
resources already freed?
Yes you
Jakob Bohm wrote:
I believe this is an unfortunate reading of the RFCs. Fundamentally,
the SSL3/TLS protocols do not tie the availability of a cipher suite to
the version of the protocol document which was current when it was
introduced. The fact that the most common cipher suites are defined in
Jakob Bohm wrote:
On 04-10-2010 21:10, Victor Duchovni wrote:
On Mon, Oct 04, 2010 at 10:37:55AM -0400, Jeff Saremi wrote:
Does BIO support 64 bit IO (large files)? If so would the rest of
OpenSSL (such as the ssl itself) support those BIOs?
I configured the build with 64bit support and
Marek Marcola wrote:
SSL protocol differs in server_key_exchange packet
(with may be used not only for export restriction).
This requires temporary RSA key in context.
If you add to server initialization routine something like:
RSA *rsa;
Marek Marcola wrote:
Many applications generate a static one, can the same exact key be
re-used without any security considerations for unrelated sessions ?
Should a highly secure application generate a new one for every connection?
In this case (export restriction) generating RSA 512 bit key
Henrik Thuermer wrote:
If we receive some data we process it via one BIO_write call followed by
SSL_read calls until the call to SSL_read fails with SSL_get_error() ==
SSL_ERROR_WANT_READ or SSL_read returns no more data (SSL_ERROR_WANT_WRITE
is also handled correctly - I hope). Then we stop
Girish Venkatachalam wrote:
But did you factor the fact that an SSL renegotiation
or handshake can happen anytime during the
conversation?
Thats not strictly true, the receiving end does have a tiny bit of
control over when to process it. From recent discussion in this list my
Henrik Thuermer wrote:
At 15:20 17.07.2006 -0700, you wrote:
Yes, I know that. But in our case there is no renegotiation: SSL_write
never returns an error and if the SSL_read return value is below zero
SSL_get_error returns only WANT_READ. In that case there was never someting
in the outgoing
Here is another interesting one,
What I mean by a null write is allow the write machinery to flush and
emit outstanding data or deal with renegotiation requests that need
write operations to be performed but I wont want to send any new
application data ?
The man page for SSL_write()
Dmitriy Khodos wrote:
The function fails if the PID does not match. However,
since PID is obtained by calling getpid(2), under Linux it is going to be
different in different threads.
It depends which version of Linux you are running and which thread
implementation you have at runtime. The
Marek Marcola wrote:
[EMAIL PROTECTED] writes:
For the moment, i have a kind of supervisor which,
accept a connection, read some datas on the socket and
then start the process which is able to handle this
datas. ( using createprocess/execv). The socket's
handle is shared to this process and
Gayathri Sundar wrote:
Thanks Richard..but I was thinking only SSL RECORDS with Record Type APP
DATA
Contain application data!!! If I can ensure that only complete SSL Records
of Type
Handshake, Change cipher spec, and Alerts are given to OpenSSL, it can
process it rite?
This way how can
Bu Bacoo wrote:
Instead of modifying the BIO, I've also tried to set it's socket to
non-blocking mode. Same result, BIO_do_connect returns -1
BIO* pBio = BIO_new_connect((char*)conn.c_str());
BIO_socket_nbio(BIO_get_fd(pBio,NULL), 1);
BIO_do_connect(pBio); //returns -1
On 7/22/06, Bu Bacoo
Girish Venkatachalam wrote:
I don't know what is supposed to happen in theory, but
in practice I have found select() to be quite a
disaster in informing me when a socket becomes
writable. I have seen this on both Linux and FreeBSD.
select() is very useful and an elegant solution for
Marek Marcola wrote:
For example:
/* check socket error state - only if val == 0 after this call
* connection is properly established.
*/
len = sizeof(int);
if (getsockopt(fd, SOL_SOCKET, SO_ERROR, (void *) state, len) 0) {
goto err;
Friedrich Dominicus wrote:
According to threads(3) and also mentioned in network security with
OpenSSL from O'Reilly one has to provide callback functions for using
OpenSSL with threads.
The callbacks abstract the thread locking/mutex requirements inside
OpenSSL library to manipulate its
GUIRY Aroun wrote:
If I send a new packet from the client I can read the missing packets,
but not the new one.
I use non-blocking sockets.
Are you on linux ?
Can you run 'strace' or 'strace -p pid' and paste the relevant parts
of the output to the list.
Darryl
GUIRY Aroun wrote:
Thanks Darryl for your help.
I wrote that when I send a new packet from the client I can read the
missing
packets, but not the new one But in fact I can read the missing packets
and a part of the second packets.
Here is the trace. I send a trame of 10 bytes from the
Jon Perkin wrote:
Apologies if this is the wrong place for my query, as I'm not sure how to
track down whether my problem lives in core OpenSSL, in the Perl OpenSSL
modules, or in the LWP modules I'm trying to use them via.
Even if I did know the answer, your not going to get it by posting the
Mark wrote:
I think it would be helpful for me. If we need to prevent calling
SSL functions on the same object (i.e. SSL_read() and SSL_write())
from different threads then I would think that OpenSSL would not need
any internal synchronisation, unless it creates its own threads
internally.
I would guess anything within the last few years.
Lets take a system:
$ uname -a
Linux me.foobar.com 2.6.18 #1 SMP Sun Sep 24 21:09:55 BST 2006 x86_64
x86_64 x86_64 GNU/Linux
$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr
Marek Marcola wrote:
I've one query regarding SSL_write call provided by OpenSSL
library. The SSL_write could return with READ_ERROR or WRITE_ERROR
with partial writing of data. While re-attempting to send the data
once again SSL_Write expects the same arguments as that of the
previous one.
Sergey S. Levin wrote:
Why the data transfer speed of the OpenSSL client and server is nearly
10 times slower then when using the regular sockets? The code of the
standard samples of client and servers are used.
Are you also measuring the time it takes to setup the SSL connection or
are you
Sergey S. Levin wrote:
1. If i use FileZilla and SSL connection - it works on 100% of speed.
I dont know what FileZilla is, but which SSL implementations is used and
what key exchange protocol and what symmetric cipher did it choose ?
2. The processor load is just 5% so, this should not
Victor Duchovni wrote:
On Wed, Mar 07, 2007 at 03:34:31AM +0100, Vladislav Marinov wrote:
This is why I want to extract information about who is the hostname/IP
participating in the TLS handshake and compare it to the Common Name
field in the certificate.
This makes no sense, the client could
brajesh tiwari wrote:
Can some one please tell me what may be the problem here.
Thank you very much.
I think the problem may be a bug in your program.
HTH
PS - How do you seriously expect help in debugging your program from a
mailing list. Yes, it is valid for your application code to
So if you actually read the Wikipedia page (a previous poster has kindly
pointed you at) you should end up at:
http://tools.ietf.org/html/rfc2440#section-6
Darryl
Jeremiah Martell wrote:
On 7/5/07, Carlo Milono [EMAIL PROTECTED] wrote:
Radix-64 - if you want the PGP/GPG stuff.
See:
David Lobron wrote:
2007-07-26 20:18:04.375 [3317] GS: Got response from sendDataPending
2007-07-26 20:18:04.376 [3317] GS: Calling poll with timeout 6
2007-07-26 20:18:04.376 [3317] GS: Checking poll results
2007-07-26 20:18:04.376 [3317] GS: calling SSL_write on buffer of length
1281
Here is my take on it, I maybe completely off target but here goes.
David Lobron wrote:
21:08:30.190534 CLIENT.39044 SERVER.8443: P 844:1025(181) ack 4827 win
65535 nop,nop,timestamp 173778704 299402767 (DF)
This is 181 bytes sent to SERVER. Presumably the GET x and
headers all in
Shaw Graham George wrote:
The sequence of events goes like this:
1. The SSL handshake proceeds as normal.
2. The client puts an HTTP request
3. The server gets the HTTP request
4. The client then executes an (unexpected) SSL shutdown
5. The server puts the HTTP response
Here I might
Prabhu S wrote:
Is this a memory leak. If I run the client application under stress, I
run into issues with available swap size reducing to zero( free -m
command) ..I have resolved significant application memory leak. Still I
run into problem in stress test.
Any suggestions?
There is a
Shaw Graham George wrote:
The problem is that, on Windows at least, my server doesn't appear to
get the SSL shutdown notify packet, for some reason. So, if that is
to be expected, I'm looking for an alternative way of detecting the
closure.
I've now tested it on Linux, and the existing code
Shaw Graham George wrote:
Sure.
1. The server receives the HTTP request, using SSL_read() and
SSL_pending(). The request contains a Keep-Alive request.
2. The server writes the data out to another process.
3. The server then it sits on an event handler that multiplexes a
select() (or
Steffen DETTMER wrote:
this is an interesting topic. I hope it is OK to bother again
even if off-topic.
This topic has been covered before on this list. I do not share David's
beliefs on this matter, the select() readability and writability
indicators are indeed sticky.
That is they never
David Schwartz wrote:
That is not only not implemented by any known implementation but quite
literally impossible. Please tell me what implementation guarantees that a
TCP 'write' after a 'select' hit for writability will not block.
This is no use, your asking me for references and I'm asking
Please take a look at this thread for assistance.
http://www.mail-archive.com/[EMAIL PROTECTED]/msg22972.html
In your case manually run these 3 commands:
cd apps
gcc -DMONOLITH -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT \
-DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -O3 -Wall
Florian Schnabel wrote:
spider:/opt/openssl-0.9.8e-etch/apps# gcc -DMONOLITH -I.. -I../include
-DOPENSSL_THREADS -D_REENTRANT \
-DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -O3 -Wall \
-DMD32_REG_T=int -DMD5_ASM -c -o s_server.o s_server.s
s_server.s: Assembler messages:
Darryl Miles wrote:
Florian Schnabel wrote:
spider:/opt/openssl-0.9.8e-etch/apps# gcc -DMONOLITH -I.. -I../include
-DOPENSSL_THREADS -D_REENTRANT \
-DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -O3 -Wall \
-DMD32_REG_T=int -DMD5_ASM -c -o s_server.o s_server.s
s_server.s
Florian Schnabel wrote:
i tried both the etch version and the stock version of openssl 0.9.8e
and got exactly the same error
comment out your FD_ZERO(), FD_SET() and FD_ISSET() macros from the file
s_server.c this will confirm the problem is with glibc, then please file
a bug report with
Maybe they can, but you wont get much response from me by being too lazy
to start a new thread with your Compose New Mail function, as opposed
to picking a historic message at random and using the Reply To Message
function.
Have a nice day!
The Posting Police
Paul Simon wrote:
I have a
Dr. Stephen Henson wrote:
Our goal is really to save and restore the cipher state of an RC4 cipher
context. It does not seem to be possible to ask an EVP_CIPHER_CTX to save
and restore it's internal state. Any ideas would be welcomed?
Here here! I feel your pain. Search the
I have some code what was originally doing:
HMAC_CTX ctx;
HMAC_Init(ctx, key, keylen, EVP_md5());
HHAC_Update(ctx, data, datalen);
HHAC_Update(ctx, moredata, moredatalen);
HMAC_Final(ctx, digest, digestlen);
This seems to work fine and valgrind indicates there are no memory
leaks, i.e.
Sorry to come at this thread a week later.
I can see both sides of the problem here, there are infact three
distinct modes of operation:
Non-Blocking: There is where the underlying socket descriptor is in
non-blocking mode. SSL API calls return -1 and set SSL_get_errno() to
allow for
Dow! Ignore my post.
My system openssl/hmac.h and the one of openssl-0.9.8b I am using have
different sized structures and part of my code (a sub-library) wasn't
building against it. Probably Fedora removing legally problematic code.
Darryl
Mikhail Kruk wrote:
It is unclear to me if Marek
thinks this problem is due to a library bug or simply that s_client
should be clearing SSL_MODE_AUTO_RETRY in its block socket use case for
that program. We all know that OpenSSL s_client has a command line
option to enable nonblocking mode so
Mikhail Kruk wrote:
I'm pretty confident that the fix (if it is feasible) is not going to
break any correct application code.
And I'm pretty confident that it is going to make app. engineer's life
easier.
My view comes from what is architecturally scalable by design which
makes it recursive
David Schwartz wrote:
My first reaction was that this is a bug in the library, but I
didn't feel
very strong about it and would have accepted that this is just a bug in
s_client. I like your argument about the library not having the right to
make 2 blocking calls unless retry is set and now I'm
David you are bringing completely unrelated issues into the situation.
David Schwartz wrote:
...SNIP...
One other point, I didn't mention threads to argue that if another
thread
steals your data, the operation will clearly block. I mentioned it to show
that it's impossible for
David Schwartz wrote:
No. That you cannot think of a way does not mean that no way exists.
WTF ! Is dark the absence of light, or is light the absence of dark ?
Please prove your way exists, there are enough poll/select
implementations available to inspect. Your words have no
Hello,
I am trying to work a full SSL shutdown (close notify sent and received
before closing the socket).
The situation:
* Am currently in established / active SSL state, with a working
connection.
* No shutdown notify has been received and we are being to instigate
the shutdown notify.
David Schwartz wrote:
David you are bringing completely unrelated issues into the situation.
No, you are failing to understand my argument.
A Kernel does its job of arbitration like this on a shared/duped file
descriptor that both processes have as fd=4:
Thread/Process A
Marek Marcola wrote:
Your next argument will be:
if you do select() and space shuttle is flying ...
I am in complete agreement here.
The crux of the situation is that I'm (we're) saying its possible to
have working OpenSSL blocking mode that uses a blocking socket which
conforms the to
David Schwartz wrote:
David Schwartz wrote:
I hate to be rude, but do you understand *anything* about programming to
standards? The 'select' and 'read' functions are standardized, as is
blocking and non-blocking I/O. You have the guarantees specifically
enumerated in the standard and
David Schwartz wrote:
On Thu, 22 Jun 2006, David Schwartz wrote:
Bingo! And work may or may not translate into application data.
I thought that a recv on a blocking socket returns immediately after it
was able to do some work, no matter whether it resulted in receiving any
actual
Alain Damiral wrote:
I'm wondering if it would not be highly appropriate to have an
'SSL_select' call defined by OpenSSL to have all operations on sockets
fully encapsulated and allow to reach the desired behaviour without
short-circuiting the layer approach... (it would provide similar
David Schwartz wrote:
I don't get it.
DS
Ah, finally something concrete.
Hey thats ok; sit back and relax. I'm sure a patch is on its way.
Darryl
__
OpenSSL Project
Darryl Miles wrote:
All you have to do inside OpenSSL is know if your underlying IO mode is
blocking or non-blocking and set a flag everytime to you enter a
high-level call from the application context.
Then _BEFORE_ you issue any low-level I/O you test to see it your
low-level IO
I would like to give OpenSSL the first part of the initial SSL connect
negotiation.
This is because my application has already read it from the socket
(which was in plain text), but then I'm happy for OpenSSL to use the
socket directly after that.
Would creating a temporary BIO containing
1 - 100 of 122 matches
Mail list logo
