Agregador de noticias

Andreas Straub (GSoC 2015): Week 07 - Alpha

Planet Jabber - 15 July, 2015 - 13:42
Hey everyone!
The majority of this week was spent on getting the code ready for alpha. This meant refactoring the logging, so that we would better be able to diagnose potential problems from the logs people would send in, along with some more random code cleanup.

I encountered some tricky issues with my in-memory SessionCache being out of sync with the database, due to the roster not having been present when the cache is initially populated. This took quite a bit of fiddling around to figure out, and a few iterations to completely fix, because there are several non-obvious, distinct failure modes here.
I also worked on a bunch of little UI tweaks, mainly relating to session trust. If you recall from week 2, we had originally planned to decide trust on a per-session basis. The idea back then was that you would only ever build one session per contact, which would never be ended, so it seemed superfluous to trust the IdentityKey. After some deliberation, it turned out to be much more complicated to achieve this in a robust way, so we decided instead to implement trust on an IdentityKey basis. This meant shifting around some of the code, as well as changing the database schema.
All this work was needed so that message locks now show whether they originate from a trusted session. If the session is untrusted, the lock is colored red. The ContactDetailsActiviy now shows per-IdentityKey trust, along with a trust toggle button for every key.


In addition to TRUSTED and UNTRUSTED, I internally keep track of a third state, UNDECIDED, which all keys are set to initially. So far, this third state is treated the same as UNTRUSTED, but in a future update, if there are UNDECIDED keys, the send message button in axolotl-enabled conversations will spawn a new activity, prompting the user to either accept or reject the individual UNDECIDED keys, before sending the message.
My goals for the next week are implementing this TrustKeysActivity, fixing message delay tagging for axolotl messages, and a slight overhaul of the crypto code, which is still missing an HMAC.

Ignite Realtime Blog: Smack 4.1.3 released

Planet Jabber - 15 July, 2015 - 13:37

I've just released Smack 4.1.3 to Maven Central. This is a bugfix release which can act as drop-in replacement for any Smack 4.1 version. Users are encouraged to update since Smack 4.1.2 introduced a memory leak in the Roster API which was fixed in 4.1.3.

ProcessOne: Boxcar Android Developer SDK updated with GCM 3 support

Planet Jabber - 15 July, 2015 - 10:24

Boxcar Developer Push service was recently updated to support Google Cloud Messaging 3.0 (GCM 3).

Google changed the semantic of the identifier. They replaced the ad-hoc RegistrationID with a new Universal Identifier. Android Developer will need need our new Boxcar Android SDK 3.0 to support it.

You can find more details on Boxcar Developer Blog: New Boxcar Android SDK 3.0.0 and SDK 2.0.4 released

Adhish Singla (GSoC 2015): Week 7

Planet Jabber - 15 July, 2015 - 06:56
Objective Learning Cordova with Examples Abstract

Apache Cordova is a platform for building cross-platform applications using HTML, CSS and JavaScript.

This week I have tried various examples in order to have a better understanding of Cordova for the purpose of making an IoT Client application for Android and Apple iOS.

Work
  • Made a starting application that shows a alert message on starting.
  • Directory Application that stores the information locally and implement search on it.
  • Learn View Routing on Cordova.
  • Understand how to use Location, Contacts and Camera APIs using Cordova.
Images from Example Application

Road Ahead
  • Start with implementation of Application(Login, Strophe Connection, Retrieve Contacts).

Fanout Blog: Realtime API management with Pushpin and Kong

Planet Jabber - 14 July, 2015 - 23:59

Pushpin is the open source reverse proxy for the realtime web. One of the benefits of Pushpin functioning as a proxy is that it can be combined with an API management system, such as Mashape's Kong. Kong is the open source management layer for APIs. To use Kong with Pushpin, simply chain the two together on the same network path.

Why would you want to use an API management system with Pushpin? Realtime web services have many of the same concerns as request/response web services, and it can be helpful to centrally manage those aspects.

...

Christian Schudt: XMPP Real-time Text in Action

