Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

June 15 2017

ProcessOne: ejabberd 17.06-beta

ejabberd 17.06-beta includes a lot of improvements over the previous 17.04 release. To name the most important ones: new caching system, Riak support for several modules and introduction of Certificate Manager.

Certificate Manager is a feature that has been requested by many organisations, allowing administrators to manage their certificate more easily. From now, starting ejabberd with an invalid certificate will dump a clear entry in ejabberd log file, explaining what’s wrong. Upcoming ACME support will further refine these improvements we’ve worked on early this year to give our users a great experience with certificate management.

The new cache system is also a new component that allows fine tuning of ejabberd performance for either small systems or large scale servers. To use data cache for a supported module, you need to set the module option use_cache. You also have the possibility to define a maximum number of cache entries and/or maximum life time of cached data, so you keep control on your memory use. Example:

modules:
  mod_roster:
    use_cache: true
    cache_size: 10000
    cache_life_time: 3600  # 1 hour

The cleanup tasks on all ejabberd API also continue, consider checking against few methods rename.

Some features and fixes are missing from the 17.06 milestone, and will be worked on the next couple of weeks.

Changes

API

  • Deprecate misc:encode_base64/1 and misc:decode_base64/1
  • Rename is_user_exists function to user_exists
  • Allow api access on both ipv4 and 6 loopback addresses

Admin

  • Refactor ejabberdctl
  • Improve ejabberdctl parameters parsing

Configuration

  • Validate module options on start_module/2
  • Validate new options before module reloading
  • Validate second-level options
  • Introduce iqdisc global option
  • stream_management listen option deprecated, use mod_stream_mgmt
  • Check presence of some files during option validation
  • Speedup configuration options lookup
  • Validate all certfiles on startup
  • Only validate certfiles if public_key:short_name_hash/1 is available
  • Introduce Certficate Manager

Commands

  • Add clear_cache admin command
  • Parse correctly presence_broadcast option in change_room_option command
  • Describe command arguments and results in mod_muc_admin
  • Improve export2sql explanation; remove obsolete and duplicated command
  • Fix and document push_roster_all command

Compilation

  • Erlang 17.5 or higher is required
  • Add --enable-system-deps configure option
  • Add --enable-stun and --enable-sip configure options

Core

  • Speedup Mnesia tables initialization
  • Improve Mnesia tables creation and transformation
  • Improve ejabberd_c2s:close()
  • ejabberd_c2s: Don’t close session on stream resume
  • Speedup loading of translation files
  • Fix ejabberd_router:is_my_route/1

Databases

  • New sql_connect_timeout option
  • New sql_query_timeout option
  • Get rid of sql_queries.erl
  • Use round-robin algorithm when selecting worker from DB pool
  • Add Riak as BOSH RAM backend
  • Add Riak as mod_proxy65 RAM backend
  • Add Riak as mod_carboncopy RAM backend
  • Add Riak as router RAM backend
  • Add Riak as session manager RAM backend
  • Fix cleaning of Riak route table

Cache

  • Implement cache for mod_announce
  • Implement cache for mod_private
  • Implement cache for mod_privacy/mod_blocking
  • Implement cache for mod_last
  • Implement cache for mod_vcard and mod_vcard_xupdate
  • Implement cache for roster
  • Add cache options to the validator
  • Use cache for authentication backends
  • Use new cache API in mod_shared_roster_ldap
  • Use new cache API in ejabberd_oauth
  • Use new cache API in mod_mam
  • Use new cache API in mod_caps
  • Use cache in front of Redis/SQL RAM backends

Modules

  • mod_http_upload: Add support for HTTP File Upload 0.3.0
  • mod_mam: Added export function
  • mod_metrics: Don’t leak with UDP sockets
  • mod_metrics: New options ip and port
  • mod_muc: Allow a room admin to un/subscribe another JID
  • mod_offline: Don’t store messages via a single process
  • mod_offline: Make sure only jabber:x:event tag is present in offline event
  • mod_register: New option ‘access_remove’ ACL
  • mod_stream_mgmt: Preserve stanza count on timeout
  • mod_vcard_ldap: Parse ldap_uids like in eldap_utils

Elixir

  • Update elixir to v1.4.4

Installer

  • Upgrade OTP to 19.3

Feedback

As usual, the release is tagged in the Git source code repository on Github.

The source package and binary installers are available at ProcessOne.

If you suspect that you’ve found a bug, please search or fill a bug report on Github.

June 14 2017

Paul Schaub: Tutorial: Home-made OMEMO client

The german interior minister conference recently decided that the best way to fight terrorism is passing new laws that allow the government to demand access to communication from messengers like WhatsApp and co. Very important: Messengers like WhatsApp. Will even free software developers see requests to change their messengers to allow government access to communications in the future? If it comes so far, how are we then still possible to protect our communications?

The answer could be: Build your own messenger. I want to demonstrate, how simple it is to create a very basic messenger that allows you to send and receive end-to-end encrypted text messages via XMPP using Smack. We will use Smacks latest new feature – OMEMO support to create a very simple XMPP based command line chat application that uses state of the art encryption. I assume, that you all know, what XMPP is. If not, please read it up on Wikipedia. Smack is a java library that makes it easy to use XMPP in an application. OMEMO is basically the Signal protocol for XMPP.

So lets hop straight into it.
In my example, I import smack as a gradle dependency. That looks like this:

gradle.build

apply plugin: 'java'
apply plugin: 'idea'

repositories {
    mavenCentral()
    maven {
        url 'https://oss.sonatype.org/content/repositories/snapshots'
    }
}

ext {
    smackVersion="4.2.1-SNAPSHOT"
}

dependencies {
    compile "org.igniterealtime.smack:smack-java7:$smackVersion"
    compile "org.igniterealtime.smack:smack-omemo-signal:$smackVersion"
    compile "org.igniterealtime.smack:smack-resolver-dnsjava:$smackVersion"
    compile "org.igniterealtime.smack:smack-tcp:$smackVersion"
}

