summaryrefslogtreecommitdiffstats
path: root/test
diff options
context:
space:
mode:
authorNick Hudson <nick.hudson@isode.com>2013-01-24 12:16:40 (GMT)
committerNick Hudson <nick.hudson@isode.com>2013-01-29 11:41:19 (GMT)
commitebef58ff180acc9d760ea0137216ef6b4f16a9b6 (patch)
tree658b2d513cd993d23e5d56ff0b3f9ae6c0132fcb /test
parent37730a9bfe2e31ae0d7adc9cd7247d1e15d0f6da (diff)
downloadstroke-ebef58ff180acc9d760ea0137216ef6b4f16a9b6.zip
stroke-ebef58ff180acc9d760ea0137216ef6b4f16a9b6.tar.bz2
Changes to Stroke to make it more amenable to porting to other platforms
Two things - the implementation of JavaTrustManager was attempting to instantiate a TrustManagerFactory with a hard-coded name of "PKIX", which doesn't work on Android. So instead of that, we ask for the TrustManagerFactory's default algorithm - which for the standard JRE still appears to be "PKIX", but which for Android may be something else. - the "hack" which had been in place to force the SSLEngine to perform a TLS handshake has been removed. Calling "SSLEngine.beginHandshake()" is not guaranteed to make the SSLEngine perform the TLS handshake, which it typically only does when it is told to wrap some data from the client. The earlier version of JSSEContext provoked this by asking it to send a "<" character, and then removing the leading "<" from whatever Stroke happened to send next. It turns out that you can force the handshake to start by telling the SSLEngine to wrap 0 bytes of data from the client, and so this change removes the hack, and instead calls "wrapAndSendData()" with an empty buffer as soon as the SSLEngine has been created. Test-information: Ran XMPP client that uses TLS and verified that everything still works as expected. Change-Id: Ie08d76bd2f5a743320a59bad62a09c1f215c48d6 Signed-off-by: Nick Hudson <nick.hudson@isode.com>
Diffstat (limited to 'test')
0 files changed, 0 insertions, 0 deletions