Agregador de noticias

Thijs Alkemade: Validate the encoding before passing strings to libcurl or glibc

Planet Jabber - 17 April, 2015 - 18:00

Lets start with a simple example in php:

curl.php

setlocale(LC_ALL, "nl_NL.UTF-8"); $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $_GET["url"]); curl_exec($ch);

This code is broken, can you tell how?

But it’s not just php or libcurl, lets try glibc.

addr.c

#include <sys/types.h> #include <sys/socket.h> #include <netdb.h> #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <string.h> #include <locale.h> #define BUF_SIZE 500 int main(int argc, char *argv[]) { struct addrinfo hints; struct addrinfo *result, *rp; int sfd, s, j; size_t len; ssize_t nread; char buf[BUF_SIZE]; setlocale(LC_ALL, "nl_NL.UTF-8"); if (argc < 3) { fprintf(stderr, "Usage: %s host port msg…\n", argv[0]); exit(EXIT_FAILURE); } /* Obtain address(es) matching host/port */ memset(&hints, 0, sizeof(struct addrinfo)); hints.ai_family = AF_UNSPEC; /* Allow IPv4 or IPv6 */ hints.ai_socktype = SOCK_DGRAM; /* Datagram socket */ hints.ai_flags = AI_IDN; hints.ai_protocol = 0; /* Any protocol */ s = getaddrinfo(argv[1], argv[2], &hints, &result); if (s != 0) { fprintf(stderr, "getaddrinfo: %s\n", gai_strerror(s)); exit(EXIT_FAILURE); } }

This is a slight modification of the example from the man page for getaddrinfo and it is broken in the exact same way.

libidn

The common factor is that both use libidn (well, glibc contains an in-tree copy of libidn, but the essence of it is the same). libidn is a library with various Unicode related funtions. For example, it can convert internationalized domain names (IDNs) to punycode. This is what converts яндекс.рф to xn--d1acpjx3f.xn--p1ai, which contains only characters that can be used safely by the DNS.

The idna_to_ascii_8z documentation states:

Convert UTF-8 domain name to ASCII string. The domain name may contain several labels, separated by dots. The output buffer must be deallocated by the caller.

The libidn docs www.gnu.org/software/libidn/…

As it turns out, the effect of passing a string that is not valid UTF-8 to any of the libidn functions that expects an UTF-8 string can be disastrous. If the passed in data ends with an unfinished UTF-8 codepoint, then libidn will continue reading past the terminating null-byte. There could be unrelated information just past that byte, which then gets copied into the result. This could leak private information from the server!

For example, the UTF-8 encoding of ф is, in hex:

d1 84

In fact, any valid UTF-8 sequence that starts with d1 should always consist of 2 bytes. But if we pass:

d1 00

instead, then it will instead interpret this as if it was passed:

d1 80

and it continues reading whatever is after our input.

The locale

Some applications don’t use idna_to_ascii_8z, but idna_to_ascii_lz instead. The documentation for idna_to_ascii_lz states:

Convert domain name in the locale’s encoding to ASCII string. The domain name may contain several labels, separated by dots. The output buffer must be deallocated by the caller.

The libidn docs www.gnu.org/software/libidn/…

However, this is no problem if the locale is already an UTF-8 locale (which is why the examples needed the setlocale calls): if the new locale and the old locale are identical, then no conversion is happening, which means the invalid data is not caught.

Impact

The effect of the php code above when passed a domain name with invalid UTF-8 is that a DNS request is started for a domain which contains extra data.

It is possible that this data contains passwords or fragments of a key, however, it has to continue to look UTF-8-like to libidn, so it is unlikely to continue on as long as Heartbleed could (for example, multiple successive null-bytes will stop the conversion). But it could easily allow an attacker to bypass ASLR.

The stringprep functions in libidn are affected by the same issue. These are used, for example, to normalize usernames and passwords. Here, it could allow an attacker to reuse parts of the password from a previous login.

Luckily, the AI_IDN flag of glibc is off by default, and I could not find many applications that ever set it.

So who should check it?

The libidn developers show little motivation to fix this, pointing the blame to applications instead:

Applications should not pass unvalidated strings to stringprep(), it
must be checked to be valid UTF-8 first. If stringprep() receives
non-UTF8 inputs, I believe there are other similar serious things that
can happen.

Simon Josefsson www.mail-archive.com/…

But the libcurl and glibc developers can pass on the blame to the layer above just as easily. The man page for getaddrinfo says:

AI_IDN - If this flag is specified, then the node name given in node is converted to IDN format if necessary. The source encoding is that of the current locale.

libcurl’s CURLOPT_URL says nothing about the required encoding.

This is a very messy situation, and so far nobody has shown any motivation to work on fixing it. So the best approach seems to be to fix end-applications to always validate strings to be valid in the current locale before passing them to libraries that require that. How many php developers are likely to do that? How many applications are out there that depend on getaddrinfo? Of course that’s unlikely, so I hope the glibc/libcurl/libidn developers figure something out.

Peter Saint-Andre: Purposes

Planet Jabber - 17 April, 2015 - 00:00
During a conversation not long ago with my friend Sarah, she mentioned the view of author John Maxwell that you cannot be a success in life unless you know your purpose, as in the one and only reason you are here on this earth.

