Agregador de noticias

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.

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.

ProcessOne: Advanced Erlang Initiative

Planet Jabber - 30 June, 2015 - 16:25

We are proud to be launching the Advanced Erlang Initiative, a new group of companies that use Erlang as a strategic technology to craft great products. Erlang ecosystems rely on those publishers that are producing person/years worth of code to build excellent products.

The Advanced Erlang Initiative recognises that those products in turn contribute to the fame of the Erlang platform. They help pushing the limits and contribute to the fame of our beloved programming language. Most of all, the Advanced Erlang Initiative acknowledges peoples energy and effort put in those great products to the good of every Erlang developer. We have created a forum for developers working with and contributing to those tools to meet and discuss their work.

The Advanced Erlang Initiative welcomes all developers that share our passion for Erlang, Elixir, the beam environment and our vision of technical excellence.

Our initiative is primarily centered around inexpensive highly technical workshops given around the world and educational videos on our Erlang products.

The first two members are:

  • ProcessOne, maker of the world class messaging server ejabberd, since 2002.
  • Quviq, maker of the Quickcheck property-based testing tool, innovation in quality assurance.

We are happy to meet you on the newly launched website Advanced-Erlang

We are already taking registration for the first two workshops:

More to come soon !

Enjoy and see you there after the summer break !


Thomas Arts, Quviq
Mickaël Rémond, ProcessOne

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!

ProcessOne: Apple increasing security of Push service ahead of WWDC

Planet Jabber - 24 June, 2015 - 12:33
Apple is tightening its push service encryption

Since this morning, Apple has been changing the setting of the push sandbox. This is generally good news, but it means that if your push notification system is written in Erlang, using Erlang stock SSL module, it will not work.

If your are using Erlang SSL to send push notification to Apple, you will need to patch Erlang to avoid the following error:


** {function_clause,[{ssl_cipher,hash_algorithm,"ï",[{file,"ssl_cipher.erl"},{line,1174}]},{ssl_handshake,'-decode_handshake/3-blc$^0/1-0-',1,[{file,"ssl_handshake.erl"},{line,898}]},{ssl_handshake,'-decode_handshake/3-blc$^0/1-0-',1,[{file,"ssl_handshake.erl"},{line,899}]},{ssl_handshake,decode_handshake,3,[{file,"ssl_handshake.erl"},{line,898}]},{tls_handshake,get_tls_handshake_aux,3,[{file,"tls_handshake.erl"},{line,153}]},{tls_connection,next_state,4,[{file,"tls_connection.erl"},{line,454}]},{tls_connection,next_state,4,[{file,"tls_connection.erl"},{line,458}]},{gen_fsm,handle_msg,7,[{file,"gen_fsm.erl"},{line,505}]}]}

The issue is that Erlang SSL implementation crashes on unknown hash and signature algorithms.

We have published a quick workaround for the issue on our own Erlang/OTP repository fork on Github and are hoping to help OTP team reproduce the issue to provide a long term more sustainable patch (as you need to disable completely unknown crypto hashes). In case you need it, the Erlang workaround is there: Do not crash on unknown hash and signature algorithms.

I hope this helps !

Good news for our customers

All our customers are already on the safe side. If you are using ejabberd SaaS, ejabberd Business Edition or Boxcar Push Developer Platform, you are already on the safe side and ready for the production roll out.

It feels good, right ?

Enjoy your week-end !

Tarun Gupta (GSoC 2015): Week 5 - Full of Testing!

Planet Jabber - 24 June, 2015 - 09:12
Hello Everyone.

This week was kind of finishing off with all the basic things like FileSize, SafeString, etc which will be required by future functionalities. I have completed all Elements, their Parsers and Serializers. Now Stroke has all of them! Also this week was full of testing all these parsers and Serializers, which took most of the time. Some tests were added by me for some parsers and serializers (because they were untested!!) , which were also added to Switen, so that Swiften has feature parity with Stroke with respect to Elements, Parsers and Serializers.
I faced certain difficulties while doing so because of differences in C++ and Java. In Java, when creating a class which requires a typename and then calling some method using that typename, then that typename should inherit from some interface/class such that those interfaces/classes have those methods, which isn't the case in Swiften. So I made some extra interfaces, some for testing, some for Base functionalities providing those methods. At some places, I made anonymous inner classes to test the functionalities using Parser Tester.
Now next, I will be focusing on completing JID, but before that IDN (and yeah, maybe some dependencies!). A lot to do in remaining two months though.

Adhish Singla (GSoC 2015): Week 4

Planet Jabber - 23 June, 2015 - 22:02
Objective Read Requests Abstract

Read Request is sent to a Device JID to retrieve Numeric Values from them, for instance Temperature related Values from a Temperature Sensor Device. This Week we will use it to retrieve numeric values from Devices and get them displayed in ChatBoxes.

Work
  • Send a hardcoded Read Query to a Device and retrieve its values in the console.
  • Extend sending Read Query from hardcoded to a command ‘/read’ that can be sent to a device using ChatBox.
  • Parse the message coming back from the Device to Display the Name and Value of Device in ChatBox.
