On Tue, May 26, 2009 at 4:46 PM, Victor Duchovni
<victor.ducho...@morganstanley.com> wrote:
> On Tue, May 26, 2009 at 01:13:33PM -0700, Kyle Hamilton wrote:
>
>> You're looking for a BIO_s_mem.
>
> No, he is looking for BIO_new_bio_pair(3) and SSL_set_bio(3).
And this is where I'm running into confusing bits of information.
Bluntly, the documentation that I can find is nearly useless.
Let me put it this way, in pseudocode of how I would like to interact
in my perfect world:
readfunc(int fd)
{
/* entry on a "can read" event from the select/poll/etc call */
len = recv(fd, &buffer, sizeof(buffer));
if(IsSSL(fd)) {
if(have_crypted_buffer_already)
merge_buffer(buffer, encrypted_buffer);
switch(SSL_decrypt(context, buffer, &decr_buf, &dlen)) {
case SSL_NOTENOUGHDATA:
buffer_encrpyted_read(fd,
buffer, len);
case SSL_GOTDATA:
buffer_decrypted(fd, decr_buf, dlen);
if(dlen != len)
buffer_encrypted_read(fd, buffer+dlen, len-dlen);
case SSL_NEEDRENEG:
enqueue(fd,
get_ssl_reneg_data(context));
default:
break;
}
}
}
(or something..)
Basically, I don't really want any calls to require more than a
context that needs to be maintained - I don't want to hand my data off
to the API and have to come back to it at some arbitrary later time,
having it buffered and/or queued by mechanisms built into the openssl
api. I expect the API to do one thing and one thing only: provide me
the necessary information to handle an SSL connection. Not handle it
for me.
Not sure if I'm asking this well...
-Aaron
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