ProcessOne: Embedding ejabberd into an Elixir Phoenix Web application

Planet Jabber - 14 April, 2015 - 14:59

By combining Elixir powerful web framework with ejabberd realtime messaging platform, you can build extremely powerful applications. This tutorial will help you get started.

Here is the screencast showing the whole process. Please read further for detailed step-by-step description and code.

Create a Phoenix application

The first step is to create your Phoenix application as usual.

First, you need to install Elixir 1.0.2+.

From there you can clone and build Phoenix framework:

prompt> git clone https://github.com/phoenixframework/phoenix.git && cd phoenix && git checkout v0.10.0 && mix do deps.get, compile

Finally, you can generate your Phoenix application template:
prompt> mix phoenix.new /Users/mremond/demo/my_app

Please refer to Phoenix web site to learn more about it: Getting started with Phoenix.

Add ejabberd as a dependency for your application

You have two simple changes to perfom in your application mix.exs initial file:

  1. Add ejabberd as a dependency for your application:
... defp deps do [{:phoenix, "~> 0.10.0"}, {:phoenix_ecto, "~> 0.1"}, {:postgrex, ">= 0.0.0"}, {:cowboy, "~> 1.0"}, {:ejabberd, ">= 15.03.0", github: "processone/ejabberd"}] end ...
  1. Tell mix to start ejabberd when you launch your application:
... def application do [mod: {Phoenixtest, []}, applications: [:phoenix, :cowboy, :logger, :ejabberd]] end ...
  1. Download and build all dependencies:
    prompt> mix do deps.get, compile

For reference, here is the complete mix.exs

Before you can start your application, you need to configure ejabberd.

Configure your application and ejabberd

Copy ejabberd.yml example file in application config/ directory. I put that file in a gist online to make that step easier:
prompt> (cd config; wget https://gist.githubusercontent.com/mremond/383666d563025e86adfe/raw/723dfa50c955c112777f3361b4f2067b76a55d7b/ejabberd.yml)

You can tweak ejabberd config file to adapt it to your needs. Please, refer to ejabberd operation guide to configure it properly.

You also need to configure your Elixir application to tell it how to set global ejabberd values like configuration file, log directory and Mnesia file directory. In the file config/config.exs, add specification ejabberd configuration for integration in your application:

... config :ejabberd, file: "config/ejabberd.yml", log_path: 'logs/ejabberd.log' # Customize Mnesia directory: config :mnesia, dir: 'mnesiadb/' ...

Make sure the directory where to place ejabberd log file does exist. If this is not the case, it will not be automatically created and no log file will be generated.

prompt> mkdir logs

Start your application

You can now start your application:

prompt> iex -S mix phoenix.server

As you see from the log printout, ejabberd is started along with your Elixir app.

You can create a user by entering the following command from Elixir command line:

iex(1)> :ejabberd_auth.try_register("mickael", "localhost", "mypass")
{:atomic, :ok}

You can connect with those credential from an XMPP client.

You can also connect on Elixir web server on http://localhost:4000/

Creating a page displaying ejabberd information

Let’s get started writing a Phoenix basic page that display ejabberd information.

In your project, edit the file web/router.ex and add a reference to a /ejabberd page in the my_app scope:

get "/ejabberd", EjabberdController, :index

The scope “/” block of our router.ex file should now look like this.

scope "/", MyApp do pipe_through :browser # Use the default browser stack get "/", PageController, :index get "/ejabberd", EjabberdController, :index end

Let’s then create the file web/controllers/ejabberd_controller.ex:

defmodule MyApp.EjabberdController do use MyApp.Web, :controller # This is used to import the jid record structure from ejabberd: require Record Record.defrecord :jid, Record.extract(:jid, from: "deps/ejabberd/include/jlib.hrl") plug :action def index(conn, _params) do # get online jid, parse and extract the user part. online_users = :ejabberd_sm.connected_users |> Enum.map &(jid(:jlib.string_to_jid(&1), :user)) render conn, "index.html", users: online_users end end

The code doing the heavy duty job the one getting online user by JID and extracting the username. This is a couple of lines of code:

# get online jid, parse and extract the user part. online_users = :ejabberd_sm.connected_users |> Enum.map &(jid(:jlib.string_to_jid(&1), :user))

We do not need anything fancy in our Phoenix view module and we will use default view placeholder web/views/ejabberd_view.ex:

defmodule MyApp.EjabberdView do use MyApp.Web, :view end

Note: I could have put some data conversion code in the view code, but as the code is short, I preferred to have all the relevant ejabberd related code in one place.

Finally, we need the template for the page, named web/templates/ejabberd/index.html.eex:

<div class="jumbotron"> <h2>Hello World, ejabberd meets Phoenix !</h2> <h3>Here is the list of online users:</h3> < %= for user <- @users do %> <p>< %= user %></p> < % end %> </div>

After starting the Phoenix server (iex -S mix phoenix.server) and connecting to the server using your XMPP client, you should see a page like the following:

Conclusion

Here you are. This is all for this tutorial. You should now have environment properly set to start developing amazing ejabberd and XMPP powered web applications.

As you have seen, in a matter of minutes, you were able to create a powerful web app integrating ejabberd XMPP framework. By merging Phoenix and ejabberd, a whole new set of applications can emerge. We are eager to see what amazing apps you will build with it.

Special thanks to Sonny Scroggin (@scrogson) for the discussion and inspiration for this tutorial and video :)