Planet Jabber - 8 July, 2015 - 19:18
XMPP Real-time Text is definitively one of the most fun XMPP extension out there, from user's point of view as well as from a developer's point of view! Recently I've added support for it in the upcoming version 0.6.0 and I thought I'd make a short video which demonstrates this cool new feature in action!

It shows how it could look like when two XMPP contacts are chatting with each other and having real-time text enabled. Enjoy!

Roughly speaking you have to create a new outbound real-time message and just update its text while typing:

// Create a chat session with another user.
Chat chat = xmppClient.getManager(ChatManager.class).createChatSession(contact);
RealTimeTextManager realTimeTextManager = xmppClient.getManager(RealTimeTextManager.class);
// Create an new RTT message.
OutboundRealTimeMessage realTimeMessage = realTimeTextManager.createRealTimeMessage(chat);
TextArea textArea = new TextArea();
textArea.textProperty().addListener((observable, oldValue, newValue) -> {
realTimeMessage.update(newValue);
});

When done typing, commit the message (which will send the current message as normal chat message):

realTimeMessage.commit();

On the receiver side, you can listen for it like this (and e.g. display it to a Label).

Label label = new Label();
// Upon receiving a RTT message, display it.
realTimeTextManager.addRealTimeMessageListener(e -> {
InboundRealTimeMessage rtt = e.getRealTimeMessage();
rtt.addRealTimeTextChangeListener(e1 -> Platform.runLater(() -> label.setText(e1.getText())));
});

Tarun Gupta (GSoC 2015): Week - 7

Planet Jabber - 8 July, 2015 - 16:32
This week was finally completing JID based on reviews and to merge it into master. I have completed Disco, Roster and Queries this week.
Disco specifies XMPP protocol extension for discovering information about other XMPP entities. There are two types of information which can be discovered: 
Firstly, identity and capability of an entity along with its features, and Secondly, items associated with an entity. 
For discovering information about a jabber entity, the requesting entity MUST send an IQ stanza of type "get", containing an empty <query/> element qualified by the 'http://jabber.org/protocol/disco#info' namespace, to the JID of the target entity. The target entity then MUST either return an IQ result, or return an error. The result MUST contain a <query/> element qualified by the 'http://jabber.org/protocol/disco#info' namespace, which in turn contains one or more <identity/> elements and one or more <feature/> elements.
For discovering items associated with an Jabber entity, it MUST send an IQ stanza of type "get" to the target entity, containing an empty <query/> element qualified by the 'http://jabber.org/protocol/disco#items' namespace. The target entity then MUST either return its list of publicly-available items, or return an error. The list of items MUST be provided in an IQ stanza of type "result", with each item specified by means of an <item/> child of a <query/> element qualified by the 'http://jabber.org/protocol/disco#items' namespace.
More information can be found here. I have added all functionalities provided in Swiften and also ported tests for the same.
In XMPP, one's contact list is called a roster, which consists of any number of specific roster items, each roster item being identified by a unique JID (usually of the form ). A user's roster is stored by the user's server on the user's behalf so that the user may access roster information from any resource.
The existing XMPP core protocol defines four <iq/> types (get, set, result, and error). Protocols complying with the <query/> action protocol use <iq/> 'set' to initiate all request-response interactions. The particular action to be taken MUST be set as an "action" attribute in the <iq/> <query/> sub-element.
So finally, I have completed all these three functionalities, i.e. Disco, Roster and Queries. Next up, I'll be doing VCards. And try to find the problem with ant, as it is not updating the required class files for the changes and hence resulting into unstable patches.

Adhish Singla (GSoC 2015): Week 6

Planet Jabber - 8 July, 2015 - 14:52
Objective History Request and its Visualization using ChartJs Abstract

History Request is sent to a Device with a FieldName so as to read its values over a period of time. Visualizing these Values can be usefull in many ways, like predicting Temperature Change based on the Previous Values of Temperature.

This Week we will use History to get Values of a Field over a period of time from a Device and Display them in the form of a Line Graph.