//Pack dependencies into the jar
jar {
    from(configurations.compile.collect { it.isDirectory() ? it : zipTree(it) }) {
    exclude "META-INF/*.SF"
    exclude "META-INF/LICENSE"
    }
    manifest {
        attributes(
            'Main-Class': 'Messenger'
        )
    }
}

Now we can start the main function of our client. We need to create a connection to a server and log in to go online. Lets assume, that the user passes username and password as arguments to our main function. For sake of simplicity, we’ll not catch any errors like wrong number of parameters etc. Also we want to get notified of incoming chat messages and we want to send messages to others.

Messenger.java

public class Messenger {

    private AbstractXMPPConnection connection;
    private static Scanner scanner;

    public static void main(String[] args) throws Exception {
        String username = args[0];
        String password = args[1];
        Messenger messenger = new Messenger(username, password);

        scanner = new Scanner(System.in);
        while(true) {
            String input = scanner.nextLine();

            if (input.startsWith("/quit")) {
                break;
            }
            if (input.isEmpty()) {
                continue;
            }
            messenger.handleInput(input);
        }
    }

    public Messenger(String username, String password) throws Exception {
        connection = new XMPPTCPConnection(username, password);
        connection = connection.connect();
        connection.login();

        ChatManager.getInstanceFor(connection).addIncomingListener(
                (from, message, chat) -> System.out.println(from.asBareJid() + ": " + message)
        );

        System.out.println("Logged in");
    }

    public void handleInput(String input) throws Exception {
        String[] split = input.split(" ");
        String command = split[0];

        switch (command) {
            case "/say":
                if (split.length > 3) {
                    String recipient = split[1];
                    EntityBareJid recipientJid = JidCreate.entityBareFrom(recipient);

                    StringBuilder message = new StringBuilder();
                    for (int i=2; i<split.length; i++) message.append(split[i]);

                    ChatManager.getInstanceFor(connection).chatWith(recipientJid).send(message);
                }
                break;
        }
    }
}

If we now compile this code and execute it using credentials of an existing account, we can already log in and start chatting with others using the /say command (eg. /say bob@marley.jm Hi Bob!). But our communications are unencrypted right now (aside from tls transport encryption). Lets change that next. We want to use OMEMO encryption to secure our messages, so we utilize Smacks new OmemoManager which handles OMEMO encryption. For that purpose, we need a new private variable which will hold our OmemoManager. Also we make some changes to the constructor.

Messenger.java

private OmemoManager omemoManager;

public Messenger(String username, String password) throws Exception {
    connection = new XMPPTCPConnection(username, password);
    connection = connection.connect();
    connection.login();

    //additions begin here
    SignalOmemoService.acknowledgeLicense();
    SignalOmemoService.setup();
    //path where keys get stored
    OmemoConfiguration.setFileBasedOmemoStoreDefaultPath(new File("path"));
    omemoManager = OmemoManager.getInstanceFor(connection);

    //Listener for incoming OMEMO messages
    omemoManager.addOmemoMessageListener(new OmemoMessageListener() {
        @Override
        public void onOmemoMessageReceived(String decryptedBody, Message encryptedMessage,
                        Message wrappingMessage, OmemoMessageInformation omemoInformation) {
            System.out.println("(O) " + encryptedMessage.getFrom() + ": " + decryptedBody);
        }

        @Override
        public void onOmemoKeyTransportReceived(CipherAndAuthTag cipherAndAuthTag, Message message,
                        Message wrappingMessage, OmemoMessageInformation omemoInformation) {
            //Not needed
        }
    });

    ChatManager.getInstanceFor(connection).addIncomingListener(
            (from, message, chat) -> System.out.println(from.asBareJid() + ": " + message)
    );
    omemoManager.initialize();
    //additions end here.
    System.out.println("Logged in");
}

Also we must add two new commands that are needed to control OMEMO. /omemo is similar to /say, but will encrypt the message via OMEMO. /trust is used to trust an identity. Before you can send a message, you have to decide, whether you want to trust or distrust an identity. When you call the trust command, the client will present you with a fingerprint which you have to compare with your chat patner. Only if the fingerprint matches, you should trust it. We add the following two cases to the handleInput’s switch case environment:

Messenger.java

case "/omemo":
    if (split.length > 2) {
        String recipient = split[1];
        EntityBareJid recipientJid = JidCreate.entityBareFrom(recipient);

        StringBuilder message = new StringBuilder();
        for (int i=2; i<split.length; i++) message.append(split[i]);

        //encrypt
        Message encrypted = null;
        try {
            encrypted = OmemoManager.getInstanceFor(connection).encrypt(recipientJid, message.toString());
            ChatManager.getInstanceFor(connection).chatWith(recipientJid).send(encrypted);
        }
        // In case of undecided devices
        catch (UndecidedOmemoIdentityException e) {
            System.out.println("Undecided Identities: ");
            for (OmemoDevice device : e.getUntrustedDevices()) {
                System.out.println(device);
            }
        }
        //In case we cannot establish session with some devices
        catch (CannotEstablishOmemoSessionException e) {
            encrypted = omemoManager.encryptForExistingSessions(e, message.toString());
        }

        //send
        if (encrypted != null) {
            ChatManager.getInstanceFor(connection).chatWith(recipientJid).send(encrypted);
        }
    }
    break;

case "/trust":
    if (split.length == 2) {
        BareJid contact = JidCreate.bareFrom(split[1]);
        HashMap fingerprints =
                omemoManager.getActiveFingerprints(contact);

        //Let user decide
        for (OmemoDevice d : fingerprints.keySet()) {
            System.out.println("Trust (1), or distrust (2)?");
            System.out.println(OmemoKeyUtil.prettyFingerprint(fingerprints.get(d)));
            int decision = Integer.parseInt(scanner.nextLine());
            if (decision == 1) {
               omemoManager.trustOmemoIdentity(d, fingerprints.get(d));
            } else {
                omemoManager.distrustOmemoIdentity(d, fingerprints.get(d));
            }
        }
    }
    break;