References

ProcessOne: Paris ejabberd meetup #2 is tomorrow !

Planet Jabber - 14 April, 2015 - 10:13

Our second Paris ejabberd meetup will take place tomorrow, april 15th, in ProcessOne office.

We will talk about ejabberd latest features and share our vision for ejabberd future. You are also very welcome to join to introduce your project.

You can register on Paris ejabberd Meetup page.

See you there !

Ignite Realtime Blog: Announcing Openfire 3.10.0 Release Candidate

Planet Jabber - 11 April, 2015 - 02:48

The Ignite Realtime Community is pleased to announce a release candidate build of the upcoming 3.10.0 release.  A lot of work has gone into this RC since the beta release a few months back and with your help testing, we are hoping to turn around a full 3.10.0 release very soon!  Here are some of the highlights since the beta:

 

  • OF-885 : Use non-blocking, async IO for BOSH connections
  • OF-893: Fix mutual authentication for BOSH
  • OF-869: Update Jetty to version 9.2
  • OF-877: BOSH connector does not properly restart after configuration change

 

For those of you that track our progress on Github, we are starting a new approach for development going forward.  An Openfire 3.10 branch has been created and the hope is that we will not have feature creep in this branch, but instead focus on stability and be able to make point releases when the situation warrants.  In the past, Openfire's point releases (ie 3.9.0 to 3.9.1) was a mixture of bug fixes and new features.  The new features will appear in other branches with an eye toward a future 3.11 or 4.0 release!  We are always looking for more folks to help develop Openfire, so please send us those pull requests and stop by our XMPP MUC room open_chat@conference.igniterealtime.org to say hi.

 

So please test this RC and report issues you find in the Openfire Support ForumDo not report issues by commenting on this blog post please!

 

Here is a listing of download links and md5sums for this release.  You can find these also on our beta download page.

 

md5sumFilename

4a3df600610ba64698c74e35d295b2e4

JSopenfire-3.10.0.rc-ALL.pkg.gz747e5a890cd672883ed69677989bac6copenfire-3.10.0.rc-1.i386.rpmddf2fc93ad0a5c01e9f41860aeac90ad openfire_3.10.0.rc_all.debc090d23a5cb685ddfb01b6a1074b384aopenfire_3_10_0_rc.dmg81d05bf6e20b9f8f6a9eeab16d6b843dopenfire_3_10_0_rc.exe734b5c3085c828531bc2f3cc610941a7openfire_3_10_0_rc.tar.gz2a346d0f9b691d96978dd93e79484642 openfire_3_10_0_rc.zipe7c84d7714f53f493cd6eccb4b1759ebopenfire_src_3_10_0_beta.tar.gz9d1ab61f11f74bbafbd0efe6c4d93b95openfire_src_3_10_0_beta.zipd4e38827c630bb57171f632f069003b2openfire_src_3_10_0_rc.tar.gze05a13587987b0ab24325b435d04243bopenfire_src_3_10_0_rc.zip

 

Happy testing!

yaxim: yax.im DNS Issues

Planet Jabber - 10 April, 2015 - 15:11

Currently, the yax.im service is experiencing connectivity problems (“remote-server-not-found” or “connection-timeout” on server-to-server links, “Unable to resolve yax.im” on clients) due to a DNS problem.

To support DNSSEC, we are moving the yax.im and yaxim.org domains to a different set of nameservers. It looks like the old nameservers for yax.im stopped resolving the domain before the 72h transition period was over; a support ticked has been opened for this. Please bear with us (or flush your resolver cache) until the issue has been fixed.

ProcessOne: ejabberd Meetups: From San Francisco to Paris

Planet Jabber - 9 April, 2015 - 13:59

Thank you all for joining us for our first meetup in San Francisco !

Here are the slides of the talks given during ejabberd San Francisco Meetup in march 2015.

A vision for ejabberd

This is Mickaël Rémond presentation on latest achievements and progress made on ejabberd during the last few months. He then shared his vision about the next steps to bring ejabberd XMPP platform to the next level.

A vision for ejabberd – ejabberd SF Meetup Archipel project introduction

This is slide deck for talk given by Archipel Project Team, with Nicolas Ochem as speaker. It introduces the concept behind Archipel, a solution to manage and supervise virtual machines based on XMPP.

Archipel Introduction – ejabberd SF Meetup from Mickaël Rémond

Second ejabberd Meetup in Paris

For those who can join us at Paris ejabberd meetup #2 on april 2015, 15th, we will follow up on ejabberd features and roadmap.

You can register on Paris Meetup page.

See you there !

buddycloud: 10 Day Challenge: Build a mobile social network

Planet Jabber - 7 April, 2015 - 11:32
Day 1: Scoping the features


We’ve already had a few conversations about what Project Isizwe wants to achieve.