Work
  • Send a hardcoded History Query to a Device and get Values of Field over a particular period of Time.
  • Extend sending History Query from hardcoded to a command ‘/history day/week/month/year FieldName’ that can be sent to a device using ChatBox.
  • Parse the Message to Data of ChartJs Line Graph.
  • Display Graph as a message in the ChatBox.
Problems Faced and Work Arounds History Command not receiving any messages.
  • As this was a part of last week work, It was resolved by sending ‘SEQNR’ as a part of the History Query which is Unique Reference Number for the IQ to identify messages related to that IQ.
Final Output

GSOC MID-EVALUATION WEEK

So this is the time when the First GSOC Evaluation takes place. We have completed 90% of what was mentioned as part of Project Timeline. Also the Features Added to Converse can be tested by cloning dev_iot branch from here “https://github.com/adhish20/converse.js/tree/dev_iot” and setting up an Development Environment for it.

Road Ahead
  • Making a Mobile Application of an IoT Client using Apache Cordova.

Adhish Singla (GSoC 2015): Week 5

Planet Jabber - 8 July, 2015 - 14:06
Objective Write and History Requests Abstract

Write Request is sent to a Device JID to set a Field to a particular Numeric Value , for instance Relay of a Device, or “hue” of Philips Hue can be changed through a write command.

History Request is sent to a Device with a FieldName so as to read its values over a period of time.

This Week we will use Write to set numeric values to Device Fields and History to get Values of a Field over a period of time from a Device.

Work
  • Send a hardcoded Write Query to a Device and set a Field Value to a particular Value.
  • Extend sending Write Query from hardcoded to a command ‘/write FieldName Value’ that can be sent to a device using ChatBox.
  • Send a hardcoded History Query to a Device and get Values of Field over a particular period of Time.
Problems Faced and Work Arounds History Command not receiving any messages.
  • We tried sending various hardcoded History Queries to the Devices but they were not responding to the History Request.
Final Output

Road Ahead
  • We will complete implementing History and use ChartJs to Visualize the History in the form of a Line Graph.

Andreas Straub (GSoC 2015): Week 06 - UI

Planet Jabber - 8 July, 2015 - 12:22
Hey everybody, and welcome back to the progress update!

So we're just about to enter alpha testing stage with some of the active users in the Conversations community, and the work of the past week has been geared towards that. As work on the app itself has continued in parallel to my project, I first had to rebase my work on top of the current development HEAD, which was a bit of a pain due to some conflicts, but we made it through alright. 
There were a handful of little bugs, as well as some features that I had fudged during prototyping and had been planning on refining, that got addressed this week. The PEP devicelist is now checked (and potentially refreshed with our own deviceId) every time we receive a PEP devicelist update, rather than only on login. I fixed displaying contacts' IdentityKeys, which had broken when I migrated the underlying data storage last week.
There were also some tricky race conditions with the order of establishing sessions between devices that required me to bust out pen an paper and reason through the different states. Along with some additional fixes regarding own device sessions, I am now reasonably confident that the algorithm works for the "usual" cases. I'm looking forward to alpha testing, which will no doubt uncover a slew of edge cases that haven't been hit yet.
The bigger chunk of work was building some very basic UI controlling the PEP contents. During my testing so far, I have had to manually wipe PEP contents and the device's axolotl states many times so that I could test specific scenarios, because something got corrupted, or simply because through reinstalls, stale deviceIds kept piling up in the devicelist. Before going into alpha, I figured I had to build at least some very basic UI exposing these features to the testers, so that they wouldn't have to go in and manually compose stanzas to send to their servers. Right now, it is possible to
  • trigger a wipe and regeneration of local axolotl data
  • wipe all other devices than the current one from the PEP devicelist
I'm hoping that for the actual release build, we can find a cleaner solution to the problem of PEP management. I don't want the user to have to think about these issues. But for now, this will have to do.
I'm in the process of cleaning up my logging right now, so that logcat outputs submitted by the testers will be more helpful. Once that is done, we are going to ask a few select people to install an alpha build and start testing to gather bug reports and usability feedback. I will also continue to improve and expand the UI capabilities that I built this week. One important feature that is still missing is proper session trust handling. The underlying code is mostly there, but my mentor and I will need to figure out how to best expose it in the UI.