Now we can trust contact OMEMO identities using /trust bob@marley.jm and send them encrypted messages using /omemo bob@marley.jm Hi Bob!. When we receive OMEMO messages, they are indicated by a “(O)” in front of the sender.
If we want to go really fancy, we can let our messenger display, whether received messages are encrypted using a trusted key. Unfortunately, there is no convenience method for this available yet, so we have to do a small dirty workaround. We modify the onOmemoMessageReceived method of the OmemoMessageListener like this:

Messenger.java

@Override
public void onOmemoMessageReceived(String decryptedBody, Message encryptedMessage,
            Message wrappingMessage, OmemoMessageInformation omemoInformation) {
    //Get identityKey of sender
    IdentityKey senderKey = (IdentityKey) omemoInformation.getSenderIdentityKey().getIdentityKey();
    OmemoService service = (OmemoService)
            OmemoService.getInstance();
    //get the fingerprint of the key
    OmemoFingerprint fingerprint = service.getOmemoStoreBackend().keyUtil().getFingerprint(senderKey);
    //Lookup trust status
    boolean trusted = omemoManager.isTrustedOmemoIdentity(omemoInformation.getSenderDevice(), fingerprint);

    System.out.println("(O) " + (trusted ? "T" : "D") + " " + encryptedMessage.getFrom() + ": " + decryptedBody);
}

Now when we receive a message from a trusted identity, there will be a “T” before the message, otherwise there is a “D”.
I hope I could give a brief introduction on how to use Smacks OMEMO support. You now have a basic chat client, that is capable of exchanging multi-end-to-multi-end encrypted messages with other XMPP clients that support OMEMO. All took less than 200 lines of code! Now its up to you to add additional features like support for message carbons, offline messages and co. Spoiler: Its not hard at all :)

When the government is unable or simply not willing to preserve your privacy, you’ll have to do it yourself.

Happy Hacking :)

Paul Schaub: GSoC – Second week of coding

The second week of GSoC is over! My Jingle implementation progresses.

Most of my efforts went into designing the state machine behind the Jingle and Jingle File Transfer protocol. Because I never really worked with asynchronous communication, let alone network code before, it takes some time to get my head around that.

I’m heavily utilizing the water fall development model – I code until I get stuck at some point I did not consider at all, then I create a new class and start over again. This is very tideous, but I make slow progress towards working Jingle Socks5 Bytestream transports!

All in all I predict, that it’ll take its time to fully complete the Jingle implementation so that it covers every corner case.

Introducing JET!

While working on my Jingle code, I also started writing down my plans for Jingle Encrypted Transfers (jet). My goal is to keep that specification as simple as possible while providing a reasonable way to exchange encrypted data. I decided, that hiding metadata is not in the scope of this document for now, but can later be specified in a seperate document. Contributions and thoughts regarding encrypted Jingle file transfer are welcome :)

Happy Hacking!

June 08 2017

ProcessOne: XMPP Radar Newsletter #23

The following articles got our attention in the month of May:

Google Summer of Code hosts ejabberd projects

Like in previous years, ejabberd projects are participating in Google Summer of Code 2017. This year, nine BEAM Community projects have been accepted – two of them involve ejabberd.

Coinbase is launching an Ethereum messaging app

Coinbase is reportedly launching a new subsidiary brand focusing on secure messaging and blockchain-enabled payments, its chief executive said in online statements.

Internet of Things and connected assets

Data in the 21st century has been compared to oil in the 19th century: a vast, valuable, and still largely untapped resource. In this series of articles, you can find interesting use cases of IoT and data analysis.

Internet of Things application protocols

Imagine an environment of constrained devices which are Always, Anywhere and Anytime connected with each other and sending data or information which can be further processed over cloud to generate analytic result which can be used to automate an action. How billions of things will communicate?

How to install eJabberd XMPP server on Ubuntu

If you never tried ejabberd before, here’s a super-simple guide on how to get started with one of the most popular XMPP servers.

Google Talk shutting down on June 26

Here’s a friendly reminder that Google announced to completely shut down the Google Talk service after June 26, 2017.

June 06 2017

Ignite Realtime Blog: Smack v4.2 Introduces OMEMO Support!

This blogpost doubles as a GSoC update, as well as a version release blog post.

 

OMEMO Clownfish logo.
OMEMO Clownfish logo (conversations.im)

 

I have the honour to announce the latest release of Smack! Version 4.2.1 brings among bug fixes and additional features like Explicit Message Encryption (XEP-0380) and Message Processing Hints (XEP-0334) support for OMEMO Multi-End-Message-and-Object encryption (XEP-0384). The OMEMO protocol was developed by Andreas Straub for the Conversations messenger (also as a Google Summer of Code project) in 2015. Since then it got quite popular and drew a lot of attention for XMPP in the media. My hope is that my efforts to develop an easy to use Smack module will result in an even broader adoption.

 

The new Smack release is available from the Maven snapshot repository.

 

OMEMO is a protocol for multi-end to multi-end encrypted communication, which utilizes the so called Double Ratchet algorithm. It fulfills amongst the basic requirements of encrypted communication (confidentiality, authenticity and integrity) also the properties of deniability and forward secrecy as well as future secrecy. Smacks implementation brings support for encrypted single and group chats including identity management and session renegotiation.

 

Current implementations (as well as this one) are based upon the libsignal library developed by OpenWhisperSystems for their popular Signal (formerly TextSecure) messenger. Smack's OMEMO support is structured in two modules. There is smack-omemo (APL licensed), which contains the logic specified in the XEP, as well as some basic cryptographic code. The other module smack-omemo-signal (GPLv3 licensed) implements some abstract methods defined by smack-omemo and encapsulates all function calls to libsignal.

 

Currently smack-omemo-signal is the only module available that implements the double ratchet functionality, but there has been a lot of discussion on the XMPP Standards Foundations mailing list regarding the use of alternative (more permissively licensed) libraries for OMEMO (like for example Olm, a double ratchet implementation from our friends over at the [matrix] project). So once there is a new specification that enables the use of other libraries, it should be pretty easy to write another module for smack-omemo enabling OMEMO support for clients that are not GPLv3 compatible as well.

 

Smack’s OMEMO modules are my first bigger contribution to a free software project and started as part of my bachelors thesis. I’m quite happy with the outcome

 

