On Tue, Nov 14, 2000 at 07:28:03PM -0800, Dan Kegel wrote:
It should be possible to implement something close to what you
describe at URL http://www.kegel.com/ssl/api.html on top of the
current SSL API with new SSL_get_error return values addeed, using
either a BIO pair or memory BIOs.
But
At 09:21 PM 11/15/00 -0800, Dan wrote:
My API proposal was meant to generate discussion. I realize it's not an
especially practical direction to move OpenSSL in. Does the idea of
an event-driven SSL API appeal to anybody, at least in the abstract?
Yes.
Geoff Thorpe wrote:
On Tue, 14 Nov 2000, Dan Kegel wrote:
I don't think we need nonblocking crypto; it would be enough to be able
to shunt the crypto off into another thread. That's what my API proposal
was about.
I think that misses the entire point of why a form of async public-key
On Mon, Nov 13, 2000 at 07:16:39PM -0800, Dan Kegel wrote:
Nonblocking network I/O is tricky with the current API, but doable.
I've got working code for that, and there are good examples now.
Nonblocking crypto is another matter; it would be a real pain, and
there are no examples showing
Bodo Moeller wrote:
On Mon, Nov 13, 2000 at 07:16:39PM -0800, Dan Kegel wrote:
Nonblocking network I/O is tricky with the current API, but doable.
I've got working code for that, and there are good examples now.
Nonblocking crypto is another matter; it would be a real pain, and
there are
I don't think we need nonblocking crypto; it would be enough to be able
to shunt the crypto off into another thread. That's what my API proposal
was about.
Insufficient for hardware crypto devices.
__
OpenSSL Project
On Tue, 14 Nov 2000, Dan Kegel wrote:
I don't think we need nonblocking crypto; it would be enough to be able
to shunt the crypto off into another thread. That's what my API proposal
was about.
I think that misses the entire point of why a form of async public-key
crypto might be
I'd say that has very little to do with BIOs and more to do with the
fact that the public key API has no concept of "non blocking operations"
and this has filtered down to the SSL API.
It may be possible to actually do what you want through some of the SSL
state callbacks but I haven't
So the question: how many people would want non blocking I/O support? If
no one or hardly anyone wants or needs it then there isn't a lot of
point. However if there's considerably demand it would be worth looking
into.
if it doesn't affect the API then i suppose, then the blocking I/O is
Richard Levitte - VMS Whacker wrote:
From: Dan Kegel [EMAIL PROTECTED]
dank BIO's should have been a well-separated layer, not an integral
dank part of OpenSSL.
I'm not sure I understand that argument. BIO's *are* separate, in
their own "module", if you wish to express it that way.
From: Dan Kegel [EMAIL PROTECTED]
dank BIO's should have been a well-separated layer, not an integral
dank part of OpenSSL.
I'm not sure I understand that argument. BIO's *are* separate, in
their own "module", if you wish to express it that way. They just
happen to be used by OpenSSL as
Dan Kegel wrote:
Dr S N Henson wrote:
The revised OpenSSL ASN1 code will eventually have support for I/O based
operations in addition to the current memory based operations which need
to have the entire structure in memory (tricky if its a 1Gb structure on
tape).
Doing
Dan - I agree with you whole heartly and this fact set me back tremendously. When I
looked at the code I was really disappointed that there appeared to be way too much
being done in the bowels of the api - and stuff that frankly does not belong there.
So the question is - how do we fix it?
Dr S N Henson wrote:
Another general ASN1 question.
The revised OpenSSL ASN1 code will eventually have support for I/O based
operations in addition to the current memory based operations which need
to have the entire structure in memory (tricky if its a 1Gb structure on
tape).
Doing
14 matches
Mail list logo