The XMPP Standards Foundation: Seeking new XSF Treasurer

Planet Jabber - 6 July, 2015 - 16:05
Until now, St Peter has been handling the XSF Treasurer role. He’s stepping down from the role and the XSF Board is looking for someone new. The role of Treasurer includes overall responsibility for the financial affairs of the XSF. The future treasurer would:
  • Maintain and monitor the XSF’s bank account with Wells Fargo NA
  • Maintain and monitor the XSF’s post office box
  • File income tax reports (Form 990) with the US IRS
  • Pay franchise taxes with the State of Delaware
  • Pay corporate registration fees with NRAI
  • Pay for relevant domain name registrations
  • Send invoices to XSF sponsors
  • Reimburse XSF members for approved out-of-pockets costs
  • Report on XSF finances to the Board of Directors
So we’re looking for someone new. If you or someone you know would be interested in serving as the treasurer (they don’t necessarily even have to be an XSF member), please get in touch with the board or me directly. It would be great to have this post filled! If you are interested, please get in touch with a member of the XSF Board.

Daniel Baczynski (GSoC 2015): Login window GUI

Planet Jabber - 6 July, 2015 - 15:43
New login window GUI is implemented. At a glance, we can see the same, single account window but there's "Use multiple accounts" link that moves a user to a list of accounts.
Every account has its name, color and login details. We can change connection options by clicking at cogwheel. There's also certificate button next to password input (as in single account view). Remove account with red cross.
Final aim is to login to each account by enabling it (checkbox next to status egg). This way we can easily choose accounts that are also automatically logged in at startup.
In this phase we can log in using only one account as roster GUI is going to be implemented. Enabling given account by ticking its checkbox effects going to roster when connected correctly.
SettingConstants::MULTIACCOUNT_ENABLED option determines wheter to use this new, experimental feature (default: false).


Remko Tronçon: More Fun with Monad Do-notation in Scheme

Planet Jabber - 4 July, 2015 - 22:00

In a previous post, I played around with monad do-notation in Scheme (well, Racket) to have a nicer syntax to play with asynchronous callbacks. This do-notation is actually quite fun to use with other monads as well. What’s interesting is that the same notation gets entirely different meanings and forms depending on which monad you use it with.

There are many interesting monads, and this post shows only a couple of simple ones in action in Scheme (for which you can find the code here). If you want a much better description and in-depth of these monads (and more), I highly recommend you read the awesome Learn You a Haskell for Great Good!

Continue reading post

ProcessOne: Growing programming languages, June 2015

Planet Jabber - 2 July, 2015 - 09:26

Steve O’Grady published another edition of his great popularity study on programming languages: RedMonk Programming Language Rankings: June 2015.

As usual, it is a very valuable piece. There are many take-away from this research. I will not go over Steve O’Grady findings, but what I found interesting is:

  • Open Source and license matters. For two of the hot languages, Erlang and Swift, we have seen important changes in licensing that may have an impact in the coming months.

    • Erlang changed its license from its Erlang Public License to a more widely accepted Apache V2. Steve O’Grady notes that it will not change language popularity but will remove friction for adoption and will make the language more attractive for large contributors. It is worth noting that Erlang is still growing and is now in the top 25, thanks to the amazing projects build with it.
    • Apple announced that Swift will be open source by end of the year, with a Linux version coming at the same time. This was a much needed change that will expand the community and accelerate the adoption of one of the fastest growing programming languages.
  • There are 4 booming programming languages: Go, Swift, Rust and Julia. Go and Rust are competing for the same type of projects and developers. In a sense, with an open sourced Swift, it could reach the same target of system programming, even if it will be difficult to overshadow its mobile development roots. It will be interesting to see how those three languages evolves comparatively in the next research. Julia is a scientific language and evolves in its own niche space.

  • My current favorite, Elixir, is not progressing as fast as Rust, despite reaching version 1 and being developed at an incredible page under Jose Valim’s vision. My feeling is that it is still in developer projet inception phase and that it is winning the heart of Erlang developers first, and many Ruby developers. I expect it to grow slowly in the coming months, as Phoenix Web Framework matures.