Smack Logo
Also Smack has a new Logo!

 

That was a lot of talking about OMEMO. Now comes the second functioning of this blog post, my GSoC update.

 

My project of implementing Jingle File Transfer (XEP-0234) for Smack is going relatively well. I'm stuck at some points where there are ambiguities in the XEP or things I don't know yet, but most of the time I find another construction site where I can continue my work. Currently I'm implementing stanza providers and elements needed for file transfer. Along the way I steadily create Junit tests to keep the code coverage at a high level. Already it pays off when there are fiddly changes in the element structure. I already got file transfer over Jingle IBB working.

 

It’s a real pleasure to learn all the tools I never used before like code coverage reports or mocking and I think Flow does a good job introducing me to them one by one.

 

That’s all for now. Happy hacking

May 31 2017

Swift Blog: Swift 4.0 RC2: Now Available

A Release Candiate for Swift 4.0 is now available for download. Read on for more information and download instructions.

Swift 4.0 RC2 is now available from our releases page. This release includes:

  • Support for message carbons (XEP-0280)
  • Trellis mode enabled as a default feature, allowing several tiled chats windows to be shown at once
  • New chat theme including a new font
  • Redesigned keyword highlighting
  • Improved spell checker support on Linux
  • Support for automatic software updates on macOS
  • Support for unicode emojis on macOS
  • And assorted smaller features and usability enhancements

Please email (swift@swift.im) or tweet (@swift_im) any feedback you have to help us further improve Swift.

May 26 2017

Paul Schaub: Last week of GSoC Community Bonding

This is my report for the last week of community bonding. On next tuesday the coding phase officially begins \o/.

I spent my week like I did the one before; writing tests, increasing the codecoverage of my Smack OMEMO module. Today the coverage finally reached the same level as the main codebase, meaning my PR wouldn’t decrease the percentage anymore. Apart from that I’ve read some tips on java.nio usage for file transfer and made myself more familiar with its non-blocking IO concepts.

Throughout the week I took the one or other chance to distract myself from work by pariticipating in OMEMO related discussions on the standards mailing list. I’m quite happy, that there’s a vital discussion on the topic which seems to have a solution in prospect which is acceptable for everyone. Specifying the OMEMO XEP in a way that enables implementations using different crypto libraries is definitely a huge step forward which might bring a broader adoption without leaving those who pioneered and developed the standard standing in the rain (all my subjective opinion). I was really surprised to see developers of the Matrix project participating in the discussion. That reminded me of what the spirit of floss software really is :)

I plan to spent the last days before the coding phase sketching out my projects structure and relaxing a little before the hard work begins. One of my goals is to plan ahead and I really hope to fulfill this goal.

Happy Hacking :)

Vanitasvitae

May 24 2017

Tigase Blog: Stateless XMPP: A competitive mobile experience.

With a bevy of new chat platforms available to consumers, it seems more and more that the emphasis of knowing who is online and what they are doing has fallen out of favor.

ProcessOne: Google Summer of Code hosts ejabberd projects

As you may know, our ejabberd XMPP server is written in Erlang. The Erlang VM was originally designed by Ericsson to support distributed, fault-tolerant, soft-real-time, non-stop applications. What you may not know is that ejabberd is part of the BEAM Community – a group of projects that run on the Erlang VM.

Since 2013, BEAM Community hosts relevant Erlang and Elixir projects, making it easier to participate in the Google Summer of Code (GSoC) (and similar initiatives), giving interested students a wide range of projects to choose from.

BEAM Community has been accepted again in 2017 as a GSoC mentoring organisation. This year, nine projects have been accepted:

  • For Lasp:
    • A Biparite Proposal for Lasp’s Lacking Documentation by Matt Wiese
    • Implementing a Real World Application in the Lasp Programming Language by goncalotomas
  • For Erlang:
    • ETS support for Erlang Lab by Kacper Mentel
  • For Elixir:
    • A code formatter for Elixir by alexjiao
    • Language Server Protocol implementation for Elixir by Nishith Kumar Shah
  • For Barrel:
    • Implementation of a RabbitMQ Plugin for BarrelDB by Tah Teche Tende
  • For Zotonic:
    • Port Zotonic Shell Scripts to Erlang EScript by Blaise M.
  • For ejabberd:
    • Ejabberd support for “let’s encrypt” ACME protocol by Konstantinos Kallas
    • Server-to-Server stream management support for ejabberd by Anna Mukharram

You can find more details about these projects here, but first lets look at the ejabberd projects.

Support for “let’s encrypt” ACME protocol

The Automatic Certificate Management Environment (ACME) protocol is a communications protocol for automating interactions between certificate authorities and their users’ web servers, allowing the automated deployment of public key infrastructure at very low cost. Supporting this protocol will reduce the complexity of acquiring certificates for TLS encryption, via the “Let’s encrypt” certificate authority.

The final goal of this project is for ejabberd to fully support the ACME protocol and thus provide an easy and cheap way of acquiring security certificates. This project is executed by Konstantinos Kallas, mentored by Evgeny Khramtsov from ProcessOne.

Server-to-Server stream management support

The goal of this project is to implement XEP-0198 for server-to-server communication in ejabberd. This extension allows to request stanza acknowledgement and quickly resume session. Any messages that were not delivered over previous connection will be retransmitted during session resumption without duplication. This project is executed by Anna Mukharram, mentored by Holger Weiß, an experienced ejabberd & XMPP developer.

Google Summer of Code

ProcessOne is committed to grow the interest of student developers in XMPP, ejabberd and real-time technologies. Through initiatives like the BEAM Community and GSoC involvement, we can have bigger and more positive impact, as well as bring valuable improvements to existing projects.

May 20 2017

Paul Schaub: GSoC: Second, third week of community bonding

Hi all!

This is my report for the second, as well as the first half of the third week of GSoC community bonding, which I spent again working on finalizing my OMEMO code.