We are helping them create the backend messaging for ‘WiFi Chat’. Wifi-Chat is a localised social network which allows the Government to have real-time conversations with citizens and opens up the opportunity to meet and chat online.

There are a few ways to think about how we plan the features in a limited time span:

  • perfect code, but nothing shipped
  • completely hacked code, but shipped
  • perfect code, with some working features and the rest on a road map

We decided on option 3.

So we sat down with the Isizwe team to talk through the launch features and are now working to get them written.

In terms of helping the end-user, we came up with the following features:

  • status sharing (similar to twitter),
  • Buddycloud channels for different conversations,
  • users will be able to create their own profile on WiFi Chat and upload an avatar (pic),
  • government will be able to create Chat Channels for any relevant discussion topic that they would like,
  • users will be able to join these Chat Channels and provide real-time feedback,
  • government will be able to create individual channels for each District, Municipality, City or Town under which multiple chat discussions will be ongoing.

(our working document)

Wifi-Chat’s features are interesting because we’re having to design it for very low-end devices. We also have to account for some users that might not have used such a service before. This shows up in the little design elements: a “hamburger menu” is replaced with just text saying “menu”. We’ll find out more on Monday when we meet some future users.

In other news, we’re staying at a lion farm, eating lots of biltong and enjoying the weather.

You can follow our code at https://github.com/project-isizwe/wifi-chat and infrastructure at https://github.com/buddycloud/buddycloud-vm

Fanout Blog: Realtime API design guide

Planet Jabber - 2 April, 2015 - 16:53
New to the subject of realtime APIs? This article is the place to start! We'll discuss the most common design approaches and their pros/cons, as well as link to the documentation of 16 public realtime APIs that you can use for inspiration.

...

Isode: R16.3: Multi-Master Directory, XMPP Archive/Search & ACP127 support

Planet Jabber - 31 March, 2015 - 11:30

We’re pleased to announce the availability of Isode’s latest release, R16.3, which can be downloaded now from our website. R16.3 is a major Isode release which adds new capabilities across the entire Isode product range, including:

M-Vault

We’ve introduced a multi-master capability to M-Vault, complementing the single-master approach to replication defined in the X.500 protocols around which M-Vault was developed. M-Vault is the first directory to offer both multi-master and X.500.

M-Link

M-Link gains a new Archive Server for archive of all messages (including 1:1 chat, MUC and PubSub). XMPP clients can access archives using Message Archive Management (MAM) as defined in XEP-0313. M-Link also gains three new web applications:

  1. Message Archive Management, allowing browser-based access to information in the archive.
  2. Statistics, a lightweight monitoring alternative to the M-Link Console GUI.
  3. Forms Discovery and Publishing, for end-user publishing and display of FDP forms.

M-Link Statistics Web App

M-Switch

We’ve added gateway support for text based organisational message protocols, which we’re collectively describing as “ACP127”. The first release of this capability supports ACP127 and DOI 103S, a popular US variant, and enables conversion with STANAG 4406 (compliant to STANAG 4406 Annex D) and SMTP (following the MMHS over SMTP extensions).

In addition we’ve made extensive improvements to MConsole and M-Link Console to support the new M-Switch and M-Link family capabilities. For a full run-down of new capabilities in R16.3, please see the Product Release page. We’ll be publishing further blog posts over the coming weeks focusing on some of the new R16.3 capabilities.

Ignite Realtime Blog: Smack 4.1.0 released

Planet Jabber - 29 March, 2015 - 14:23

The Ignite Realtime community is very happy and proud to announce the release of Smack 4.1.0, our open source XMPP client library. Since Smack 4.1 is not binary compatible with Smack 4.0, i.e. it is not a drop-in replacement, make sure to have a look at the "Smack 4.1 Readme and Upgrade Guide".

 

Smack 4.1 marks a milestone in the development history of Smack, as its obsoletes aSmack, the build environment formerly required to port Smack to Android. Starting with 4.1, Smack is able to run natively and unmodified on Android.

 

A further release highlight, among many others, is the support for XEP-198: Stream Management. Note that like every new big feature, Stream Management is disabled by default.

 

The full changelog can be found at https://www.igniterealtime.org/builds/smack/docs/4.1.0/changelog.html, the javadoc is available accessible via https://www.igniterealtime.org/builds/smack/docs/4.1.0/javadoc/ and the documentation available at https://www.igniterealtime.org/builds/smack/docs/4.1.0/documentation/

 

We would like to thank everyone who provided feedback, bug reports and contributed. The developers and contributors for the 4.1.0 release, since 4.0.0 are:

 

$ git shortlog -sn 4.0.0..4.1.0

   631  Florian Schmaus

     4  Vyacheslav Blinov

     3  Anno van Vliet

     3  Daniele Ricci

     2  Georg Lukas

     2  Júlio Cesar Bueno Cotta

     2  lucastucchi

     2  vito-c

     1  Abmar Barros

     1  Anno

     1  Chris Deering

     1  Christoph Fiehe

     1  Gilles Cornu

     1  Gligor Selimovic

     1  Jae Jang

     1  Luke GB

     1  atsykholyas

 