The programming language space is still extremely interesting to see evolve and I am looking forward seeing what the developer community is doing with them. Actual projects are the language king makers. For example ejabberd has been critical for Erlang popularity. Docker project is boosting Go adoption. Let’s watch other big project to understand programming languages future.

Marvin Wißfeld (GSoC 2015): Status Update - Can you see DNSSEC?

Planet Jabber - 2 July, 2015 - 00:00

It’s again time for a status update, else I got the feeling I will be beaten up and thrown away (or something alike).

What happened?

minidns-dnssec advanced a lot.

  • Finally I added support of verifying DNS records. This means you can new verify that a record you received is properly signed by the zone owner, as long as he as verified ownership to the parent domain zone.
  • Support for negative result verification (NSEC) was added as well. This feature is used to verify that a record does not exist. However most DNS servers implement the successor of NSEC, NSEC3, which is not part of this implementation.
  • Obviously fixed a few bugs here and there.
What will happen?

The core is done, now we need a huge framework around it: NSEC3, API stabilization and a lot of tests are still missing to make this project a success.

And finally adding minidns-dnssec into applications is also an important part of the project. We want all this hard work to run in the applications you use everyday, don’t we?

Remko Tronçon: Flattening Callback Chains with Monad Do-Notation

Planet Jabber - 1 July, 2015 - 22:00

A few unrelated topics on my reading list made me want to randomly experiment with a few things. I wanted to understand monads a bit better, see how they applied to callback-based asynchronous programming, and play around with macro programming in a Lisp dialect. This is a partial log of the theoretical-and-probably-not-directly-applicable-but-nevertheless-fun rabbit hole I dived into.

Continue reading post

Tarun Gupta (GSoC 2015): Week - 6

Planet Jabber - 1 July, 2015 - 17:20
Hello Everyone,
I have completed International Domain Name (IDN) features, all JID features and couple of bugs this week, along with tests.
Well, International domain name is an internet domain name that contains at least one character in a language specific script (can be any language). Internationalized domain names can use characters from the entire range of Unicode, while traditional domain names are restricted to ASCII characters. The conversions between ASCII and non-ASCII forms of a domain name are accomplished by algorithms called ToASCII and ToUnicode. The algorithms are applied after breaking the domain into different labels such as: "www.example.com" is composed of three labels: "www", "example", and "com". ToASCII will apply the Nameprep algorithm, which converts the label to lowercase and performs other normalization, and will then translate the result to ASCII using Punycode before prepending the four-character string "xn--". The ToASCII algorithm can also fail if the final string exceed the 63-character limit of a DNS name. A label for which ToASCII fails, cannot be used in an internationalized domain name. More details can be found in RFC 3490. For example,"транспорт.com" gets converted to "www.xn--80a0addceeeh.com".I have used a third party library ICU - International Components for Unicode, which provides functionalities for such conversions.
Next, I have completed JID which required a bit of refactoring and addition of two important methods providing functionalities of getting escaped and unescaped node. getEscapedNode takes a string node and then checks for each character. If character is one of the allowed esacpe characters, then it is replaced with the Hex of that character. I have also added tests for checking all the functionalities inside JID.
Lastly, as a substitute for boost::ptime::not_a_date_time, I have allowed null values for Date type variables to some elements.
Next Up, I will be implementing Disco, Queries. And I am working quite in alignment with the proposal.
Thanks.

Andreas Straub (GSoC 2015): Week 05 - Bugfixes

Planet Jabber - 1 July, 2015 - 08:26
Welcome to the progress update!
Sadly, there won't be new screenshots , as the focus of this week were general code quality improvements. ;) Last week, I achieved proof-of-concept level functionality, so now the task is to make sure it not only works in the ideal case, but also copes with all kinds of errors properly. The first order of business was fixing establishing sessions with own devices. Previously, only sessions with remote devices could be established.