I dug deeper into writing test cases, mainly integration tests and I found quite a lot of small, undetectable bugs this way (Yay!). This strengthens my plan to work test driven during my GSoC project. The OMEMO code I currently work on was started as part of my bachelor thesis about 4 to 5 months ago and at this time, I was more concerned about having working code in the end, so I wrote no tests at all. Deploying test cases AFTER the code is already written is not only a tideous task, but its also often very difficult (because the code is not structured properly). So I learned my lesson the hard way :D

During testing I also found another bug in an XMPP server software, which prevents Smack from creating accounts on the server on the fly. Unfortunatelly this bug will not get fixed anymore for the version I use (installed from debian testing repository, which I thought was *reasonable* new), which keeps me from doing proper testing the way its meant to be done. I don’t have the time to compile the server software myselves. Instead, I work around this issue by creating the accounts manually everytime I run the test suite using a small bashscript.

I also had to deal with a really strange bug with file writing and reading. smack-omemo has a set of 4 integration tests, which all write data into a temporary directory. After each test, the directory is deleted to prevent tests influencing eachother. The issue was, that only the first test could read/write to the test directory. All subsequent tests failed for some reason. It took me a long time to notice, that there were two folders created (one in the working directory, another one in the subdirectory of the integration test framework). I am still not really sure what happened. The first folder was logged in all debug output, while files were written (by the first test) to the second filder. I guess it was caused by the temp directory being specified using a relative path, which messed up the tests, which were instanciated by the test framework using reflection. But I’m really not sure about this. Specifying the directory using an absolute path fixed the issue in the end.

Last but not least, me and Flow worked out some more details about my GSoC project (Implementing (encrypted) Jingle file transfer for Smack). The module will most likely be based upon java.nio to be scalable in the future. Flow also emphasized that the API should be as easy to use as possible, but at the same time powerful and extensible, which is a nice challenge (and probably a common one within the XMPP community). My initial plan was to create a XEP for OMEMO encrypted Jingle file transfer. We decided, that it would be of more value, to specify the XEP in a way, which allows arbitrary encryption techniques instead of being OMEMO exclusive.

Currently there is a little bit of tension in the community regarding the OMEMO specification. I really hope (and believe) there is a solution which is suitable of making everybody happy and I’m looking forward to participate in an open discussion :)

Happy hacking!

May 12 2017

Daniel Pocock: Thank you to the OSCAL team

The welcome gift deserves its own blog post. If you want to know what is inside, I hope to see you at OSCAL'17.

Daniel Pocock: Kamailio World and FSFE team visit, Tirana arrival

This week I've been thrilled to be in Berlin for Kamailio World 2017, one of the highlights of the SIP, VoIP and telephony enthusiast's calendar. It is an event that reaches far beyond Kamailio and is well attended by leaders of many of the well known free software projects in this space.

HOMER 6 is coming

Alexandr Dubovikov gave me a sneak peek of the new version of the HOMER SIP capture framework for gathering, storing and analyzing messages in a SIP network.

exploring HOMER 6 with Alexandr Dubovikov at Kamailio World 2017

Visiting the FSFE team in Berlin

Having recently joined the FSFE's General Assembly as the fellowship representative, I've been keen to get to know more about the organization. My visit to the FSFE office involved a wide-ranging discussion with Erik Albers about the fellowship program and FSFE in general.

discussing the Fellowship program with Erik Albers

Steak and SDR night

After a hard day of SIP hacking and a long afternoon at Kamailio World's open bar, a developer needs a decent meal and something previously unseen to hack on. A group of us settled at Escados, Alexanderplatz where my SDR kit emerged from my bag and other Debian users found out how easy it is to apt install the packages, attach the dongle and explore the radio spectrum.

playing with SDR after dinner

Next stop OSCAL'17, Tirana

Having left Berlin, I'm now in Tirana, Albania where I'll give an SDR workshop and Free-RTC talk at OSCAL'17. The weather forecast is between 26 - 28 degrees celsius, the food is great and the weekend's schedule is full of interesting talks and workshops. The organizing team have already made me feel very welcome here, meeting me at the airport and leaving a very generous basket of gifts in my hotel room. OSCAL has emerged as a significant annual event in the free software world and if it's too late for you to come this year, don't miss it in 2018.

OSCAL'17 banner

May 10 2017

Paul Schaub: GSoC: First week of community bonding

The first week of community bonding is nearly over and already it’s quite an experience for me. Me and Alameyo were very nicely welcomed by members of the igniterealtime project which really took care of making us able to jump right into the project.

I spent most of the time making myself more familiar with the Smack codebase by working on my OMEMO pull request, which comes closer and closer to a mergeable state. Currently I’m working together with my mentor Flo to make the API of the module as easy to use as possible. I learned the hard way, that singletons and generics are a pain when used together, but in the end it worked out quite well I’d say, although there is still some work left to do.

During the week, I also came across some bugs in XMPP server software, which were a great opportunity to come in contact with other developers outside of the igniterealtime project. Everybody was nice and helpful. Its really pleasant to work with the community.

Lastly, I also got in touch with some other GSoC students, which is super fun. I really enjoy meeting people from other countries and it turns out, that everybody puts their pants on the same way.

I’ll post updates roughly on a weekly basis to document the course of events. Untill then :)

Happy Hacking!

May 08 2017

Daniel Pocock: Visiting Kamailio World (Sold Out) and OSCAL'17

This week I'm visiting Kamailio World (8-10 May, Berlin) and OSCAL'17 (13-14 May, Tirana).

Kamailio World

Kamailio World features a range of talks about developing and using SIP and telephony applications and offers many opportunities for SIP developers, WebRTC developers, network operators and users to interact. Wednesday, at midday, there is a Dangerous Demos session where cutting edge innovations will make their first (and potentially last) appearance.

Daniel Pocock and Daniel-Constantin Mierla at Kamailio World, Berlin, 2017

OSCAL'17, Tirana

OSCAL'17 is an event that has grown dramatically in recent years and is expecting hundreds of free software users and developers, including many international guests, to converge on Tirana, Albania this weekend.

On Saturday I'll be giving a workshop about the Debian Hams project and Software Defined Radio. On Sunday I'll give a talk about Free Real-time Communications (RTC) and the alternatives to systems like Skype, Whatsapp, Viber and Facebook.

