profile
viewpoint

startedswift/swift

started time in a day

push eventswift/swift

Kevin Smith

commit sha 3d00d04ffbf40845058f6ede4da2592bb27a255d

Add copy/move ctors for JIDs Test-Information: Unit tests still pass. Change-Id: I4e5b63104e482a79a933f337082c579db7bb8cff

view details

Kevin Smith

commit sha 12d031cf8177fdec0137f9aa7e2912fa23c4416b

Accept certs with upper case entries Although we were doing the right thing with punycode (as far as I can see) for the IDNA entries, we were forgetting that the comparisons needed to be case insensitive (checked the RFCs). Now they are. Test-Information: Added unit tests for the three flows that were modified. Change-Id: Ib17ae3df66159f38339996580dc85a5d99356274

view details

push time in 9 days

startedswift/swift

started time in 12 days

issue closedswift/swift

Chat History

Is there anyway to recover chat history? If so, where is it stored when using the Windows app?

closed time in 13 days

anthonymetzler

issue commentswift/swift

Chat History

Hi Anthony. Swift doesn't store the chat history locally. In the future it'll allow access to the server-side (MAM) history storage, but at the moment you'd have to query the server through another mechanism.

anthonymetzler

comment created time in 13 days

startedswift/swift

started time in 13 days

issue openedswift/swift

APT Release key expired?

When trying to update my apt sources I get:

Err:17 https://swift.im/packages/debian/stretch release InRelease
  The following signatures were invalid: EXPKEYSIG 3A95CBB2E072AA5E Swift Package Maintainer <packages@swift.im>
Fetched 252 kB in 3s (78.6 kB/s)
Reading package lists... Done
Building dependency tree
Reading state information... Done
4 packages can be upgraded. Run 'apt list --upgradable' to see them.
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://swift.im/packages/debian/stretch release InRelease: The following signatures were invalid: EXPKEYSIG 3A95CBB2E072AA5E Swift Package Maintainer <packages@swift.im>
W: Failed to fetch https://swift.im/packages/debian/stretch/dists/release/InRelease  The following signatures were invalid: EXPKEYSIG 3A95CBB2E072AA5E Swift Package Maintainer <packages@swift.im>
W: Some index files failed to download. They have been ignored, or old ones used instead.

Trying to re-add the current key doesn't help.

Details:

pub   rsa4096 2015-11-11 [SC] [expired: 2019-11-28]
      0C4D 5A25 DBEF 212D 7E4F  BC4D 3A95 CBB2 E072 AA5E
