| Age | Commit message (Collapse) | Author |
|---|
|
|
|
The JavaCertificate class functionality copies that found in Swiften's
OpenSSLCertificate class. One of the things that the class needs to
do is make available lists of SRV and XMPP names which are contained
in the certificate's subjectAltName extensions.
However, unlike OpenSSL, the standard Java classes don't provide
support for parsing the different types of subjectAltNames that we
want - what Java provides is a method to return the DER encoded
values, and so this change adds functions to the JavaCertificate class
to parse these values to extract Strings corresponding to either
XMPP or SRV subjectAltNames.
Also addressed a couple of comments from a previous patch.
Test-information:
Tested with certificate that has subjectAltNames for
- Service Name _xmpp-client.funky.isode.net
- Service Name _xmpp-server.funky.isode.net
- XMPP address funky.isode.net
- DNS Name funky.isode.net
And verified that all of these are parsed and made available with the
relevant methods.
Verified that a certificate which does NOT contain any of these
subjectAltNames is parsed with no errors (and the code reports no
matching subjectAltNames)
Signed-off-by: Nick Hudson <nick.hudson@isode.com>
|
|
Hopefully the changes speak for themselves.
Some feedback relating to JavaCertificate has not been addressed; that
will be done in a separate patch
Test-information:
Can still establish sessions with / without TLS
|
|
This change provides implementation for the previously empty
"readFromFile" method, which is based on the code inside Swiften's
ByteArray.readByteArrayFromFile().
Note that, as for the Swiften method, no errors are reported if an
attempt to read from a file fails; it just leaves the contents of the
object unchanged.
Some javadoc was also provided, especially noting that the various
String methods are only safe so long as you're working with UTF-8
Strings.
Test-information:
Existing Stroke unit tests still pass
Signed-off-by: Nick Hudson <nick.hudson@isode.com>
|
|
Note that TLS won't be enabled with this patch unless you uncomment the
change in PlatformTLSFactories. With that comment removed, then a new
CoreClient session will attempt to negotiate TLS if the server supports
it.
Further changes are required to support this properly, as there
appears not to be comprehensive support in the CoreClient class for
dealing with situations when the server's certificate is not acceptable.
There's also no support yet for setting up client certificates.
Further changes will also be needed (see below) to support full
parsing of subjectAltNames from server certificates.
Significant changes are as follows
- TLSProceed - FIXME comments removed
- JavaConnection - changed so that it reads bytes from the socket's
InputStream, rather than reading chars and then constructing a
String out of them from which a byte array is then extracted.
While this seemed to work for non-binary data (e.g. non-encrypted
XMPP sessions), it breaks when you start sending binary (i.e. TLS)
data.
- JavaTLSConnectionFactory - implemented
- PlatformTLSFactories - By having this return a JSSEContextFactory, then
this will cause the client to try TLS if possible. But because other
changes are needed to make this work properly, the current code still
returns null.
- JSSEContext - new class which uses an SSLEngine to handle TLS handshake
and subsequent encryption/decryption. This is the main substance of
the SSL implementation
Note the "hack" in here to cope with SSLEngine requiring that some data
be sent from the application before it will do a TLS handshake
- JSSEContextFactory - just creates JSSEContexts
- JavaCertificate - this wraps an X509Certificate and does *some* of the
parsing of a certificate to look for stuff that is expected when
verifying an XMPP server certificate (RFC 6120 and RFC 6125). Note that
the JDK classes for parsing certificates don't provide an easy way
to decode "OTHER" subjectAltNames, and so this implementation does
not find XMPP or SRV subjectaltnames from the server certificate. This
will need extra work.
- JavaTrustManager - obtains the server certificate from the TLS handshake
and verifies it. Currently the only verification done is to check that
it's in date. More work will be needed to perform proper validation
- Where necessary, Remko's copyright comments were changed from GNU to
"All rights reserved". Isode copyright notices updated to "2012"
Test-information:
Set up XMPP server with its own certificate, and checked that TLS gets
negotiated and starts OK (provided the server cert contains e.g. a DNS
subjectAltName matching its own name). Subsequent operation appears
to be as expected.
|
|
Also port the unit tests from Swiften.
|
|
This fixes crashes.
Test-information:
No more errors.
|
|
Updated class qualifier so it can be found by factory.
Test-information:
No more errors.
|
|
Also fixes the call in OutgoingAdHocCommandSession which was sending null data
and resulting in a crash when used in MLC.
Test-information:
No longer crashed MLC.
|
|
Also fixed up some incorrect Remko copyrights
|
|
Also made "Stanza" be an abstract class and had its ".toString()" include
the name of the subclass which is involved, so that the subclasses don't
have to do that themselves.
Also added null check to existing HostAddress.toString() method
Also fixed Remko copyright in Connector class
Test-information:
Stuff is displayed as expected in debugger.
|
|
Updates requisite classes in line with Swiften.
Also fixes bugs in the EventLoops not using handleEvent.
|
|
The JavaTimer class uses Thead.sleep() to wait a specified number of
milliseconds. Thread.sleep() requires the caller catch
InterruptedException, but in the original implementation, such an
exception would result in the code assuming that the specified time
had been reached.
So as things stood, if you e.g. set a timer for 60 seconds, then the
timer might generate its "onTick" signal before that 60 seconds had
elapsed.
This patch changes the code so that the method will wait until the
specified time has been reached.
The "milliseconds" parameters are also changed to "long", which is the
type used by the rest of the java library for millisecond values.
Added a bit of javadoc and a toString() method as well.
Note there is still a "FIXME" in the code which I've not addressed.
Test-information:
Tested in debugging setup; things seem to be working as expected.
|
|
Just to help with debugging
Test-information:
Values appear as expected when running inside Eclipse debugger
|
|
In trying to use the Event class I wasn't sure exactly what it was
doing so have added javadoc to try and make it clearer.
I also added "toString()" method to Event.java for debugging purposes.
Test-information:
"ant javadoc" works and info looks as expected.
Running in debugger now shows me info derived from "toString()" method
when I click on Event objects
|
|
Test-information:
Looks okay.
|
|
This patch addresses some review comments:
1. Updates the Javadoc.
2. Disallows arguments from being null - throws NullPointerException.
3. Updates each test to use its own DummyEventLoop.
Test-information:
Unit tests pass.
|
|
|
|
This patch ports the Adhoc commands from Swiften to Stroke.
It also ports their unit tests.
Test-information:
Unit tests pass.
MLC able to use the ad-hoc command fine.
|
|
This change adds a javadoc target to the build file for stroke, so
that you can do
% cd build/stroke
% ant javadoc
I have not updated any of the other build infrastructure (Makefile
etc.). Nor have I added any intelligence to the "javadoc" task so
that it won't bother creating documentation if the doc is already up
to date etc..
Note that I've not used the "linkoffline" directive, which means that
if you try to generate doc when the Oracle web pages are offline,
things may hang until the connection times out.
Test-information:
"ant javadoc" works as expected
"isodebuild clean -component=stroke" gets rid of any javadoc
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Also updates build.xml so the path to the xpp library can be specified,
rather than needing the same layout as my build tree.
|
|
|
Swift