This commit adds the modules smack-omemo and smack-omemo-signal.
smack-omemo is licensed under the Apache license like the rest of the smack project.
smack-omemo-signal on the other hand is licensed under the GPLv3.
Due to the fact, that smack-omemo is not of much use without smack-omemo-signal,
the OMEMO feature can currently only be used by GPLv3 compatible software.
This may change in the future, when a more permissively licensed module becomes available.
Fixes SMACK-743.
In case the server provided nonce contained one or more equals
characters ("=") the part.split("=") call would return more then the
expected two key/value parts. Hence we simply use part.split("=", 2).
Also made the unit test check for this case.
Fixes SMACK-755
I'm not sure why i've put the removeAsyncStanzaListener() call into
the finally block. If callback.processStanza(Stanza) takes a long
time (or even blocks), then it would appear to the "no response"
handling Runnable as if there was no response, when in fact there was
one.
instead of an EntityFullJid, because according to XEP-0045 § 7.8.1.:
"The <room@service> itself MUST then add a 'from' address to the
<invite/> element whose value is the bare JID, full JID, or occupant
JID of the inviter …"
Fixes the following exception thrown if the user had entered a non-existend XMPP domain:
java.lang.IllegalArgumentException: Must provide at least one InetAddress
at org.jivesoftware.smack.util.dns.HostAddress.<init>(HostAddress.java:55)
at org.jivesoftware.smack.util.dns.DNSResolver.lookupHostAddress(DNSResolver.java: 56)
at org.jivesoftware.smack.util.DNSUtil.resolveDomain(DNSUtil.java:209)
at org.jivesoftware.smack.util.DNSUtil.resolveXMPPServiceDomain(DNSUtil.java:136)
at org.jivesoftware.smack.AbstractXMPPConnection.populateHostAddresses(AbstractXMP PConnection.java:626)
at org.jivesoftware.smack.tcp.XMPPTCPConnection.connectUsingConfiguration(XMPPTCPC onnection.java:556)
at org.jivesoftware.smack.tcp.XMPPTCPConnection.connectInternal(XMPPTCPConnection. java:888)
at org.jivesoftware.smack.AbstractXMPPConnection.connect(AbstractXMPPConnection.ja va:377)
Thanks to Grigory Fedorov for reporting.
Before this, if there was a stream error response by the server to our
stream open, that error response would only be handled in the reader
thread, and the user would get a message like:
"org.jivesoftware.smack.SmackException$NoResponseException: No
response received within reply timeout. Timeout was
5000ms (~5s). While waiting for SASL mechanisms stream feature from
server"
while the server may actually sent something like
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
id='6785787028201586334'
from='jabbim.com'
version='1.0'
xml:lang='en'>
<stream:error>
<policy-violation xmlns='urn:ietf:params:xml:ns:xmpp-streams'>
</policy-violation>
<text xml:lang='en' xmlns='urn:ietf:params:xml:ns:xmpp-streams'>
Too many (2) failed authentications from this IP
address (1xx.66.xx.xxx). The address will be unblocked at 04:24:00
06.01.2017 UTC
</text>
</stream:error>
</stream:stream>
It was necessary to change saslFeatureReceived from SmackException to
XMPPException in order to return the StreamErrorException at this sync
point. But this change in return required the introduction of a
tlsHandled sync point for SmackException (which just acts as a wrapper
for the various exception types that could occurn when establishing
TLS). The tlsHandled sync point is marked successful even if no TLS
was established in case none was required and/or if not supported by
the server.