Problems Faced and Work Arounds Inputs for Read Request
  • There was a similar problem to that of Disco Query, we were not sending resources when we began, and the device sent back an Error IQ which was resolved as soon as we figured out the same for Disco Query.
Final Output

Road Ahead
  • We will implement Write and write an API for Raspberry Pi 2 in JavaScript for next week.

Ignite Realtime Blog: Whack 2.0.0 released

Planet Jabber - 22 June, 2015 - 19:18

2534 days after its last release, we are happy to announce the 2.0.0 release of the Whack API!

 

Whack is our Open Source XMPP (Jabber) component library for XMPP components. External components are processes that run outside of the Openfire's process but can connect to the server to add new functionality. Whack is an implementation of XEP-0114: Jabber Component Protocol.

 

This release brings a number of small improvements and bugfixes. Notably, Whack 2.0.0 is now based on the Tinder API.

 

Starting with the current release, Whack shall also be available through Apache Maven. The artifact coordinates of the core module are: org.igniterealtime.whack:core:2.0.0. The source code includes a number of small examples on how to use the library, which should have you up and running in no time!

Ishan Khanna (GSoC 2015): GSOC Serverless Messaging Project – #1

Planet Jabber - 20 June, 2015 - 17:37

This is my first post regarding the Google Summer of Code 2015 Serverless messaging project that I am doing under the XMPP Standards Foundation. I am working on the Smack Project that allows you to create Chat clients for Java and Android based applications with the help of an XMPP server.

So far I have added the functionality to announce presence over a Link Local connection on the network. Also to conceal your presence from the network. Currently I am testing this with some clients like Gajim that have support for XEP-174.

Peter Saint-Andre: RFC 7590: TLS in XMPP

Planet Jabber - 19 June, 2015 - 00:00
Following on the work that Yaron Sheffer, Ralph Holz, and I did on best practices for SSL/TLS in application protocols, Thijs Alkemade and I have now applied those recommendations to XMPP in the form of RFC 7590 (published today). This document explicitly updates the security considerations of the core XMPP spec and thus helps us further strengthen the security properties of the Jabber/XMPP network. Naturally there is still much to be done, but this is another step in the right direction...

Adhish Singla (GSoC 2015): Week 3

Planet Jabber - 18 June, 2015 - 20:47
Objective Disco Requests Abstract

Disco Query is sent to a JID to check for features related to the JID. This Week we will use it to identify Devices and the IoT Features that they support.

Work
  • Send Disco Query to all contacts as soon as a JID logs in.
  • Based on the features received from the contacts set ‘support_0323’ and ‘support_0325’ vars in the Contact Data Structure.
  • Set some Viewable Difference so as to Differentiate between Contacts and Devices Visually.
Problems Faced and Work Arounds Inputs for Disco Query
  • Initially we faced problem with Disco Query that was, We were not able to retrieve features for Devices, while it was working good with normal JIDs.
  • Disco not working for Devices.

  • Disco working for JIDs.

  • We figured out that the problem faced was because we were sending the Disco Query to Bare_JID instead of sending it to JID/resource.
  • Disco working for Devices after using Resources.

Visual Difference between Contacts and Devices
  • We started with the Idea of having a different Tabs and Views for IoT Devices, which we were unable to do because of Contact Rendering Issues.
  • Then we had 2 ideas to replace the above which were to have a different Group for IoT Devices or have a Different Icon for Devices.
  • We settled down on having a Different Icon for Devices and that is a ‘Wrench’ Icon.
  • Successful Disco Request and View.

Road Ahead
  • For next week we will implement Read and Write for Devices.

Tarun Gupta (GSoC 2015): Week4 - Elements

Planet Jabber - 17 June, 2015 - 16:33
Hello Everyone, And now in the fourth week of GSoC. Just one week before evaluation week,though.

I have implemented a couple of Elements, including Jingle and Hash Elements. Elements just provide various functionalities like Chat State Tracking, etc to store information. Elements require parsers and serializers to set and get their variables. Parsers parse the XML and extracts and sets the private variables for the Element. On the other hand, Serializers serializes an instance (of the Element) to XML format. So from last week, I have implemented a large number of elements, their parsers and serializers. And then there's tests, which checks the desired functionalities. Just a small number of Elements remaining, after which I'll go onto complete Base functionalities. I have skipped WhiteBoard from Elements, as it is not required for now.
Now comparing the current progress to that of my GSoC proposal, I think I have done quite more. On a short summary, I have completed all of Avatars (1 test remaining), all of Crypto, almost all of Elements, Parsers and Serializers, and some of Base functionalities.
Next week, I'll probably go according to my GSoC proposal plan (or maybe not) and implement and extend JID and EventLoop.
That's for now. Thanks Everyone.

Andreas Straub (GSoC 2015): Week 03 - Wire format