The signed tag used to upload the 4.1.0 artifacts to Maven Central points to 4bb8aea2815ceaab4224d1e2c3d80ba70c1f3803. As always, Smack 4.1.0 is available via Maven Central.

 

Now go ahead and implement a open source XMPP client with Smack. Be it for Android or one of the many platforms supported by Java. But even more importantly, provide feedback and help to improve Smack. We try our best to make Smack one of the best, stable and reliable open source libraries for XMPP, but it's far from being perfect. Join #smack (freenode) and discuss with us how Smack could be improved.

 

Happy Hacking.

buddycloud: 10 Day Challenge: Build a mobile social network

Planet Jabber - 26 March, 2015 - 19:43

Tomorrow morning some of the Buddycloud team departs from Berlin, Germany, for Johannesburg, South Africa.

We’re excited to build a production-ready mobile social network for Project Isizwe, including user and group communication: backend, frontend, message synchronisation in just 10 days. This is amazingly fast and we’re up against a very tight schedule.

Background

Project Isizwe provides free WiFi to township residents and has 500K users on their free wifi service. Now they want to help their users communicate, help and share information with each other. And more…  

Project Isizwe identified a big problem with how their users are being ignored by the government. They noticed two things:

  • there is no effective forum for feedback and debate between residents and the Government and,
  • the younger residents don’t feel they are heard through traditional government channels.

For example, younger residents never attend town-hall meetings and this leads to their voice being lost in the decision making.

The Project Isizwe team designed a solution called Wifi Chat and asked Buddycloud to help them with in-app messaging and social infrastructure to power this.

Wifi Chat will provide a real-time, secure and easy to use set of channels and site for informing citizens of new developments or topics and receiving feedback, input and comments.

Because messaging is really important to Project Isizwe’s strategy, they wanted to build wifi-chat as open source using open standards. This will enable their developers  to extend the Buddycloud to new in-house apps. For example, various city Governments could integrate their own communication channels into one service.

They had us at “open and extensible” and we offered to jump in and help and learn about their requirements.

Deciding to use a ready-made backend like Buddycloud has immediately saved at least a year of development time. That means our time in SA can be used to just spin-up a ready-made Buddycloud stack on their network and leaves us free to focus on developing the frontend.

And so to the frontend: we’re up against some interesting challenges:

  • lots of low end devices
  • web only

To give you an idea of the devices we’re dealing with here’s a selection:

Phone modelShareOSVersionScreen sizeHuawei Y220-U0011.3%Android2.3320x480Samsung GT-S5280 Galaxy Star4.5%Android4.1.2240x320Vodafone VF685 Smart Kicka4.3%Android4.4320x480Nokia Lumia 5204.2%Windows Phone8@2_240x400Samsung GT-S5301 Galaxy Pocket Plus3.7%Android4240x320ZTE V7953.2%Android2.3320x480BlackBerry Z102.8%BlackBerry10@2_384x640

This week we’ve been thinking about how to best create a realtime messaging solution on resource constrained devices. We’ve been going backwards and forwards on Angular, Backbone and other Javascript frameworks to work out what will best suit this project and enable us to ship in 10 days.

We’re going to work some magic

For quick spin-up of the backend, we’ll be using the Buddycloud-vm project to generate and orchestrate new server images for testing and production servers.

For the next 10 days we’ll be posting a daily development report covering the the technical challenges. You can start following our code progress starting on Monday as we push to https://github.com/project-isizwe/wifi-chat

Felix has already started working his interface magic and we’ll be posting more images as they fly off his machine.

See you on Monday!

Prosodical Thoughts: Prosody 0.9.8 released

Planet Jabber - 26 March, 2015 - 15:59

We are pleased to announce a new minor release from our stable branch. This release contains mainly bug fixes, including an important security fix.

A summary of changes in this release, by importance:

High:

  • Ensure only valid UTF-8 is passed to libidn. It was found (CVE-2015-2059) that libidn can read beyond the boundaries of the provided buffer when an input string contains invalid UTF-8 sequences.

Systems where Prosody is compiled with libICU are not affected by this issue.

Medium:

  • DNS: Fix traceback caused when DNS server IP is unroutable (issue 473)
  • HTTP client: More robust handling of chunked encoding across packet boundaries
  • Stanza router: Fix handling of 'error' <iq>'s with multiple children

Low:

  • c2s: Fix error reply when clients try to bind multiple resources on the same stream (issue 484)
  • s2s: Ensure to/from attributes are always present on stream headers, even if empty (issue 468)
  • Build scripts: Add --libdir option to ./configure to simplify building on some platforms
  • Fix traceback in datamanager when used outside of Prosody (e.g. in some migration tools)
  • mod_admin_telnet: Fix potential traceback in server:memory() command (issue 471)
  • HTTP server: Improved debug logging
Download

As usual, download instructions for many platforms can be found on our download page

If you have any questions, comments or other issues with this release, let us know!

Tigase Blog: Tigase Server 7.0.1 Release

Planet Jabber - 25 March, 2015 - 17:49
A maintenance version of Tigase XMPP Server (7.0.1) has been released. Binaries are available for download in the files section on the project tracking system.

ProcessOne: Elixir Sips: ejabberd with Elixir – Part 1

Planet Jabber - 25 March, 2015 - 16:26

