I've uploaded a new patch that checks the buffer overflow condition in the
native wrap and unwrap. The testSelfInteraction test of
org.apache.harmony.xnet.provider.jsse.SSLEngineImplTest now gets a bit
further, though now fails reading on the second iteration of the wrap/unwrap
data exchange loop.
On 15/09/2010 15:15, Catherine Hope wrote:
I've uploaded a new patch for SSLEngine that passes in the direct buffer
address to the wrap/unwrap natives and then updates the byte buffer
positions after the call. The handshake test now completes the handshake
and application data can be passed bet
I've uploaded a new patch for SSLEngine that passes in the direct buffer
address to the wrap/unwrap natives and then updates the byte buffer
positions after the call. The handshake test now completes the handshake
and application data can be passed between the server and client. I still
need to d
On 13/09/2010 19:48, Catherine Hope wrote:
Hi Oli,
I've uploaded a new patch to
https://issues.apache.org/jira/browse/HARMONY-6627 that gets a bit further
with the handshake. Currently I can get back the initial handshake data
from the client, get the server to accept this and then request a
ce
Hi Oli,
I've uploaded a new patch to
https://issues.apache.org/jira/browse/HARMONY-6627 that gets a bit further
with the handshake. Currently I can get back the initial handshake data
from the client, get the server to accept this and then request a
certificate from the client but then the testcas
On 10/09/2010 11:58, Catherine Hope wrote:
Hi Oli,
I've also been looking at how the SSLEngine may be implemented in OpenSSL
Great!
and am struggling to to obtain the handshake data to return to the other
side without sending it across an actual connection. I've been working with
an open SS
Hi Oli,
I've also been looking at how the SSLEngine may be implemented in OpenSSL
and am struggling to to obtain the handshake data to return to the other
side without sending it across an actual connection. I've been working with
an open SSL bio pair which, according to the manual, enables an app
An update on where I am so far with this. The implementations of the
SSLSocket, SSLSession, SSLContext and their related classes are
complete. The tests for these classes all pass for me now with my latest
set of changes. I've started removing a lot of the classes that have
been replaced by ca
On 20/08/2010 20:59, Oliver Deakin wrote:
On 20/08/2010 18:26, Catherine Hope wrote:
I've been working on SSLSocketInputStream, which currently reads
bytes one
at a time. I've attached a patch to
https://issues.apache.org/jira/browse/HARMONY-6627 with an
implementation of
the read methods u
On 20/08/2010 18:26, Catherine Hope wrote:
I've been working on SSLSocketInputStream, which currently reads bytes one
at a time. I've attached a patch to
https://issues.apache.org/jira/browse/HARMONY-6627 with an implementation of
the read methods using OpenSSL calls and replaced the available
I've been working on SSLSocketInputStream, which currently reads bytes one
at a time. I've attached a patch to
https://issues.apache.org/jira/browse/HARMONY-6627 with an implementation of
the read methods using OpenSSL calls and replaced the available call to use
ioctl.
Currently when I run the x
Hi Chris,
On 19/08/2010 21:40, chris.g...@k-embedded-java.com wrote:
Hi Oliver,
- Set a single global set of native RNG callback functions that then
figures out (somehow) who made the original call into the OpenSSL
natives and uses the appropriate SecureRandom implementation. This
would be tr
Hi Oliver,
>> - Set a single global set of native RNG callback functions that then
>> figures out (somehow) who made the original call into the OpenSSL
>> natives and uses the appropriate SecureRandom implementation. This
>> would be tricky, but might be possible. I imagine we could look up the
>>
On 16/08/2010 13:47, Oliver Deakin wrote:
I've been making steady progress with this implementation so far but
I've hit a snag. The Java spec allows users to specify a SecureRandom
implementation when creating connections, and there can be different
SecureRandom implementations for different
Thanks Cath, that will be a great help! I've only been testing on
Windows so far, so it will be very useful if you can check how things
are looking on Linux as we progress.
Thanks for the heads up on the Java classes - I've just rebuilt and see
the build failures too now. I think the problem
Hi Oli,
I can help you work on this. I've created a JIRA
https://issues.apache.org/jira/browse/HARMONY-6627 to attach patches to. So
far I've had to make a few changes to build on linux and currently the Java
classes don't build from scratch.
Best wishes,
Cath
I've been making steady progress with this implementation so far but
I've hit a snag. The Java spec allows users to specify a SecureRandom
implementation when creating connections, and there can be different
SecureRandom implementations for different connections in the same VM
instance. Howeve
I've made a little progress with this in my local workspace, but I'd
like to get the work out into the community so everyone can see it. To
this end I've created a temporary branch [1] under which I will be
committing changes as I go. I figured this was the easiest thing so I
can reorganise th
Hi Chris,
On 19/07/2010 21:08, chris.g...@k-embedded-java.com wrote:
Hi Oliver,
I'm currently investigating the possibility of implementing a JSSE
provider wrapping OpenSSL.
This would be a great idea, but don't underestimate he task. IIRC there is
at least one abandoned project on SourceFor
Hi Oliver,
> I'm currently investigating the possibility of implementing a JSSE
> provider wrapping OpenSSL.
This would be a great idea, but don't underestimate he task. IIRC there is
at least one abandoned project on SourceForge to do something similar. I
also know of at least one proprietary (c
20 matches
Mail list logo