But the biggest task this week was reworking the message processing pipeline to an asynchronous model. Recall that, in order to establish a session, it is necessary to fetch PreKeyBundles from PEP. Previously, PreKeyBundles were fetched ahead of time and cached in memory, so that message processing could be performed synchronously, by simply retrieving the needed bundles from the cache. Now, those bundles are fetched on demand from PEP. As an added benefit, I also moved the subsequent encryption operations into a background thread, as the processing chain was already broken up into asynchronous tasks. This should improve responsiveness, because in pathological cases (10+ open sessions per message) I noticed some UI hanging during message processing. And while I was at it, I also rewrote the way those messages are then submitted to the XmppConnectionService for sending. I had previously written this code as a bare minimum working approach. Now I'm using the sendMessage()/resendMessage() as intended, so that messages written while offline will get delivered properly.
I also refined the PEP content verification. Previously, if any part of the PEP bundle mismatched the local state, the entire bundle was essentially "nuked" and overwritten with fresh data. Especially considering the PreKeyPublics, this lead to an unreasonably high "churn rate". Now only those contents that need updating are actually refreshed. Additionally, PEP contents are now refreshed every time a session is established. This is necessary to overwrite used PreKeyPublics sooner rather than later, in order to lower the chances that another client will try to use the same one to establish a session.
Next up, I will be adding more error handling, as well as building some basic UI, so that we can hopefully push out an alpha version to a few people soon.

ProcessOne: ejabberd 15.06: Message archive, configuration checker and new packages

Planet Jabber - 30 June, 2015 - 14:27

ejabberd 15.06 includes over 100 changes since the last release two months ago. Among those changes it includes several major new features.

New features

The focus of this release is archiving and easier configuration.

Message Archive Management support

Message Archive Management (aka MAM, defined in XEP-313) is now the de facto standard for message archiving in XMPP world.

ejabberd now comes with its own full feature message archiving implementation:
– It support both version 0.2 and the more recent version 0.3 of the protocol.
– It support Mnesia internal storage and relational database backend (aka odbc, but actually use native drivers).

To enable it, simply add mod_mam in ejabberd modules configuration section, telling it to use your configured relational database.

modules: ... mod_mam: db_type: odbc

Please, also check the sql directory to find about the table to add to your relational database. MAM relational storage is supported for MySQL, Postgres and SQLite.

Configuration checking on launch

ejabberd is sometime difficult to configure, especially when you want to define complex setup. After having changed the configuration file to support YAML format, we now introduce a new feature to help you get your configuration right.

On ejabberd launch, you will now see report about possible misconfiguration, with explicit error message.

For example, suppose there is a typo on the registration_timeout option, you’ll get the following error in the log file:

16:15:20.487 [error] unknown option 'registrtion_timeout' will be likely ignored

This can be of great help when trying to understand why an option is not taken into account.

Windows installer

The Microsoft Windows installer is back, as a beta version. Windows is not a good platform to run a production ejabberd server, for various reasons. However, many users are developing on Windows or want to try ejabberd from their Windows Desktop. Building ejabberd on Windows is very complex, so we decided to finally update our packaging to bring latest ejabberd to Windows users. The installer is 64 bits only, it supports Windows 7 and Windows 8.

The installer is still considered experimental. For example, we did not yet sign the installer with Windows developer account to become a trusted developer. This may come depending on the feedback we get regarding our Windows version.

Please, send us your feedback and contributions!

RPM and DEB packages

We have been providing for years a binary installer that includes everything you need to run ejabberd. It includes all the dependencies and a minimal version of Erlang, independently from the one installed on your system.

We now provide the same binary packaging as RPM and DEB for 64bit Linux. This is generated from the same source so it includes its own minimal version of Erlang and doesn’t have any dependencies on other packages. This is still a work in progress, it means that your feedback is welcome. The packages can be downloaded from ProcessOne ejabberd download page.