May 07 2017

Paul Schaub

Hi!

My name is Paul Schaub (vanitasvitae), I’m a computer science student from Münster, Germany, I’m 23 years old and right now I’m in my 8th semester.

I’m very close to getting my bachelors (undergraduate) degree with only one subject missing (Yay!). That’s why I got some spare time, which I am very happy to be able to spend as a GSoC (Google Summer of Code) student on the Smack project \o/!

 

In my free time, I’m involved in some free software projects mostly around Android apps. I’m currently one maintainer of the unofficial diaspora* app dandelion*. I also wrote the most likely unknown Android app EnigmAndroid which is a simulation of the Enigma machine.

 

My bachelors thesis was about implementing the OMEMO encryption protocol for the Smack library. The result is currently available as an open pull request (there’s still some work to do ). I chose this topic, because I believe that strong, easy to use encryption is very important for society. I’m very happy that the project worked out so great so far.

 

Within the GSoC, I’ll implement Jingle file transfer for Smack as well as finish up the OMEMO PR. Also I’ll try to find an elegant solution for OMEMO encrypted file transfer, which I’ll try to formalize into a (Proto-)XEP. Here you can find my GSoC proposal.

 

I’m always interested in making new contacts in the FOSS world, so if you have any questions or want to chat, don’t hesitate to contact me . You can find my contact information on my github page, but I’m also hanging out in the open_chat MUC.

 

Happy hacking!

Vanitasvitae

May 04 2017

Ignite Realtime Blog: Openfire 4.1.4 Release

The Ignite Realtime Community is proud to announce the 4.1.4 release of Openfire. This release signifies our continued effort to have a stable 4.1 release series while work progresses on the next major release.  A changelog exists denoting our 14 resolved issues and you can download the release builds from our website.  The following table contains a reference of release build files, their associated sha1sums and the number of times the previous release for that build type was downloaded.

OS sha1sum Filename Version 4.1.3 Downloads
Linux RPM (32bit JRE) 8846cd55047d9871ef9357568e0c1a9f43c41652 openfire-4.1.4-1.i686.rpm 3,293 Linux RPM (No JRE) 61a89afb66d74d523addbd238bf0c008ffada8aa openfire-4.1.4-1.noarch.rpm 2,249 Linux RPM (64bit JRE) 8f370c7e9dfe530f7d05d93122ca72b9b563c92c openfire-4.1.4-1.x86_64.rpm 12,142 Linux .deb 83bf090c07daeacb59a97ddade1cd76c1dbb3030 openfire_4.1.4_all.deb 15,714 Mac OS 37664eee2235748653ce070e873e5064a8e49bed openfire_4_1_4.dmg 4,095 Windows EXE 1f417e66ec7ec729ff60cada797d112267370826 openfire_4_1_4.exe 43,598 Binary (tar.gz) 6c8c262fbcc00c84bf86aab3787485e619757cc0 openfire_4_1_4.tar.gz 7,377 Binary (zip) 25763a8273a5d7a66e322b3515c38dfa6c52dc6b openfire_4_1_4.zip 17,892 Source (tar.gz) 680aad9967cef70ba609bb82854b9f991c8cd9c5 openfire_src_4_1_4.tar.gz 1,872 Source (zip) 656ca8c2fe4679f340682e33e1042d6ae00f9ed3 openfire_src_4_1_4.zip 6,273

 

As a reminder, our development of Openfire happens on Github and we have an active MUC development chat hosted at  open_chat@conference.igniterealtime.org. We are always looking for more folks interested in helping out, so please consider pitching in!

 

As always, please report any issues in the Community Forums and thanks for using Openfire!

April 27 2017

Peter Saint-Andre: RFC 8141: Uniform Resource Names

