profile
viewpoint

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 9 days

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 9 days

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 9 days

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 9 days

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 9 days

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 9 days

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 9 days

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 9 days

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 10 days

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 10 days

startedswift/swift

started time in 10 days

startedswift/swift

started time in 10 days

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 12 days

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 14 days

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 14 days

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 20 days

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 22 days

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 22 days

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 22 days

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 23 days

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 23 days

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 a month

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 a month

fork stinvi/swift

Swift XMPP client and Swiften XMPP library

http://swift.im/swift

fork in a month

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 a month

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 a month

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 a month

startedswift/swift

started time in a month

startedswift/swift

started time in a month

push eventswift/swift

Tim Costen

commit sha 415870c04a7e6cabf13e6acf3a94bb0f68732907

Add enhanced OpenSSL configuration Adds TLSOptions to the OpenSSLContext, which invokes a new private 'configure' method which allows various OpenSSL options to be set. Also add standard verification callbacks and external (via a std::function field in TLSOptions) to allow the user to specify their own method which will perform client certificate checking when a new TLS connection is accepted. Only set up the internal verifyCertCallback if the user-supplied hook is set. All callback hooks are set up in the 'configure' method, and only then if TLSOptions.verifyMode is present (i.e. not defaulted to boost::none), to preserve compatibility for users of this class (e.g. Swift) which want to use OpenSSL's own internal validation functions rather than setting the callbacks. Test-information: Used new code under development in M-Link when setting up a TLSContext, setting verify-mode=require, and set up verifyCertCallback with a local method. Making a client TLS connection which includes a client certificate results in the local verify callback being invoked. Change-Id: Idbb7279e1711fca8123f430bfca0dcfb65bc8da6

view details

push time in a month

startedswift/swift

started time in 2 months

startedswift/swift

started time in 2 months

push eventswift/swift

Tobias Markmann

commit sha c62b7b6ce35a77d0a8236ef48155187fe5c30d12

Fix building 3rdParty/Expat on non-Windows Test-Information: Tested successfully on macOS 10.14.6 and Debian 9. Change-Id: I341589b6e92e9d16b53ea247d0b91ac1a0639f66

view details

push time in 2 months

issue commentswift/swift

Bundles vulnerable copy of Expat - please update to 2.2.7

Cool, thank you!

hartwork

comment created time in 3 months

push eventswift/swift

Tobias Markmann

commit sha e74a38b60d600d547b3b2e4dfdd7ddb543855e3f

Update 3rdParty/Expat to 2.2.7 Test-Information: None yet. Change-Id: Ia5b570c918b8059561b52062e8d43496f188ee4a

view details

Tobias Markmann

commit sha d4105dbe815ba4109e0165cae696bd87d91c8bfe

Add KDE Neon support to InstallSwiftDependencies.sh Thanks Miroslaw Stein. Test-Information: After running BuildTools/InstallSwiftDependencies.sh Swift builds fine on KDE Neon User Edition 5.16. Change-Id: I05c074051aaecfdaf2352308285bcfaeaa4d8c2c

view details

push time in 3 months

issue closedswift/swift

Bundles vulnerable copy of Expat - please update to 2.2.7

Hi!

This repository bundles an outdated vulnerable copy of Expat 2.2.1. Please update your copy to version 2.2.7 with the latest security fixes. A change log with details is available at https://github.com/libexpat/libexpat/blob/master/expat/Changes . Thank you!

Best

  Sebastian

CC #70

closed time in 3 months

hartwork

issue commentswift/swift

Bundles vulnerable copy of Expat - please update to 2.2.7

Hi. Yes, this has been merged, thanks for the heads-up.

hartwork

comment created time in 3 months

issue commentswift/swift

Bundles vulnerable copy of Expat - please update to 2.2.7

Any news?

hartwork

comment created time in 3 months

push eventswift/swift

Edwin Mons

commit sha f6fb85ba98fdd6601c4b8323c51c8367ccc4b52e

Signal namespace declarations to ParserClients Prior to calling handleStartElement, the ParserClient handleNamespaceDeclaration will fire for each namespace declared on the element. Test-Information: Unit tests pass on Debian 9 for both expat and libxml2 Change-Id: Ic42e83aee83edfbb2aa5c971997808eb6e133223

view details

push time in 3 months

startedswift/swift

started time in 3 months

more