Elixir Sips is an Elixir screencast website providing great tutorials to learn Elixir but also to help you build extraordinary pieces of code quickly with Elixir.

They produced a great series of videos on programming ejabberd with Elixir. Here is the material for the first part. We will publish more material on ProcessOne blog soon. Stay tuned !

Most of all, please, give us feedback in the comments on what you would like to see covered regarding ejabberd and Elixir… Or even better, come to see us live at upcoming ejabberd San Francisco Bay Area Meetup !

Here is the first ejabberd / Elixir tutorial (Part 1�) �by Josh Adams.�
Please note that part 2 of this tutorial is also available: Extending ejabberd with Elixir – Part 2.

Introduction

ejabberd is an XMPP server that is widely used to power either vanilla XMPP installs or XMPP-backed applications. It’s one of Erlang’s success stories, and it recently added Elixir support. Here is the blog post announcing Elixir support: ejabberd joins the Elixir revolution�.

Setup

I followed the blog post regarding compiling ejabberd with Elixir support.
Let’s see the support in action:

cd ~/my-ejabberd ./sbin/ejabberdctl iexlive iex(ejabberd@localhost)1> IO.puts "ejabberdSips!" ejabberdSips! :ok iex(ejabberd@localhost)2> :ejabberd_auth.try_register("elixirsips", "localhost", "mypass") {:atomic, :ok}

Alright, so we’ve registered a elixirsips user locally. Let’s see if our XMPP client can connect:

((( open up gajim, add account )))

So there, we’ve connected to the account with the user we added from Elixir.
Now the blog post says for us to build the smallest possible module, but they have already provided it for us.

cd ~/erlang/ejabberd vim lib/mod_presence_demo.ex defmodule ModPresenceDemo do import Ejabberd.Logger # this allow using info, error, etc for logging @behaviour :gen_mod def start(host, _opts) do info('Starting ejabberd module Presence Demo') Ejabberd.Hooks.add(:set_presence_hook, host, __ENV__.module, :on_presence, 50) :ok end def stop(host) do info('Stopping ejabberd module Presence Demo') Ejabberd.Hooks.delete(:set_presence_hook, host, __ENV__.module, :on_presence, 50) :ok end def on_presence(user, _server, _resource, _packet) do info('Receive presence for #{user}') :none end end

Here you can see that, when enabled, this will announce presence for every user when they change presence. We didn’t see that happen when I connected, so it must not be enabled. Let’s open up the yaml configuration file:

cd ~/my-ejabberd vim etc/ejabberd/ejabberd.yml

In the modules section, add:

ModPresenceDemo: {}

Now we’ll restart and connect again. Now every time we change presence, an update gets logged.

This is the end of the introductory blog post. Let’s see if we can take it a little bit further. Open up the module again:

def on_presence(user, _server, _resource, packet) do info('Receive presence for #{user}') # We'll inspect the packet that we're sent in this event info(inspect packet) :none end

Now recompile everything and reinstall, and start it back up. Now I’ll connect again with my client and we’ll see what a presence packet looks like.

((( connect, mark yourself away with a given status )))

19:54:04.160 [info] Receive presence for elixirsips 19:54:04.161 [info] {:xmlel, "presence", [{"xml:lang", "en"}, {"id", "56"}], [{:xmlel, "priority", [], [xmlcdata: "40"]}, {:xmlel, "show", [], [xmlcdata: "away"]}, {:xmlel, "x", [{"xmlns", "vcard-temp:x:update"}], [{:xmlel, "photo", [], []}]}, {:xmlel, "c", [{"xmlns", "http://jabber.org/protocol/caps"}, {"node", "http://gajim.org"}, {"ver", "47EPEmSc9oqPGwcrbNtpKcYyJcE="}, {"hash", "sha-1"}], []}, {:xmlel, "status", [], [xmlcdata: "asdf"]}]}

So here we can see what an away presence message with a status looks like.
Let’s log it a bit nicer:

def on_presence(user, _server, _resource, packet) do info('Receive presence for #{user}') info(inspect(:xml.get_subtag(packet, "show"))) :none end

Now I’ll do my common happy-path “,t” thing and map that key combination to build and install the new plugin, so we can easily do that part, then restart the server every time we want to see a change:

:map ,t :!make && make install<cr>

Let’s use it, and restart the server. Now change our status a few times.

We can see that there’s no “show” subtag when we’re just available, but otherwise it maps to various defined states. Let’s also log the status if it exists:

def on_presence(user, _server, _resource, packet) do info('Receive presence for #{user}') info(inspect(:xml.get_subtag(packet, "show"))) info(inspect(:xml.get_subtag(packet, "status"))) :none end

We could do a bit more, but this shows a decent start. In the next episode, we’ll look at how you can filter packets as they pass through the system. See you soon!

Resources

Learn more about ejabberd development at upcoming ejabberd San Francisco Bay Area Meetup !

ProcessOne: Elixir Sips: ejabberd with Elixir – Part 2

Planet Jabber - 25 March, 2015 - 15:44

Elixir Sips is an Elixir screencast website providing great tutorials to learn Elixir but also to help you build extraordinary pieces of code quickly with Elixir.