uid           [ expired] Swift Package Maintainer <packages@swift.im>```

created time in 15 days

issue openedswift/swift

Chat History

Is there anyway to recover chat history? If so, where is it stored when using the Windows app?

created time in 16 days

startedswift/swift

started time in a month

startedswift/swift

started time in a month

issue openedswift/swift

documentation

Hi,

Do you guys have any documentation for the Swift xmpp client? I'm trying to determine what features it has (specifically if it supports XEP-0047) and how exactly I would go about initiating a file transfer but I can't figure it out.

created time in a month

fork dreamsxin/swift-1

Swift XMPP client and Swiften XMPP library

http://swift.im/swift

fork in a month

startedswift/swift

started time in 2 months

push eventswift/swift

Edwin Mons

commit sha 261ba8d8595ed8cb90f9c4feb1d6ef642942bcba

Remove std::endl from SWIFT_LOG calls The std::endl is now added by ~Log, but only for output to stderr or a log file. Calls to the Android logging system or manually set callbacks will not include the newline in the logging output. JIRA: SWIFT-430 Test-Information: Unit tests pass on Debian 9 Checked that running Swift with logging to stderr still had a newline. Change-Id: I096fdba78a3b8f87db2097951c28c528592183e8

view details

push time in 2 months

push eventswift/swift

Edwin Mons

commit sha 697ae6ae84512a744958b24118197ec7bfdbc1f0

Let handleNextEvent only handle a single event A batching mechanism was added to EventLoop::handleNextEvent, which caused it to be renamed to handleNextEvents. The problem with the batching was that it breaks EventLoop::removeEventsFromOwner: events already grabbed off the events_ queue for invocation could be removed, leading to issues in cases where two events were grabbed off the queue that referred to the same entity, the second event was a timer event, and the first event caused the timer to be stopped. The timer event would in this case be executed, leading to unexpected behaviour or crashes, as shown by the added unit test. Test-Information: Unit tests pass on Debian 9 and macOS 10.14. Benchmarked the eventloop on Debian and macOS, and did not notice a performance degradation. Transferred files using S5B and IBB, and checked there were no UI hangs. Transfer speed before and after the change are roughly the same. Change-Id: Ife7312f533e8f0976c2e8077d16e0b63fbac6eb1

view details

push time in 2 months

fork Neustradamus/swift

Swift XMPP client and Swiften XMPP library

http://swift.im/swift

fork in 2 months

push eventswift/swift

Tobias Markmann

commit sha 8230b23238b4d0ef0fcde01a799758558d502fa1

Update 3rdParty/CppUnit to version 1.14.0 This gets rid of std::auto_ptr usage and its deprecation warnings. Test-Information: Builds and tests pass on macOS. Change-Id: I299a0a8d9aa2ead15c933e83a2e3e53f84a4f5b7

view details

push time in 2 months

push eventswift/swift

Tobias Markmann

commit sha caca46ceedddd43c707e7eda9b4c765d61730ccb

Remove extra semicolons clang-trunk complained about them and ideally Swift would build without warnings. Test-Information: Builds find and tests pass. Change-Id: I1896befef0e65a980cc22f402e126aec8b56e71f

view details

push time in 2 months

push eventswift/swift

Tobias Markmann

commit sha 7a4d44dbc444b68b665535bb38847cfa48bfee3f

Pass down SDKROOT environment variable This is needed on macOS so that the running compiler knows what SDK to build against. Test-Information: Builds with system and custom build clang on macOS 10.14.6. Change-Id: I80a76937834d681c322bf36bfcb034565be9b2f5

view details

push time in 2 months

push eventswift/swift

Edwin Mons

commit sha e53dc1593d1789ac33b132214e957e947843d451

Re-enable logging in OpenSSLContext All logging in OpenSSLContext is now at debug level. Test-Information: Unit tests pass. Change-Id: I44d01ff23a05676a26ec547d6454dcb6883ebd88

view details

push time in 2 months

push eventswift/swift

Tim Costen

commit sha 7d79cd827fb17db7b03858b06f03c514d25cdfea

Clear internal error state after cert chain parse When parsing a PEM string containing a chain of certificates, createCertificateChain calls PEM_read_bio_X509 until it returns NULL (end of chain). But this will have set OpenSSL's internal error chain. Creating a new OpenSSL context has the side effect of clearing this chain, but if you are using a context which has already been created, the context sees that the error chain is set and fails. All that is needed is for createCertificateChain to clear the OpenSSL error chain before returning. JIRA: LINK-1868 Change-Id: Ife2a3dabfeecff9e430648d63e4b4ba001e80a00

view details

push time in 2 months

push eventswift/swift

Edwin Mons

commit sha d640ec248ca8bf86a03007a0f8df352df696cf92

Support application-supplied logging This adds a method to set a logging callback. If such a callback is set, all SWIFT_LOG calls will invoke this callback instead of writing to either stderr or the swift logging file. Test-Information: Updated unit tests pass. Checked that logs generated by Swift and Sluift (which do not set the callback) resulted in logging in the expected location. Change-Id: I0eb2a1057aa77839e1b8d5f320205eb9d5fdc253

view details

push time in 2 months

issue commentswift/swift

Swiften won't connect to the XMPP server with TLS enabled, but without StartTLS

OK then, I've opened a PR: https://github.com/swift/swift/pull/117

jw0k

comment created time in 2 months

PR opened swift/swift

add non-opportunistic TLS support

This patch adds non-opportunistic TLS support (direct TLS). It is useful in cases where StartTLS is not desirable or not available, e.g. if the XMPP server is hidden behind HAProxy which doesn't support StartTLS.

I've tested the compilation on GCC 7.4.0, GCC 9.2.0, Clang 9.0.0 and Visual 2019. I've also tested if it works in our environment on both Linux and Windows.

+29 -4

0 comment

2 changed files

pr created time in 2 months

fork jw0k/swift

Swift XMPP client and Swiften XMPP library

http://swift.im/swift

fork in 2 months

issue commentswift/swift

Swiften won't connect to the XMPP server with TLS enabled, but without StartTLS

Yes please. Contributions are under the BSD license, with a note to that effect in the commit message (e.g. https://github.com/swift/swift/commit/110eb87e848b85dd74a6f19413c775520a75ea35 ) - if you're happy with that, please open a PR and we can go from there.

jw0k

comment created time in 2 months

issue commentswift/swift

Swiften won't connect to the XMPP server with TLS enabled, but without StartTLS

@Kev That's OK. In the meantime I managed to implement it myself. Are you interested in the pull request?

jw0k

comment created time in 2 months

issue commentswift/swift

Swiften won't connect to the XMPP server with TLS enabled, but without StartTLS

Hi. Direct TLS isn't something that Swiften can currently use. It is a thing it would be useful, but I don't think any of us will have time to work on it soon, I'm afraid.

jw0k

comment created time in 2 months

push eventswift/swift

Tim Costen

commit sha 959a42d21fd70ea002da9afa7482194e8b6097e1

Handle xmpp-server SRV records Update ServerIdentityVerifier with new boolean parameter (defaulting to false) to its constructor. Use this to determine whether to check for SRV records which start with "_xmpp-client." (the default, for backwards compatibility), or "_xmpp-server.". JIRA: SWIFT-424 Bug: Release-notes: Manual: Test-information: Added a couple of new unit tests to check operation when this parameter is set true. All ServerIdentityVerifier unit tests run as before. Change-Id: Icb1fee31b436292cd6b5e61bc86482d700e40332

view details

push time in 2 months

push eventswift/swift

Edwin Mons

commit sha a616265f7a5a48c5769262027795f99df91a6ae8

Fix libxml2 crash on certain invalid input When the libxml2 parser is fed data with an odd combination of invalid input (triggering the parser to assume 2 or 4 byte encodings were in play), I/O errors might occur. In that case, the parser context will not have its internal error set, but the call to xmlParseChunk will return the right error. The parse() method now uses the output of xmlParseChunk directly instead of trying to obtain the error from the parser context afterwards. Encoding errors during parsing were emitted to stderr because the default error handlers were still in place. These have been replaced with custom handlers that suppress the output. Test-Information: Unit tests pass on Debian 9 Change-Id: Ie01db4be467e5197203c9d07d3356f5d44d8b9b4

view details

Edwin Mons

commit sha 8baf0e407b3b4914654a6036a16ac81b7a2e7414

Bring StreamError enum to spec RFC 6120 no longer defines invalid-id, and adds unsupported-feature. The StreamError enum was derived from the schema in section A.2, which erroneously had these two deviations from 4.9.3. Test-Information: Unit tests pass on Debian 9 Change-Id: I2bb3d0b09448877bbd4618fa852baab87bfa1abc

view details

push time in 3 months

push eventswift/swift

Tim Costen

commit sha 943f4cd11f35573e1af91be578cd058fac34b670

Comment out logging calls Swift OpenSSLContext and OpenSSLCertificate contain a number of error, warning and info logging calls which have the effect of writing to stderr. This patch comments them out for now - a proper interface with a logging object being passed in etc will be added at a later date. JIRA: SWIFT-426 Bug: Release-notes: Manual: Test-information: Compiles OK. TLSTest runs OK. Change-Id: I2bc09ff32277c2b669317fcf9748358b2934db7c

view details

push time in 3 months

push eventswift/swift

Tim Costen

commit sha be7632881677da5267eb711c1f2823ac82d43d09

Allow use of system TAs to be disabled via TLSOptions Add new boolean flag to TLSOptions which when set to true prevents system Trust Anchors being loaded into new TLS contexts created using OpenSSL. Add new test to Swiften QA with appropriate comment. JIRA: SWIFT-425 Test-information: Checked logic of change under debugger while running the tests in CertificateTest.cpp which create TLS contexts. Change-Id: I2d4a8410ce9cc752e6774e1d1cdb84dcd37b01d7

view details

push time in 3 months

startedswift/swift

started time in 3 months

issue openedswift/swift

Swiften won't connect to the XMPP server with TLS enabled, but without StartTLS

We have an XMPP server hidden behind the balancer. The balancer itself provides the TLS encryption. However it does not support upgrading a plaintext connection to an encrypted connection (a.k.a. StartTLS or opportunistic TLS). I suppose for this reason Swiften cannot connect to our server. Is it possible to set up Swiften in such a way that the connection is encrypted for the very beginning (without StartTLS command)? It is possible, e.g. in Psi (the option is called "Legacy SSL").

created time in 3 months

fork avichalsaxena/swift

Swift XMPP client and Swiften XMPP library

http://swift.im/swift

fork in 3 months

issue commentswift/swift

Add Omemo Encryption Support

If you implement a new library by doing so, you'll get one that is no derivative of the original library, thus you can place it under and license you want, e.g. Apache-2.0.

This is confirmed by a moxie in this public discussion 2016 on ycombinator. He writes:

We haven't patented any of the concepts here, and we've done a lot to explain and popularize them. We're happy for people to use these concepts to build their own implementations

dreamflasher

comment created time in 3 months

issue commentswift/swift

Add Omemo Encryption Support

Gathered some more info: one person who studied the xep-0384 said that it covers 90% what is needed for an implementation. So the rest could be understood by studying the reference implementations like https://github.com/tgalal/python-axolotl and https://github.com/tgalal/python-axolotl-curve25519. If you implement a new library by doing so, you'll get one that is no derivative of the original library, thus you can place it under and license you want, e.g. Apache-2.0.

The main reason for implementing OMEMO is that I see more and more people using it and thus it becomes a critical feature for a client. (And MLS seems to be years away, so waiting for it is no solution.) Implementing OMEMO is important to more use Swift-im's potential as XMPP client, just because many other clients implement it.

dreamflasher

comment created time in 3 months

push eventswift/swift

Tim Costen

commit sha 8e0a9cd6a608ee2bf83b52c9eb9ac556bf10293f

Extend getPeerCertificateChain Extend getPeerCertificateChain so that it uses the correct SSL methods for Server and Client mode contexts, i.e. SSL_get_peer_certificate as well as get_peer_cert_chain when this is a server-mode context. Tidy up error message logged on certificate verification failure. Always return "1" from verifyCallback; check result of certificate verification by a call to getPeerCertificateVerificationError() once the TLS session is established. JIRA: LINK-1814 Bug: Release-notes: Manual: Change-Id: Ica1d90998187ec5ce2584d48bd6fbfb8f9a667c9 Test-information:

view details

push time in 3 months

push eventswift/swift

Tobias Markmann

commit sha 7de9a3489c3e2ddc4c0ab78f43649c5d6be20aca

Return unique_ptr in PlatformIDNConverter::create() There are cases where users of this method forget to free the pointer. This is now avoided by returning a unique_ptr. Test-Information: All existing unit and integration tests, i.e. `./scons test=all` pass. Change-Id: I10a88c3361823074d81db7af8cec1bd70c409995

view details

push time in 3 months

issue commentswift/swift

Add Omemo Encryption Support

@Kev @dwd thanks for your responses. Now I understand why this issue is closed. (Because you believe OMEMO not to be an open standard and not promising enough.)

For the record I'm assuming that MLS refers to "Messaging Layer Security" as being discussed here:

  • https://messaginglayersecurity.rocks/
  • https://datatracker.ietf.org/wg/mls/about/
dreamflasher

comment created time in 3 months

issue commentswift/swift

Add Omemo Encryption Support

Dave's mostly saving me the effort of replying here (thanks), I agree with what he says. At this point, given OMEMO's lack of progress, and MLS on the horizon, I'm not sure that even a ready-to-go PR submission with no side effects would be accepted into Swift.

dreamflasher

comment created time in 3 months

issue commentswift/swift

Add Omemo Encryption Support

But not to me or the XSF, because (b) is irrelevant (or rather, its only relevance would be to prove (a)).

At the moment, the specification simply isn't clear enough to implement from, and makes several assumptions about the use of libsignal. Every extant implementation uses libsignal, and every one has been worked on with detailed explanations from the original authors.

Moreover, all this presupposes that the design of OMEMO is actually making the right choices. I don't think it does, but given that previous feedback from outside the core group has been ignored (including mine), there seems little point in trying to address these.

As a result, I'll just wait patiently for MLS, which is an IETF work in progress and not only provides performance improvements over OMEMO, but will certainly qualify as an open standard.

dreamflasher

comment created time in 3 months

issue commentswift/swift

Add Omemo Encryption Support

@dwd, the question to me is if the OMEMO XEP-0384 is an open standard or not. If there is a) a spec that allows implementation or b) an implementation that everyone can use (like licensed without freedom protection), it would be an open standard. Your statement seems to indicate that XEP-0384 is not an open standard. But if an implementation under Apache 2 would exist then it would be an open standard (at least to me and FSFE).

dreamflasher

comment created time in 3 months

issue commentswift/swift

Add Omemo Encryption Support

The problem isn't whether such an implementation exists, it's whether one can be created without reference to anything but openly published specifications. In that, I disagree with the FSFE's definition, which appears to mandate the existence of one or more implementations. I'd suggest instead that you look at the UK Government's principles, which are linked from the FSFE's:

https://www.gov.uk/government/publications/open-standards-principles/open-standards-principles#Defining-open-standards

Currently, OMEMO fails the second and third points of the selection criteria, and arguably all the points other than the fourth (RF licensing) of the "must also have" bit.

That's before one considers other aspects of OMEMO, like whether its design is actually as secure as it ought to be, and so on.

Of course, I'm deliberately taking a pretty strict line here, but the XMPP Standards Foundation has been known to persuade NATO to publish documents before accepting specifications, so the fact OMEMO exists as a XEP at all is evidence people have been pretty relaxed with this one.

dreamflasher

comment created time in 3 months

issue commentswift/swift

Add Omemo Encryption Support

@dwd thanks for your note. So if there were an implementation with a license that is not freedom protecting (like Xorg Style or Apache-2.0) then swift and other clients could use it. Is there such an implementation? Otherwise would it mean that there is no spec and no-reference implementation that can be generally used? (If this would be the case then this would not meet the definition of an Open Standard by FSFE https://fsfe.org/activities/os/def.en.html see points 3. and 5.) :(

dreamflasher

comment created time in 3 months

issue commentswift/swift

Add Omemo Encryption Support

The XSF view has always been that we implement from spec, and not from reverse-engineering the protocol from other implementations. Developers have tried to independently implement OMEMO from scratch, but it's proven impossible from the XEP currently - every extant implementation has been worked on by people associated with the original implementation. So it's not a viable specification currently.

That's not to say that the specification cannot be fixed, or that a fully independent implementation cannot be written. It's just not happened yet.

dreamflasher

comment created time in 3 months

push eventswift/swift

Tim Costen

commit sha 2239cdae45b39e675877ae32c86c47bcadce3090

Add ability to set external Trust Anchors to Swift OpenSSL context Add a new (optional) field to TLSContext, which allows a vector of Trust Anchor certificates to be specified. Inside OpenSSLContext::configure, pass the X509 components of these certificates into the OpenSSL context: these are now available for client certificate verification in any callback method set via TLSOptions.verifyCertificateCallback. JIRA: LINK-1765 Test-information: Tested via MLink unit tests. No leaks reported. Change-Id: Ie9cc2051ee212249a12a4bc71b62306b5bce3013

view details

push time in 3 months

issue commentswift/swift

Add Omemo Encryption Support

@Kev is there a list of issues with the current spec (you mention above)?

What is the licensing issue? The only mention in https://xmpp.org/extensions/xep-0384.html#intro-motivation is that there is one reference implementation under GNU GPL v>=3. Is this what you refer to? It does not seem to be a problem for a new implementation, though. (GNU GPL allows studying the source code to understand the protocol.)

dreamflasher

comment created time in 3 months

issue commentswift/swift

Add Omemo Encryption Support

Ping. If patches are welcome when the specs are in good enough shape, it seems sensible to keep the issue open.

dreamflasher

comment created time in 3 months

startedswift/swift

started time in 3 months

startedswift/swift

started time in 3 months

push eventswift/swift

Tim Costen

commit sha 2ad1938c50f9fe57fe3dd98eb9f4bb711ac52acd

Correct leaks in OpenSSL interface Remove increment of reference count on first certificate added to a new SSL context - the call to SSL_CTX_use_certificate does this internally. When adding extra certificates to the context via calls to SSL_CTX_add_extra_certificate, the explicit increment of the reference count is still required to prevent destruction of the certificates when the SSL context is freed. In OpenSSLContext::setPrivateKey, make sure the EVP_PKEY returned by PEM_read_bio_PrivateKey is tidied up, by wrapping it in a shared_ptr which calls EVP_PKEY_free. Add a new Unit test which creates an SSL context and inserts a multi-element certificate chain and a private key. JIRA: SWIFT-423 Bug: Release-notes: Manual: Change-Id: I82c66139a9dfe7a925eb39f73721200895a689e2 Test-information: Leak testing performed via ASAN-compiled MLink unit tests - now no leaks/errors reported associated with TLS Contexts and Certificates. Swiften unit test runs as expected.

view details

push time in 3 months

push eventswift/swift

Joanna Hulboj

commit sha df07a5e1e654c5fe4b513b8b0e41a392e9955cdf

Treat numeric domain JID as invalid DomainJID consisting of only numbers is not treated as valid. Test-information: Unit tests pass on Windows 10 and Ubuntu 18.04.1 LTS. Change-Id: If23ba8b8ea2a3c72d6f6e3acec4f587166c14e61

view details

push time in 4 months

issue commentswift/swift

Can't establish connection to Google's Firebase XMPP server

Hi - I don't know anything about Firebase, but what is getting returned on your connection isn't what an XMPP server would return (it would return XML), even on an error, so I don't think I can sensibly help with this.

vmarkushin

comment created time in 4 months

issue commentswift/swift

XML StreamError (Swift::ClientError::Type) on <footag> in element content.

Thank you for clarifying this. I use a qt xmlwriter class now and it works like a charm.

geobra

comment created time in 4 months

push eventswift/swift

Joanna Hulboj

commit sha 6f5fa6a02eb7502a15afab70c91451b8142e2ac3

Remove duplicated arguments Test-information: Unit tests pass on Windows 10 and Ubuntu 18.04.1 LTS. Change-Id: Icea837d91f28f47f7b0a90bc620b26c5567c8421

view details

push time in 4 months

issue closedswift/swift

XML StreamError (Swift::ClientError::Type) on <footag> in element content.

A little code snipped to reproduce this error.

----------------------------------- 8< -------------------------------------- Swift::Message::ref msg(new Swift::Message); Swift::IDGenerator idGenerator; std::string msgId = idGenerator.generateID(); Swift::JID toJID = Swift::JID(jid.toStdString());

    msg->setFrom(Swift::JID(client_->getJID()));
    msg->setID(msgId);

    QString displayedPayload = "<displayed xmlns='" +  chatMarkersIdentifier + "' id='" + displayedMsgId + "' ";

    if (itsAMuc == true)
    {
        msg->setTo(toJID.toBare());
        msg->setType(Swift::Message::Groupchat);

        QString sender = QString::fromStdString(toJID.toString());

        if (toJID.isBare() == true)
        {
            sender += "/" + persistence_->getResourceForMsgId(displayedMsgId);
        }

        displayedPayload += " sender='" +  sender + "'";
    }
    else
    {
        msg->setTo(toJID);
        msg->setType(Swift::Message::Normal);
    }

    displayedPayload += " />";

    msg->addPayload(boost::make_shared<Swift::RawXMLPayload>(displayedPayload.toStdString()));

    client_->sendMessage(msg);

----------------------------------- 8< --------------------------------------

Assume displayedPayload contains: <displayed xmlns="urn:xmpp:chat-markers:0" id="abc" sender="3q1u5zjubr4rb@conference.jabber.ccc.de/123<xyz>456"></displayed>

This causes Swiften to exit with 'StreamError'. If I programmatically replace the '123<xyz>456' by '123(xyz)456', all works fine. I would assume that <> inside of a content element within the " did not get interpreted by Swithen library.

closed time in 4 months

geobra

issue commentswift/swift

XML StreamError (Swift::ClientError::Type) on <footag> in element content.

The stream error is coming from the server being unhappy with what's sent, which implies that the stanza you're crafting is invalid somehow, probably invalid XML. This is quite likely to happen, I'd suggest creating payloads and the appropriate parsers/serialisers, rather than relying on hand-crafting XML. The RawXMLPayload is exactly as it sounds - this is the raw XML that's going to be written to the stream, the user is responsible for ensuring that it's valid.

geobra

comment created time in 4 months

push eventswift/swift

Joanna Hulboj

commit sha 23e2766dab6d4a3f6158eca7649cd36b644634d3

Process attribute and element prefixes XML (Expat/LibXML) parsing modified to process prefix information. Prefixes for attributes stored within attributes. Prefixes for elements passed in additional callback (only if prefix present). Test-information: Unit tests pass on Windows 10 and Ubuntu 18.04.1 LTS. Change-Id: Ib6b5087feed758c31895f426df6a3c7ea975f248

view details

push time in 4 months

issue openedswift/swift

XML StreamError (Swift::ClientError::Type) on <footag> in element content.

A little code snipped to reproduce this error.

----------------------------------- 8< -------------------------------------- Swift::Message::ref msg(new Swift::Message); Swift::IDGenerator idGenerator; std::string msgId = idGenerator.generateID(); Swift::JID toJID = Swift::JID(jid.toStdString());

    msg->setFrom(Swift::JID(client_->getJID()));
    msg->setID(msgId);

    QString displayedPayload = "<displayed xmlns='" +  chatMarkersIdentifier + "' id='" + displayedMsgId + "' ";

    if (itsAMuc == true)
    {
        msg->setTo(toJID.toBare());
        msg->setType(Swift::Message::Groupchat);

        QString sender = QString::fromStdString(toJID.toString());

        if (toJID.isBare() == true)
        {
            sender += "/" + persistence_->getResourceForMsgId(displayedMsgId);
        }

        displayedPayload += " sender='" +  sender + "'";
    }
    else
    {
        msg->setTo(toJID);
        msg->setType(Swift::Message::Normal);
    }

    displayedPayload += " />";

    msg->addPayload(boost::make_shared<Swift::RawXMLPayload>(displayedPayload.toStdString()));

    client_->sendMessage(msg);

----------------------------------- 8< --------------------------------------

Assume displayedPayload contains: <displayed xmlns="urn:xmpp:chat-markers:0" id="abc" sender="3q1u5zjubr4rb@conference.jabber.ccc.de/123<xyz>456"></displayed>

This causes Swiften to exit with 'StreamError'. If I programmatically replace the '123<xyz>456' by '123(xyz)456', all works fine. I would assume that <> inside of a content element within the " did not get interpreted by Swithen library.

created time in 4 months

push eventswift/swift

Tim Costen

commit sha e58cf7d5d7d3bab330bccf6a098dd476fbf4dc86

Add support for use of shared certificate chain when setting up TLS context Actual implementation is in OpenSSL subclass. This allows a permanent vector of shared certificates to be used when creating multiple OpenSSL contexts. This replaces the existing use of a vector of unique pointers to certificates which handed over responsibility for the underlying OpenSSL certs to the OpenSSL context. To enable this to work, a new method is added to the OpenSSLCertificate class which enables the reference count on the the contained OpenSSL certificate to be incremented - this stops the OpenSSL certificate being deleted when the OpenSSL context is freed. Use of conditional compilation was necessary to get the reference counting to build with the different versions of OpenSSL in use. Modify the method in OpenSSLCertificateFactory (and stub in CertificateFactory) which generates a vector of certificates, so that it generates a vector of shared_ptrs rather than unique_ptrs. Add test of CreateCertificateChain to Swiften CertificateTest class, together with sample certificate file in PEM form. JIRA: LINK-1763 Bug: Release-notes: Manual: Test-information: Tested via development version of Mystique - created multiple TLS sessions using single certificate chain. Swift unit tests now build and run again. New Swiften TLS unit test builds and runs. Change-Id: I7fa4888b640c94b68712a6bff1f7aa334a358df2

view details

push time in 4 months

push eventswift/swift

Tobias Markmann

commit sha 8051f94932b6932a2e3eb60a26c758fbfed6d6ad

Set DEBIAN_FRONTEND=noninteractive for Dockerfile.package.in Test-Information: Tested that it does not request input from user anymore. Change-Id: I85d231dab20e124f4ee8a9575a1b0422d216abe0

view details

push time in 4 months

fork stinvi/swift

Swift XMPP client and Swiften XMPP library

http://swift.im/swift

fork in 4 months

push eventswift/swift

Tobias Markmann

commit sha f15902a76e0f3ff0151fb34dcfae2db75a2f5fb7

Fix casing of enums to avoid conflict on Windows Test-Information: Tested on Windows with OpenSSL that this fixes the compilation issue. Change-Id: I01887c8eb758a6c1c208244cdae32aa9c0a99565

view details

push time in 4 months

push eventswift/swift

Joanna Hulboj

commit sha 181ac4a83ba4a82be683fb0a6f08393d3c91320c

Close the stream for disallowed XML features According to RFC 6120 if any disallowed XML feature is encountered, we should close the stream with a <restricted-xml/>. The following features of XML are prohibited in XMPP: - processing instructions - internal or external DTD subsets - internal or external entity references - comments Test-information: Unit tests pass on Windows 10 and Ubuntu 18.04.1 LTS Change-Id: I475920c91b7f9da51ab37c106a4783a52f6e3cae

view details

push time in 4 months

issue commentswift/swift

TypeError: unsupported operand type(s) for +: 'filter' and 'list':

Any further information I can provide to help with this? This is the last service I need to migrate to my Arch server.

sdfg2

comment created time in 4 months

startedswift/swift

started time in 4 months

startedswift/swift

started time in 4 months

more