We hope that this is another step in making ejabberd simpler to deal with and even more ubiquitous. It should also help you stay up to date and always be able to run the latest ejabberd version.

Improvements

We now have an installer for contributed modules since ejabberd 15.04. In that new release, we’ve improved automatic compilation of external modules, it’s now more robust and able to handle more complex modules.

Documentation now includes supported protocols with versions by parsing directly modules source code.

Changelog overview

Here is a complete changelog. We’ll detail some of these changes in the coming days with follow up blog posts.

Message archiving
  • Add support for message archiving in Mnesia or relational databases.
Protocol
  • Document protocol support and version inside each module and use that info in documentation
  • Remove deprecated XEP-0090 Entity Time and XEP-0091 Delayed Delivery
  • Don’t add body element to MUC subject messages
  • Do not bounce normal messages sent to unavailable resource
Admin command-line tool
  • Fixed several ejabberd commands
  • Allow password with ‘;’ passed in ejabberdctl
  • Improve ejabberdctl external module install code, allows better error checking
  • New ping ejabberdctl command to check if the node is up and running
  • New commands for Multi-User chat management: get_room_options and get_user_rooms
Configuration
  • Add config validation at startup
  • Fix include of non yaml config files
  • New option hide_sensitive_log_data to hide client IP address in log
  • New option net_ticktime, to fine tune Erlang cluster networking
  • New option max_users_presence in mod_muc, to avoid broadcasting presence packet from users after a chat room has reached a given size
Elixir
  • Add correct package version for mix
Security
  • New options to configure your own custom Diffie-Helman parameters: dhfile and s2s_dhfile
PubSub
  • Enforce definition of pubsub node max_items
  • Fix pubsub/odbc crash on remote user unsubscribe
  • Fix use of publish_only affiliation with odbc backend
Multicast
  • Pick first local multicast service, otherwise remote
Databases
  • Fix anonymous user login, it wasn’t stored in anonymous mnesia table
  • Fixed some string/binary issues in ejabberd_odbc
  • PostgreSQL storage: added missing sm (session manager) table
Packaging
  • Microsoft Windows 64 bits installer
  • Provide RPM and DEB binary packages for linux 64 bits.
Clean up
  • Remove obsolete doc and win32 files
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.

Andreas Straub (GSoC 2015): Week 04 - PEP

Planet Jabber - 24 June, 2015 - 14:09
Welcome to this week's progress update! 
As you may recall, I spent the last two weeks trying to get a basic OTR-style end to end encryption setup working. I encountered a lot of problems, as I had written all of the supporting code with the ultimate goal of PreKeyBundle-initiated multi-end to multi-end sessions in mind. After realizing I would have to rewrite large chunks of the code in order for this OTR-like behavior to work, and after discussing these problems with my mentor, we decided to drop work on this. Rather, I decided to progress immediately to working on the PEP code that would be needed to house the PreKeyBundles. The only reason we had decided initially to work on this was because it was thought to be less complicated, and so would get us to a testable state sooner. As this turned out to be a dead end, it was time to cut our losses and move on. This was definitely the right decision, as I was able to get a very basic PreKeyBundle-based implementation working this week:




As you can see from the above screenshots, I was able to demonstrate the ability to send an encrypted message that reaches multiple devices of the same account. This is of course still very fragile code, missing most error handling, but I'm now able to test on real hardware, which makes iterating on the design a much quicker (and more enjoyable) process. I'm hopeful that, within a few weeks, I will be able to distribute a test build on the Conversations beta channel, which will be very useful in getting bug reports as well as early user feedback.

So with the progress update out of the way, let's talk about PEP. The asynchronous model of axolotl necessitates some kind of central storage where users can publish PreKeyBundles, which can be used by their contacts to establish sessions with them asynchronously. We chose to implement this using PEP, as it's a standardized XMPP extension that is in wide use (e.g. for Avatars). PEP is needed by my protocol for two tasks:
  1. Publishing a user's list of deviceIds
  2. For every device, publish a list of PreKeyBundles