They produced a great series of videos on programming ejabberd with Elixir. In the first part of that tutorial, you have learned how to set up Elixir support in ejabberd and write your first ejabberd module in Elixir. Here is the material for the second part in which you will learn how to leverage one of the most powerful ejabberd hooks: ejabberd packet filter.

We will publish more material on ProcessOne blog soon. Stay tuned !

Most of all, please, give us feedback in the comments on what you would like to see covered regarding ejabberd and Elixir… Or even better, come to see us live at upcoming ejabberd San Francisco Bay Area Meetup !

Here is the second ejabberd / Elixir tutorial (Part 2) �by Josh Adams.�

Introduction

In the last episode, we saw how to get notified of presence messages from users connected to the ejabberd server. Now we’re going to look at how we can modify messages as they are sent from user to user. Specifically, we’re going to build a module that makes everyone yell all the time.

Project

We’re going to just start where the last episode left off. Let’s add a new module first.

cp lib/mod_presence_demo.ex lib/filter_packet_demo.ex vim lib/filter_packet_demo.ex defmodule FilterPacketDemo do import Ejabberd.Logger # this allow using info, error, etc for logging @behaviour :gen_mod def start(_host, _opts) do info('Starting ejabberd module Filter Packet Demo') # NOTE: The second argument here is global Ejabberd.Hooks.add(:filter_packet, :global, __ENV__.module, :on_filter_packet, 50) :ok end def stop(_host) do info('Stopping ejabberd module Filter Packet Demo') # NOTE: The second argument here is global Ejabberd.Hooks.delete(:filter_packet, :global, __ENV__.module, :on_filter_packet, 50) :ok end def on_filter_packet({from, to, xml} = packet) do info("Filtering packet: #{inspect {from, to, xml}}") packet end end

Now I’ll compile it and install it with my ,t mapping.

Now let’s enable this module in our server. Open up the config in ~/my-ejabberd and add our new module.

Next let’s just start the ejabberd server:

./sbin/ejabberdctl iexlive

We’ll connect with two users and chat between them, and we’ll see all the packets that flow through ejabberd. Of course, we only really want to do anything to messages, so let’s restrict our hook to only catch those:

defmodule FilterPacketDemo do def on_filter_packet({from, to, xml={:xmlel, "message", _attributes, _children}} = packet) do info("Filtering message: #{inspect packet}") body = :xml.get_subtag(xml, "body") info(inspect body) packet end def on_filter_packet(packet), do: packet end

Compile and restart, send some messages, and now we only see info logs on our actual messages…You’ll note there’s an empty message sent every time we send one with a body as well. I believe this is just the confirmation of receipt of a given message.

We want to just write a filter that will upcase all of these messages, to begin with. To do that, all we would have to do is replace the body with the upcased body. Let’s think about how to do that. Basically, we would just want to map the children tags of the message, modifying the cdata if they match a certain tag name, and then use the mapped result as the children of the packet that we pass along. Let’s try that.

defmodule FilterPacketDemo do import Ejabberd.Logger # this allow using info, error, etc for logging @behaviour :gen_mod def start(host, _opts) do info('Starting ejabberd module Filter Packet Demo') Ejabberd.Hooks.add(:filter_packet, :global, __ENV__.module, :on_filter_packet, 50) :ok end def stop(host) do info('Stopping ejabberd module Filter Packet Demo') Ejabberd.Hooks.delete(:filter_packet, :global, __ENV__.module, :on_filter_packet, 50) :ok end def on_filter_packet({from, to, xml={:xmlel, "message", attributes, children}} = packet) do info("Filtering message: #{inspect packet}") new_children = Enum.map(children, fn(child) -> case child do {:xmlel, "body", [], [xmlcdata: text]} -> {:xmlel, "body", [], [xmlcdata: String.upcase(text)]} _ -> child end end) {from, to, {:xmlel, "message", attributes, new_children}} end def on_filter_packet(packet), do: packet end

Go ahead and compile it and restart the server, and let’s send some messages.

(( do that, note they are upcased ))

Summary

With that little bit of code, we’re able to modify the behaviour of this ejabberd server with respect to messages being sent. Obviously you could imagine how to do more interesting things here, but this was a pretty simple introduction into packet filtering with ejabberd. See you soon!

Resources

buddycloud: Announcing Buddycloud-VM: everything you need to run Buddycloud on premises.

Planet Jabber - 25 March, 2015 - 13:49

The Buddycloud virtual machine helps developers test and deploy Buddycloud.

While Buddycloud hosting is a great way to start building and testing in-app communication, sometimes you need more flexibility than cloud hosting.

The buddycloud-vm is a good way to spin-up your own on-premises messaging stack.

We have designed the buddycloud-vm to be flexible enough to build and deploy into your workstation or to deploy remotely into your own datacenter/ Amazon/Google/Digital Ocean servers.

Grab the latest version off Github. Community support is always available in the Buddycloud chatroom.

The XMPP Standards Foundation: Board goals for 2015

Planet Jabber - 23 March, 2015 - 09:51

When our newest Board of Directors were elected, they decided that they wanted to set some goals against which their achievements as Board members could be measured.

And so this journey began…