Planet Jabber - 17 June, 2015 - 15:04
Hey everyone, and welcome back to the progress update! This week I want to talk a little bit about the wire protocol I want to use for this project.

The basic mechanism of the protocol involves encrypting each payload with a fresh, random key, and then encrypting that key separately for each partner involved in the conversation using long-standing axolotl sessions with those contacts. This is similar to how emails are encrypted with PGP, and has the advantage of fine-grained control over the intended recipients while minimizing overhead (as the payload is only present once in the message).

This data is serialized into an XML structure containing a <hdr> element for every participating contact, which contains an encrypted copy of the payload key, and a single <msg> element, which contains the encrypted payload. Every header is tagged with the remote device ID that corresponds to the contact device this header is intended for, so that recipients don't have to exhaustively try to decrypt every header, but only need to look at the ones that are relevant to them. The message is tagged with IV and HMAC. While axolotl already provides integrity protection, this obviously only applies to the individual axolotl-encrypted headers, so it is necessary to validate the encrypted payload as well, in this case using the standard encrypt-then-authenticate scheme.

A big goal of my design is minimizing overhead, especially in the headers. Every message sent in a multi-end to multi-end encrypted session contains one header for each own device, as well as for each of the contact's devices. Therefore, bloat adds up quickly. It would have been possible to reduce the size by around 20 bytes per header by opting to use a custom binary format, but using XML integrates much more nicely with the XMPP ecosystem, and will probably also aid others in implementing this protocol in the future.

As far as my progress goes, I'm still working on the single-end to single-end use case at the moment. It's turning out to be slightly more involved than anticipated because most of the code I have already written is geared towards the asynchronous PreKeyBundle based session management, as that will most likely be the only session establishing mechanism supported in the final release version. For that reason, I have had to make some adjustments, but it's coming along nicely, and I should be entering the testing phase very soon.





Marvin Wißfeld (GSoC 2015): Status Update - Recursive resolving

Planet Jabber - 17 June, 2015 - 00:00

Ugh. You probably know this. You’re working hard, but joyful on a certain project. At sometime during the day you boss comes in your office asking you to write a report on this or that. Not only you have to do these boring thing now, you’re also told to not “just put it off for the sake of writing more code”.

Well, of course your boss has good reasons to do so. Summarizing will not only help people around you understand what you do, what you want to achieve and what they can do to support you, but recapturing your own work might also gives you a new view on your work and in the end might make it even better. However in the moment where the report is due, it always seems unreasonable and useless, doesn’t it?

What happened?

Last status post is already two weeks ago. There must be something to report!

  • minidns is now able to create output that is easily comparable with the output generated by the dig tool. This does not only come very handy when debugging the parsing results, but also makes output more valuable to expert users. (The output is not 100% RFC compatible, see here why).
  • As minidns supports both Android and desktop Java, it is able to handle Android specific ways to retrieve the stub DNS server setting. However these methods caused unreasonable overhead when performed on non-android systems. minidns now contains a proper platform detection to not call these Android specific routines on non-android systems.
  • To allow the proper testing announced in the last status post, minidns was refactored hugely and now has support for arbitrary network request backends. While this is normally just UDP and TCP (as announced last report), it is possible to inject our test framework there. Additionally custom network backends (like using the Tor network to resolve .onion-domains) can be injected there.

This was more generic contribution to the minidns library. When it comes to the project topic, there is also progress to report.

  • Support to parse NSEC3 and NSEC3PARAM records (see RFC5155) for signed denial of existence was added. These are not used yet, but parsing them is a requirement for later usage.
  • An initial version of a recursive resolver was added. Although it is already fully functional, it might have bad performance in certain circumstances.
What will happen?

A first DNSSEC specific code is already in the minidns-dnssec subproject in my working repository branch. With the recursive resolver being up and running, the base to work on the real DNSSEC part is done. So we can expect first DNSSEC features to arrive in short time.

Christian Schudt: Version 0.5.0 Release Notes

Planet Jabber - 14 June, 2015 - 09:33
Yay, after a few months of work, version 0.5.0 has been released and pushed to Maven Central!

This release contains some new features, most noteworthy:

And as always bug fixes, more JavaDoc, minor improvements, micro optimizations etc.

A more comprehensive list can be found in the changelog.

Special thanks goes to Markus Karg, who has provided many good ideas and test results, issued bugs and suggested improvements!

What’s next?

Moving to Java 8

0.5.0 will be the last release for Java 7, future releases will be for Java 8.

The reasons behind this decision are:
  • Java 8 offers so much cool new stuff, which is worth exploring and probably helps improving the API in a sustainable way. I am thinking especially about the Stream API, java.time and java.util.function packages and the new Async API.
  • As of now, this library is developed and tested with Java 8 only, which makes maintaining Java 7 compatibility a burden.
New Features

I only want to give a vague preview here, but my plans for new features are currently to implement XEP-0198: Stream Management and finally finish XEP-0301: In-Band Real Time Text.

Happy coding!
Distribuir contenido