For these purposes, I introduced two types of PEP nodes:  eu.siacs.conversations.axolotl.devicelist and eu.siacs.conversations.axolotl.bundles. These are, of course, preliminary names that will be changed to something more neutral once this protocol is standardized properly. Here are some examples of what these nodes look like:

<!-- Node: eu.siacs.conversations.axolotl.devicelist --><item> <list xmlns="eu.siacs.conversations.axolotl"> <device id="1337"/> <device id="2342"/> <!-- ... --> </list></item>
<!-- Node: eu.siacs.conversations.axolotl.bundles:DEVICE_ID --><item> <bundle xmlns="eu.siacs.conversations.axolotl"> <signedPreKeyPublic signedPreKeyId="FOO"> BASE64BLOB== </signedPreKeyPublic> <signedPreKeySignature> BASE64BLOB== </signedPreKeySignature> <identityKey> BASE64BLOB== </identityKey> </bundle> <prekeys xmlns="eu.siacs.conversations.axolotl"> <preKeyPublic preKeyId="1"> BASE64BLOB== </preKeyPublic> <preKeyPublic preKeyId="2"> BASE64BLOB== </preKeyPublic> <!-- ... --> </prekeys></item>
Notice that there are actually several copies of the bundles node, one per deviceId. The idea behind this scheme is that device will subscribe to the devicelist node, so that they are notified whenever their contacts (or their own account) adds another device. Separating out the bundles list into a separate node has several advantages.
  • It reduces contention on PEP, as the deviceIds are generally updated less frequently
  • It reduces network load, as subscribers receive PEP updates not only when the node is changed, but also whenever they come online. The bundles node is pretty big, as it houses 100 preKeyRecords.
These PEP nodes are used as follows:
  • Whenever a user comes online, they will check that their own deviceId and PreKeyBundles are present in PEP. If not, they are published.
  • Whenever a user receives devicelists for one of their contacts (or themself), the deviceIds are cached and used later when establishing sessions.
  • Whenever a user wants to send a message to one of their contacts, they first check whether they have active sessions for each of the contact's (and their own) deviceIds. If there are missing sessions, they will fetch corresponding PreKeyBundles from PEP and use these to build sessions.

Because PEP is a general purpose pubsub key-value-store, there are some issues that have to be dealt with when using it for our purposes. In traditional axolotl setups (i.e. as used by TextSecure), the key server will 
  1. only hand out a PreKeyBundle once
  2. only accept PreKeyBundles from the deviceId owner
  3. prevent one device from clobbering another's deviceId 
PEP can not guarantee such integrity protection, so the clients have to take care of enforcing it themselves. 

The first restriction (only handing out any PreKeyBundle once) can not easily be replicated in this setup. Our approach here is to have the clients pick one of the PreKeyBundles at random, and have the owner refresh them frequently. This should all but prevent accidental double use of a PreKeyBundle. However, since this is essentially a self-imposed restriction, malicious parties don't have to do this, and can reuse PreKeyBundles as much as they want. Double use of a PreKeyBundle is not a security issue in and of itself, as long as certain security considerations are followed. In fact, some protocols (e.g. IKE) have (EC)DH public key reuse built in. A lockout mechanism might also be possible, in which a client will only accept a limited number of sessions initiated per PreKeyBundle. We have decided against implementing this for now, as it introduces additional complexity in handling accidental reuse, and could lead to some message loss.
The second and third restrictions can only be enforced by clients periodically policing their own PEP nodes to ensure no changes were made. Changes to the deviceId are noticed, as the client is subscribed to this node. Changes to the PreKeyBundles are currently checked on every login.

These concessions should have little to no impact on normal protocol operation. We rely on the fact that, if an attacker has stolen a user's XMPP credentials, they might be able to perform DoS-type attacks against opening new sessions, this is noticed by the user, who can then take steps to remedy the situation (i.e. change his passwords).

Next, I will spend a lot of time on building proper UI, testing, fixing bugs, and introducing all kinds of error handling. Until next week!
Distribuir contenido