Long, long ago on an Internet far, far away, some forward-thinking technologists defined several different types of identifiers called Uniform Resource Locators URLs (for locating things on the Internet - say, an article published online) and Uniform Resource Names or URNs (for permanently naming things without necessarily locating them - say, identifying a book by its ISBN no matter where a physical or electronic copy might be located). Some years later, a grand unified theory of identifiers was formulated, leading to the creation of Uniform Resource Identifiers (URIs) including both URLs and URNs (and URCs, but who's ever heard of those?). Even though most URIs that we use today are URLs, URNs as specified in RFC 2141 have continued to be widely deployed, especially for bibliographic purposes and as XML namespace names. Because the communities that use URNs have felt the need to make some slight adjustments to the syntax and to align URNs with the formal definition of URIs, back in 2010 folks at the IETF decided to start work on a new document to obsolete RFC 2141. It took us 7 years (!), but here we are today with RFC 8141 to bring URNs into the modern age (almost exactly 20 years after the publication of RFC 2141 in 1997). Special thanks to John Klensin for co-editing this specification with me!...

April 22 2017

Tigase Blog: Experiences with Tigase Messenger for iOS

At heart I’m what people call a power user. When I started to use Tigase Messenger for iOS, I was a little reluctant to hand over status to the application, I typically like to have every conceivable feature at my fingertips – even if I don’t use them.

April 13 2017

Erlang Solutions: MongooseIM 2.1.0beta1 what happens when you give your team freedom

<p><a href="http://www2.erlang-solutions.com/l/23452/2017-04-12/4jzcbj">MongooseIM</a> is a highly technical platform for businesses to build messaging and social apps, or add messaging and social features to an existing app. The fullstack MongooseIM platform offers various components, both for the backend (Erlang, Elixir) and the frontend (iOS, Android, Web) for you to pick up and assemble like pieces of a puzzle. Today, the MongooseIM platform delivers a new beta version of the messaging server, as well as new push notification server.</p> <p>My name is Michał Piotrowski, and I&rsquo;m MongooseIM platform tech lead. With this blog post I&rsquo;d like to announce and describe our latest release. MongooseIM 2.1.0beta1 is one of the strongest releases I have ever worked on. It comes with new features on the XMPP level and it also contains much more internal, technical changes.</p> <p>For this release we created a <a href="http://mongooseim.readthedocs.io/en/2.1.0beta1/Roadmap">roadmap</a> and gave the team the freedom to implement it. The end result is not only implementation of most of the items from the roadmap but also many corresponding changes resulting in improved code quality or performance.</p> <h2>Push Notifications</h2> <h3>For mobile devices</h3> <p>These days most of instant messaging applications are mobile first or mobile only. To deliver great product for mobile devices you have to be able to send push notifications to offline users in one way or another. This was possible so far with the <a href="http://mongooseim.readthedocs.io/en/2.1.0beta1/modules/mod_http_notification/">mod_http_notification</a> module. The problem with this approach is that you need to create your own HTTP service talking to <code>APNS</code> or <code>FCM</code>.</p> <p>In this version we added support for push notifications as described in <a href="https://xmpp.org/extensions/xep-0357.html">XEP-0357: Push Notifications</a>. We also added a new service to our platform <a href="https://github.com/esl/MongoosePush">MongoosePush</a> which can be used to communicate with both APNS and FCM. Configuration of all the required components to enable push notifications is no laughing matter. That&rsquo;s why we create a detailed <a href="http://mongooseim.readthedocs.io/en/latest/user-guide/Push-notifications/">tutorial</a> on this topic.</p> <p>Thanks to this functionality you can enable push notifications in your application based on a standard way. There is no need to create ad-hoc, custom solutions.</p> <h3>For other services</h3> <p>In many cases you may want to get some of the events from MongooseIM in your other services. For example, to apply some business logic or implement a custom archive. Again, this was possible with MongooseIM so far by aforementioned mod_http_notification with the same limitations as described above.</p> <p>MongooseIM 2.1.0beta1 comes with a new and more flexible way to integrate with other services in the whole infrastructure. Thanks to <a href="http://mongooseim.readthedocs.io/en/2.1.0beta1/modules/mod_aws_sns/">mod_aws_sns</a> you can configure MongooseIM to push certain events to your Amazon SNS queues. The sky’s the limit in applying any business logic you may want on all the delivered events.</p> <h2>Full text search for MAM</h2> <p>Most modern instant messaging applications need full text search on the messages from archive. While not officially described in any XEP, it&rsquo;s possible to add custom queries to MAM requests for instant full text search. This is exactly what we did in MongooseIM 2.1.0beta1. With this version you can use custom field full-text-search in your MAM query to get all messages matching provided pattern. Complete example can be found in <a href="https://github.com/esl/MongooseIM/pull/1136">the PR</a> implementing this functionality. Be warned, this has its limitations:</p> <ul> <li>It works only with MySQL, PostgreSQL or Riak KV backends.</li> <li>MySQL and PostgreSQL implementation is not the most efficient as it&rsquo;s based on SQL&rsquo;s full text search.</li> </ul> <p>Please take a look at <a href="http://mongooseim.readthedocs.io/en/2.1.0beta1/modules/mod_mam/">mod_mam</a> documentation to see how to enable this feature.</p> <h2>Continuous load testing</h2> <p>In developing the MongooseIM platform we are always focused on the quality of our product. That&rsquo;s why we integrated MongooseIM with services like <a href="https://travis-ci.org/esl/MongooseIM">travis-ci</a>, <a href="https://coveralls.io/github/esl/MongooseIM">coveralls.io</a> and <a href="http://gadget.inakalabs.com">gadget-ci</a> a long time ago. Thanks to these improvements, every single change is properly tested. Code quality and test coverage are also monitored to ensure we deliver the best possible quality.</p> <p>For the past few months we&rsquo;ve been working on another service which helps us deliver better products. <a href="http://tide.erlang-solutions.com">Tide</a> is our own service integrated with MongooseIM build pipeline. Thanks to this service we are able to continuously load test our pull requests to see the performance impact of proposed changes.</p> <h2>XMPP pipelining</h2> <p>The usual way of connecting to a XMPP server is based on a request response pattern. The client sends a stanza, waits for the reply from the server and then sends another stanza. This is required when the client connects to a server for the first time. Many things about the server capabilities are not known to the client so it needs to wait for the response to proceed. When communicating with familiar server, where the clients know about all the features provided by it, almost all initial requests can be combined in one request.</p> <p>This improves connection or re-connection times significantly. Following diagrams shows re-connection time (with stream resumption) with and without pipelining.</p> <p><img src="https://s3.amazonaws.com/uploads.hipchat.com/15025/1282540/SJcJKBIyYrvSdSo/diagram.png" alt="Reconnection speed with and without pipelining"></p> <p>As you can see the reconnection time with pipelining takes <strong>at most</strong> less than <strong>50ms</strong> while without pipelining it&rsquo;s at least <strong>150ms</strong>.</p> <p>This improvement doesn&rsquo;t come for free though. These changes increase MongooseIM&rsquo;s memory consumption. Tests on our Tide platform before and after the change was merged shows that MongooseIM consumes around 200Mb more memory on a load test with 50K users.</p> <h2>Erlang distribution over TLS</h2> <p>Many of our customers were asking if it’s possible to encrypt the communications between Erlang nodes in the cluster. They need this for various reasons, and improved security is always an important factor when deciding whether to encrypt Erlang traffic or not.</p> <p>Our answer to this problem is yes, it&rsquo;s possible. Magnus Henoch already described how to do this for Erlang in general in his <a href="https://www.erlang-solutions.com/blog/erlang-distribution-over-tls.html">blog post</a>. Starting from there we extended MongooseIM to simplify such encrypted setup and add it to 2.1.0beta1. Detailed documentation on how to encrypt Erlang traffic for your MongooseIM cluster you can read in the <a href="http://mongooseim.readthedocs.io/en/2.1.0beta1/operation-and-maintenance/tls-distribution/">Distribution over TLS</a> guide.</p> <p>You can expect a dedicated blog post with load test results on this topic in the near future. <a href="http://www2.erlang-solutions.com/emailpreference">Sign up to the Erlang Solutions Newsletter</a> to be notified of this blog post when it’s published. </p> <h2>Changelog</h2> <p>Please feel free to read the detailed <a href="https://github.com/esl/MongooseIM/releases/tag/2.0.1">changelog</a>, where you can follow links and find the code changes.</p> <h2>Special thanks to our contributors!</h2> <p>Special thanks to our contributors: <a href="https://github.com/astro">@astro</a>, <a href="https://github.com/aszlig">@aszlig</a>!</p> <h2>Next?</h2> <h3>From beta1 to final release through beta2</h3> <p>This release is a beta which means we are still adding a lot of changes before final release. We work to ensure that our product is as high a quality as possible with every change - I strongly recommend giving this beta a try. This also means that you can influence the final 2.1.0 release by giving us your feedback.</p> <h3>Peer to peer or mediated binary streaming</h3> <p>We will deliver an ICE/STUN/TURN server, coded in Elixir, to allow peer to peer and one to one media streaming, like voice, video, screen sharing, and whiteboarding. The signalling part, named <a href="https://xmpp.org/about/technology-overview.html#jingle">Jingle</a>, is already available.</p> <h2>Test our work on MongooseIM 2.1.0beta1 and share your feedback</h2> <ul> <li>Star our repo: <a href="https://github.com/esl/MongooseIM">github.com/esl/MongooseIM</a></li> <li>Follow us on Twitter: <a href="https://twitter.com/MongooseIM/">twitter.com/MongooseIM</a></li> </ul>

April 12 2017

Daniel Pocock: What is the risk of using proprietary software for people who prefer not to?

Jonas Öberg has recently blogged about Using Proprietary Software for Freedom. He argues that it can be acceptable to use proprietary software to further free and open source software ambitions if that is indeed the purpose. Jonas' blog suggests that each time proprietary software is used, the relative risk and reward should be considered and there may be situations where the reward is big enough and the risk low enough that proprietary software can be used.

A question of leadership

Many of the free software users and developers I've spoken to express frustration about how difficult it is to communicate to their family and friends about the risks of proprietary software. A typical example is explaining to family members why you would never install Skype.

Imagine a doctor who gives a talk to school children about the dangers of smoking and is then spotted having a fag at the bus stop. After a month, if you ask the children what they remember about that doctor, is it more likely to be what he said or what he did?

When contemplating Jonas' words, it is important to consider this leadership factor as a significant risk every time proprietary software or services are used. Getting busted with just one piece of proprietary software undermines your own credibility and posture now and well into the future.

Research has shown that when communicating with people, what they see and how you communicate is ninety three percent of the impression you make. What you actually say to them is only seven percent. When giving a talk at a conference or a demo to a client, or communicating with family members in our everyday lives, using a proprietary application or a product or service that is obviously proprietary like an iPhone or Facebook will have far more impact than the words you say.

It is not only a question of what you are seen doing in public: somebody who lives happily and comfortably without using proprietary software sounds a lot more credible than somebody who tries to explain freedom without living it.

The many faces of proprietary software

One of the first things to consider is that even for those developers who have a completely free operating system, there may well be some proprietary code lurking in their BIOS or other parts of their hardware. Their mobile phone, their car, their oven and even their alarm clock are all likely to contain some proprietary code too. The risks associated with these technologies may well be quite minimal, at least until that alarm clock becomes part of the Internet of Things and can be hacked by the bored teenager next door. Accessing most web sites these days inevitably involves some interaction with proprietary software, even if it is not running on your own computer.

There is no need to give up

Some people may consider this state of affairs and simply give up, using whatever appears to be the easiest solution for each problem at hand without thinking too much about whether it is proprietary or not.

I don't think Jonas' blog intended to sanction this level of complacency. Every time you come across a piece of software, it is worth considering whether a free alternative exists and whether the software is really needed at all.

An orderly migration to free software

In our professional context, most software developers come across proprietary software every day in the networks operated by our employers and their clients. Sometimes we have the opportunity to influence the future of these systems. There are many cases where telling the client to go cold-turkey on their proprietary software would simply lead to the client choosing to get advice from somebody else. The free software engineer who looks at the situation strategically may find that it is possible to continue using the proprietary software as part of a staged migration, gradually helping the user to reduce their exposure over a period of months or even a few years. This may be one of the scenarios where Jonas is sanctioning the use of proprietary software.

On a technical level, it may be possible to show the client that we are concerned about the dangers but that we also want to ensure the continuity of their business. We may propose a solution that involves sandboxing the proprietary software in a virtual machine or a DMZ to prevent it from compromising other systems or "calling home" to the vendor.

As well as technical concerns about a sudden migration, promoters of free software frequently encounter political issues as well. For example, the IT manager in a company may be five years from retirement and is not concerned about his employer's long term ability to extricate itself from a web of Microsoft licenses after he or she has the freedom to go fishing every day. The free software professional may need to invest significant time winning the trust of senior management before he is able to work around a belligerant IT manager like this.

No deal is better than a bad deal

People in the UK have probably encountered the expression "No deal is better than a bad deal" many times already in the last few weeks. Please excuse me for borrowing it. If there is no free software alternative to a particular piece of proprietary software, maybe it is better to simply do without it. Facebook is a great example of this principle: life without social media is great and rather than trying to find or create a free alternative, why not just do something in the real world, like riding motorcycles, reading books or getting a cat or dog?

Burning bridges behind you

For those who are keen to be the visionaries and leaders in a world where free software is the dominant paradigm, would you really feel satisfied if you got there on the back of proprietary solutions? Or are you concerned that taking such shortcuts is only going to put that vision further out of reach?

Each time you solve a problem with free software, whether it is small or large, in your personal life or in your business, the process you went through strengthens you to solve bigger problems the same way. Each time you solve a problem using a proprietary solution, not only do you miss out on that process of discovery but you also risk conditioning yourself to be dependent in future.

For those who hope to build a successful startup company or be part of one, how would you feel if you reach your goal and then the rug is pulled out underneath you when a proprietary software vendor or cloud service you depend on changes the rules?

Personally, in my own life, I prefer to avoid and weed out proprietary solutions wherever I can and force myself to either make free solutions work or do without them. Using proprietary software and services is living your life like a rat in a maze, where the oligarchs in Silicon Valley can move the walls around as they see fit.

Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.

Don't be the product, buy the product!

Schweinderl