We started by asking the community what THEY cared about and what they wanted the Board to focus on.

We took this information, turned it into measurable objectives and then asked the community to vote – what did they think the most important areas to focus on? There was a lot of debate here, and we listened – the measurables could have been something else, there are other ways of looking at this etc – but, we had to commit to something or a year on we would still be working how to measure what we were doing!

And this is what got decided (the meeting minutes can be found here.)

% based goals

 

We recognised that there were two top scorers – website traffic and membership engagement. While membership engagement is of obvious importance, the Board felt that engagement would be covered by other activities and was possibly too inwardly focussed.

  • Decision: Website traffic
Binary goals
For our binary goal, there was a clear leader, although a difficult goal! How we achieve this goal needs more discussion, but the decision was unanimous.
  • Decision: IOT strategy
Soft goals While the ‘Benefits of federation’ was clearly the highest rated objective for our “soft goal”, the Board recognised that this was simply an aspect of XMPP positioning.
  • Decision: XMPP positioning

And that is where we are at. The % based goal and XMPP positioning are both being worked on at the moment, through the development of our new website.

We will keep you posted with our progress…

ProcessOne: ejabberd 15.03

Planet Jabber - 20 March, 2015 - 18:32

ejabberd 15.03 is yet another important release. We have added fixes and some major improvements.

You can learn more about the changes and roadmap by meeting part of the team in upcoming ejabberd San Francisco Meetup.

New features Websocket

Websocket support is among the major new features introduced in this release. You can write speedy XMPP web clients. This web support has been tested on large deployments and is extremely fast, with very low latency.

More details on ejabberd Guide – Websocket

Customizable session backends

We have introduced a new major feature to give more flexibility in the way sessions are managed in ejabberd. In the past, session were managed in Mnesia because it was the best compromise between speed, latency and scalability. However, ejabberd is deployed on a large variety of usage patterns and platform types and sizes. We thus have decided to provide more flexibility to accommodate with various use cases. For most deployments Mnesia is still the default choice and best backend to store sessions. For corporate deployments that need to get easy access to online users and status from other components, we provide a SQL backend for live sessions storage. Finally, if you want to avoid duplicating session across nodes to deploy a larger cluster, you can store your session information in a central, fast, in-memory backend like redis.

This improves scalability or flexibility depending on your platform type.

Security improvement: SCRAM support for SQL authentication backend

If you use the default ejabberd SQL authentication backend, you can now enable password encryption in the database using the standard SCRAM approach. We also provide a tool to migrate your existing authentication database to the new SCRAM secure scheme.

Development community and Elixir improvements

ejabberd 15.03 is also the continuation of 15.02 in the way it simplifies the development and management of contributed modules. The community is growing with more code being contributed by third party developers. You can already find many modules contributed by the community. And now you can even install contributed modules without having developer skills or module compilation.

Interest around ejabberd has been accelerating with the introduction of Elixir. This release improves Elixir support. Moreover, you can now write ejabberd tests in Elixir and they are ran transparently with the rest of the test suite.

Package management

This feature allows you to install easily ejabberd contributed module, with a simple command like:

$ ejabberdctl module_install modulename

You can find more details on this blog post: Easy installer and structure for ejabberd contributed modules

Simple add cluster command

With our constant desire to simplify deployment we added a new ejabberdctl command to add a node in a cluster in a single command. Those who went to the process of setting up a cluster will certainly love this new command:

$ ejabberdctl join_cluster ejabberd@existingnode

More details here: Adding a node in a cluster

Changelog overview

As a summary, here is the high level changelog:

  • Add support for WebSocket
  • Flexible session management with multiple backends: Mnesia/SQL/Redis or custom backend for session manager
  • Security improvement with SCRAM based password encryption in SQL authentication backends.
  • Package management for ejabberd contributed modules.
  • Improved Elixir experience
  • Automatic clustering scripts
  • Added missing index on database
  • Important updates on the documentation, with the launch of a new documentation site: docs.ejabberd.im
  • Several other bugfixes
MySQL database structure improvement

We were missing an index on privacy list in the default MySQL schema. The database schema has been updated.
If you want to apply the changes on a running instance, here is the SQL command to issue:

CREATE INDEX i_privacy_list_data_id USING BTREE ON privacy_list_data(id); 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 you found a bug, please search or fill a bug report on Github.

The XMPP Standards Foundation: Summit 17 – the presentations

Planet Jabber - 20 March, 2015 - 10:23

A slightly tardy share, but we have the presentations from Summit 17 in Brussels starting to trickle in!

As more come in, this post will get longer (and hopefully have a more permanent home on the new site) but here we go:

XMPP Research

With their active blog xmppresearch.org, researchers from RWTH Aachen University and TU Dresden are contributing to an ongoing collection of academic works around XMPP, including a high-quality bibliography, demos and reviews. Domink Renzel presented their work and their goals to the Summit members.

Blogging via XMPP

Sergey Dobrov walked us through federated blogging and a combination of XMPP & PubSub/PEP. The presentation includes a call-out for help, and hwo you can get involved.

 

We would love to showcase more of the presentations, so if you have anything from the Summit you would like to share, please get in touch!

Distribuir contenido