This is the third post in a series of posts (part 1, part 2) describing a secure alternative to applications like WhatsApp. I started with the following statement:

I believe it is possible to build a system with the simplicity and functionality of WhatsApp or Viber, which provides end-to-end encryption, is built on free software and open protocols, that supports federation and is almost decentralised, and that would allow interested companies to turn a profit without compromising any of these principles.

In this post, I will discuss the SIP service providers, how to enable them to make a profit, while keeping the network open and secure.

Basics Service providers are expected to be third parties, either for-profit or not. PSTN termination would be an optional feature, possibly only offered by for-profit services. The services would consist in just a standard SIP service, with STUN/ICE for NAT traversal, plus an API for getting PSTN termination rates, credit balance, account creation, and for buying credit. All authentication will be performed with public key cryptography, using the data already available in the directory service. The idea would be that companies can make a profit by selling PSTN termination and SMS sending. In this way, users get good rates for calling/texting people who are not part of the network, and free SIP-to-SIP calls don't impose a big load on the service. It is expected that the providers would offer some free calls, to allow the users to test the service. Public providers like Betamax already offer free calls to land lines in many countries. To make this simple for the users, the client application would use the API to provide an unified interface to the service providers, without the need for passwords or a web browser. To support multiple services, the overseeing authority must be in charge of compiling a list of authorised providers, which then the client application would use when creating an account. Provider selection can be made automatically, depending on commercial agreements or user location, and for power users, the option to manually choose a provider should be offered. To ensure control of the providers, they should not be able to control the directory servers used. The client application should be careful in exposing as little private data as possible to them.

Account creation With the components described so far, we can think already of how account creation and first calls would be handled:

1. The client application creates a public/private key pair.
2. It requests the directory service to create an account for the public key and the phone number.
3. The directory service uses an encrypted SMS challenge or other similar mechanism to authenticate the request.
4. The public key is published, associated with the phone number.
5. The client app gets a list of service providers, which includes configuration parameters and PSTN rates, and offers the user the chance to select one, or it is automatically selected.
6. The client app then requests an account creation using the phone number as identification, while authenticating with the published key.
7. The provider uses DNSSEC to validate the request, and an account is created.
8. The client then creates an ENUM record in the directory service, associating the phone number with the SIP account.
9. The client registers with the SIP service, again using the public key to authenticate, and can start making calls right away.
10. When the user wants to make a non-free call, the application can offer to buy credit, or use the GSM network.

How is this different As you can see, there is not much difference with the current status. In fact, I would expect that traditional VoIP providers could become part of this network without much additional cost. The big differences are:

• Authentication is delegated to the directory service.
• The provider API, wich handles all administrative tasks, usually offered by web applications.
• Account creation is 100% automated and immediate.
• The provider must offer federated SIP service, and use encryption for all SIP transactions.
• PSTN termination would ideally accept encrypted RTP streams, but that's probably too much to ask.

What's next In the next post I will describe what's possibly the most challenging part of this project: the client application.

Ingress is an Android phone game developed by Google where you have to go to various places to capture portals which are based on landmarks or places of note. There s a sci-fi back story which I haven t cared much about (my local library has a heap of good sci-fi books I don t have time to read). But if you are interested in low quality sci-fi you can start with the Youtube channel for Ingress [1]. But the best thing to do is to download the Ingress client program from the Google play store if you have an Android phone [2]. Periodically they have special events in the game called Anomalies , which usually involve many people competing to capture a small number of special portals. Usually a portal is fairly easy to capture so a high level player can easily capture a portal in at most a few minutes, but when there is a large group of players defending a portal by replacing the resonators as quickly as they are destroyed it becomes more challenging. I m not going to try to explain this properly as I presume that readers either already know or don t care. The Wikipedia page about Ingress has more information. On Saturday there was an Anomaly where the main city was Melbourne. My team (Enlightened) won the event in Australia but apparently the event in the US at the same time was won by the other team (Resistance). I had hoped that our event would be similar to some of the ones I ve seen on the Ingress Report (a fictional news service on youtube) in which actors from the sci-fi videos about Ingress attended. But unfortunately it seems that the actors stay in the US. Every player who was registered for the anomaly received a gift pack that contained three cards and a badge. The picture above shows the cards that my wife and I received along with one of our badges. The badges are green for Enlightened and blue for Resistance (the in-game colors) and have three flashing LEDs the photo has one of the LEDs lit up. The three cards have passcodes which can be redeemed for in-game items, the XMP, Power Cubes, and Resonators weren t that useful (10 not particularly rare items that I could get through 10 minutes of game playing). The Medal cards are for in-game badges showing the anomalies that we have played at, but they are bronze badges which again aren t much use as nothing less than silver will help in leveling up. Overall it was a good experience, we won, had a good after-party (with free snacks and one free drink per person), and the badges are nice. I recommend attending if there s an event in your area, and note that you don t need to be a high level player to attend, even L6 players were able to contribute.

• [1] https://www.youtube.com/user/ingress
• [2] https://play.google.com/store/apps/details?id=com.nianticproject.ingress

I recently bought a new Lenovo X1 Carbon. It is the new second-generation, type 20A7 laptop, based on Intel s Haswell microarchiteture with the adaptive keyboard. It is the version released in 2014. I also ordered the Thinkpad OneLink Dock which I have returned for the OneLink Pro Dock which I have not yet received. The system is still very new, challenging, and different, but seems to support GNU/Linux reasonably well if you are willing to run a bleeding edge version and/or patch your kernel and if you are not afraid to spend an afternoon or two tweaking things. What follows are my installation notes for Debian testing (jessie) when I installed it in early May 2014. My general impressions about the laptop as a GNU/Linux system and overall are at the end of this write-up.

Yesterday night, we had the opportunity to have for the first time my friend Kaz as a guest in my Operating Systems class. We are about to finish the semester, and he took the opportunity not just to show how the Ext4 filesystem is structured, but how it is implemented in a current Linux release. Kaz took a very different approach from what I do: He did it really hands-on, starting with the explanation on how a hello world module would be created, and then digging in following the code of the ext4 module in Linux 3.14 (and some bits in the general filesystem-related includes). Of course, for a ~2hr session, he did not go into the full details, but did show where the main structures of a filesystem are defined, including a general walkthrough on the general kernel coding style. The class was very enjoyable and clear. We had the bad luck of the projector's lamp burning out at the beginning of the class, but still, you can see in the pictures the students were really into his exposition. I think the exposition did make it through and got the students involved and interested And that makes it really worth it! Now... Sadly, due to a (most probably) human factor, I tried to record this talk but lost most of it :-( I have only the first part, but lost most of the second one. I have some bits recorded by a second camera, but have to check if they make sense by themselves, or do need the whole context. Anyway, I'll be reviewing those bits, and will update this post when I get around to cleaning+fixing+integrating them. Some more photos...

Attachment	Size
Video of the first part of Kaz's class	26.26 MB
Kaz's slides for the ext4 module	40.72 KB

Stadtwerke Bonn conduct track works on the third
weekend of May 23-25th on several sections of the
line 61. The orbits of lines 61, 62 and 65 drive from
Friday 23 May to Sunday 25 May not on their usual
line paths. Due the track works a train replacement
service by busses will be established. Please note: The travel time of the shuttle busses
takes longer. It is recommend to adjust the traveling
plan. We apologise for any inconvenience! (Emphasis mine. Inconvenience, such as almost C N>K )

Remember that if you would like to request sponsorship to attend DebConf14, the deadline for registration is today, Thursday, May 15. To be considered for sponsored attendance, your registration and sponsorship request must be received by the end of the day. For travel sponsorship requests, this includes complete information about the funding amount requested. We will happily approve travel sponsorship requests in the amount of $0, but after today you will not be able to change the amount of travel sponsorship you are requesting! Registrations will still be accepted after today in any of the basic, professional, and corporate categories, but requests for sponsorship will no longer be accepted. To register, please read this page and then fill out the registration form.

I m holding a Debian packaging workshop for our trainees at work tomorrow, and have prepared a sample package for a simple PHP web application (just a handful of files) with DB connection (PostgreSQL of course), automatic setup via dbconfig-common, and with support for both Apache 2.2 (wheezy, precise) and Apache 2.4 (jessie/sid), configuration-wise. (It is possible to install this without Apache, just it does not configure the webserver then.) Schema updates on software updates are also tested (there is neither Flyway nor Liquibase which are the tools we use at work for this, other than Roland Mas wonderful scripts for FusionForge in Debian, but to my delight I discovered that dbconfig-common can also do this).

• VCS-Browser
• VCS-git

Comments, suggestions, flames, etc. welcome. I know that this should not be a native package, and will address this tomorrow, but I wanted something that serves as decent example for how to do this easily, Policy conformant and using modern techniques (even those I dislike myself for the sake of simplicity). Permission was granted by the business administration to reproduce this all under a BSD-style licence, so, enjoy sharing! Thanks to Roland Mas, for making FusionForge such a nice project, and Arno T ll for some instant IRC help on the Apache side of this. This is my first time using dbconfig-common, and now, I finally feel I know enough to finish the packaging of Kivitendo which I ve started earlier. Beta testers for that welcome, too. (And next week or so, I ll need this for a Maven thingy. I ll probably opt out on the DB side, there, though. Never did anything with that, either, not being a Java guy. I guess something web to go with tomcat7 anyone got this already?)

For quite some time I was pretty confident that Weblate will need some UI rewrite at some point. This is always problematic thing for me as I'm no way an UI designer and thus I always hope that somebody else will do that. I've anyway spent few hours on train home from LinuxTag to check what I could do with that. The first choice for me was to try Twitter Bootstrap as I've quite good experience with using that for UI at work, so I hoped it will work quite well for Weblate as well. The first steps went quite nicely, so I could share first screenshots on Twitter and continue to work on that. After few days, I'm quite happy with basic parts of the interface, though the most important things (eg. the page for translating) are still missing. But I think it's good time to ask for initial feedback on that. Main motivation was to unite two tab layout used on main pages, which turned out to be quite confusing as most users did not really get into bottom page of the page and thus did not find important functions available there. So all functions are accessible from top page navigation, either directly or being in menu. I've also decide to use colors a bit more to indicate the important things. So the progress bars are more visible now (and the same progress bar now indicates status of translation per words). The quality checks also got their severity, which in turn is used to highlight the most critical ones. The theme will probably change a bit (so far it's using default theme as I did not care much to change that). So let's take a look at following screenshot and let me know your thoughts: You can also try that yourself, everything is developed in the bootstrap branch in our Git repository.

Filed under: English phpMyAdmin SUSE Weblate 4 comments Flattr this!

I previously wrote about the case for a Basic Income in Australia [1]. Since then I read an interesting article by Rutger Bregman in the Dutch site The Correspondent discussing the benefit that such Basic Income schemes have given in various places [2], he makes a great case for giving a Basic Income to poor people. However I believe that it should be provided to everyone. I believe that government payments shouldn t be means tested because the proportion of the population who earn more than the cutoff is usually very small (IE it doesn t save much money), because the money will be recovered from wealthy people in tax, and because the bureaucracy involved in determining who is eligible involves spending tax money to pay bureaucrats and costing everyone time in dealing with the process. The concept of an Attention Economy has been getting some interest recently. But discussions of it seem to be mostly concerned with the needs of fairly wealthy people, how to advertise to them, how to filter out unwanted ads for them, etc. But the costs in attention can be even worse for people on low incomes or social security because they have many attention costs that could be solved by money. Many common essential purchases (EG soap, basic foods, and purely functional clothes) can become difficult decisions if saving a few dollars is important. The amount of thought involved in buying such items can result in someone who s not well off having little energy to concentrate on other things. I think that to have an effective social security system we need to consider how much cognitive effort is being required of people who are receiving benefits. Last month I wrote yet another review of mobile phone plans in Australia [3]. Every time I do this it takes a significant amount of time because the Telcos devise overly complex plans to make it difficult to compare their offerings. It seems that they aim to make their offerings somewhat competitive if you can interpret them but confusing enough to allow many (most?) of their customers to pay needlessly high bills. I could just pick a random telco and pay whatever it takes, spending an extra $10 or $20 per month isn t such a big deal for me. Even though I advise a number of my relatives on the cheapest phone plan it s probably only barely saving enough money to be worth the effort, a major motivation for me is being stubborn and not wanting telcos to rip people off. The Importance of Mobile Phones A mobile phone seems to be essential for most people. Mobile phones are used for making medical appointments and for applying for work, so in almost every case some of the financial assistance paid to a job seeker or person on a disability pension will go towards mobile phone costs. The aims of the social security benefits seem to clearly involve a phone service. Given that most people who receive social security payments spend some of that money on mobile phone bills the government has a direct financial interest in not having such money wasted on needlessly expensive phone plans. As we also don t want to have people on social security spending time and attention trying to find the best phone plan it makes sense to have the government help manage this process. Good communications is regarded as essential to education and economic development. A huge amount of taxpayer money was spent on the NBN (and then wasted by Tony Abbott when he cancelled the original plans) for these benefits. Good phone access is also an issue of personal safety. While it is possible to call emergency services from a mobile phone that doesn t have a valid SIM there are probably few people who keep a spare phone charged for that purpose. Also there are a variety of issues that can impact life or health which can best be resolved by calling friends or relatives. Free Phones I think that the best solution to these problems is for the government to directly pay mobile phone bills. If we are going to have a Basic Income then the government should make the base payment for mobile phone calls for every resident, if not then the government should make the base payment for everyone who receives any form of social security payment. Obviously the amount of data that could be transferred over a 3G network is greatly in excess of the amount that any plans allow and offering true unlimited calling leads to people using mobile phones as baby-monitors, so some limits are necessary. But the government could cheaply pay for a phone plan that exceeds the requirements of most people and then allow anyone who wants more data or calls to pay extra. Which Plan? The cheapest all-inclusive mobile phone plan in recent times was Kogan who charged $299 per annum for 6G of data per month and unlimited calls. The cheapest current offer for unlimited calls seems to be Lebara s $30 per month offer which includes 2G of data. My observation is that people who use 3G Internet just for phone use (as opposed to tethering a laptop or providing home Internet), who use a home Wifi network for installing Android programs and don t play Ingress tend to use a lot less than 1G of data per month. I would use between 400M and 700M per month if I wasn t playing Ingress and didn t use my phone as a Wifi access point. In terms of call volume, 600 minutes a month should be enough to cover the basic needs of most people judging by the number of plans on offer with limits smaller than that. As a current Lebara offer is $30 per month for unlimited calls and 2G of data (and there are similar offers from other telcos), it should be possible for a telco to offer 600 minutes of calls and 1G of data for less than $15 per month. When the government is paying (no bad debts) and many of the users will use much less than the quota such a plan should be profitable at $10 per month or less. Implementation The way to implement this would be to start with a tender that has a hard requirement for the minimum amount of service provided. This would include the number of minutes per month for calls, the number of SMS sent, and the amount of data transfer. To avoid excessive billing (a standard telco scam) there should be a requirement that fees for extra use not exceed some small multiple of the base rate, for example if the government was paying $10 for 600 minutes of calls and 1G of data the excess usage charges could be capped at 3 cents per meg and 5 cents per minute (3* the base rate) which would be profitable for the telco but not a scam. If the telcos act in a market driven competitive manner they will compete to provide the most attractive offerings for $10 per month. If the build cost of the NBN had been invested at government bond rates (for any of the rates used for current bonds) then it would pay for the mobile phone bills for every resident forever, so the cost of providing phones for everyone is in the range of government telecommunications programs. If people who are working were to pay an extra $10 in tax and people who are on social security had their benefits reduced by $10 then that would be a great deal if it saved them the $20 or more that most people spend on a basic phone plan. Government Phone Delays A friend who s a single mother pays for an unlimited mobile phone plan because calls to the social security office are usually kept on hold for more than an hour. It s likely that she could save money over the course of a year by paying for a cheaper plan and just dealing with the occasional big bill, but she needs to budget carefully and feels that she can t take that risk. It seems stupid that government phone delays (partly caused by cutting funds for staff) cause increased expenses for people who are receiving social security payments. If the government implemented a smart queuing system that allowed them to call people back instead of making them wait on hold then it would save money overall. So there are obviously other ways that the government can save money on phone calls and time for everyone.

• [1] http://etbe.coker.com.au/2013/12/08/basic-income-australia/
• [2] http://tinyurl.com/jwj5ahe
• [3] http://etbe.coker.com.au/2014/04/01/comparing-telcos-again/

I've been using Linode since 2010, and many of my friends have heard me talk about how big a fan I am of linode. I've used Debian unstable on all my Linodes, since I often use them as a remote shell for general purpose Debian development. I've found my linodes to be indispensable, and I really love Linode. The Problem Recently, because of my work on Docker, I was forced to stop using the Linode kernel in favor of the stock Debian kernel, since the stock Linode kernel has no aufs support, and the default LVM-based devicemapper backend can be quite a pain. I tried loading in btrfs support, and using that to host the Docker instance backed with btrfs, but it was throwing errors as well. Stuck with unstable backends, I wanted to use the aufs backend, which, dispite problems in aufs internally, is quite stable with Docker (and in general). I started to run through the Linode Library's guide on PV-Grub, but that resulted in a cryptic error with xen not understanding the compression of the kernel. I checked for recent changes to the compresson, and lo, the Debian kernel has been switched to use xz compression in sid. Awesome news, really. XZ compression is awesome, and I've been super impressed with how universally we've adopted it in Debian. Keep it up! However, it appears only a newer pv-grub than the Linode hosts have installed will fix this. After contacting the (ever friendly) Linode support, they were unable to give me a timeline on adding xz support, which would entail upgrading pv-grub. It was quite disapointing news, to be honest. Workarounds were suggested, but I'm not quite happy with them as proper solutions. After asking in #debian-kernel, waldi was able to give me a few pointers, and the following is very inspired by him, the only thing that changed much was config tweaking, which was easy enough. Thanks, Bastian! The Constraints I wanted to maintain a 100% stock configuration from the kernel up. When I upgraded my kernel, I wanted to just work. I didn't want to unpack and repack the kernel, and I didn't want to install software outside main on my system. It had to be 100% Debian and unmodified. The Solution Left unable to run my own kernel directly in the Linode interface, the tact here was to use Linode's old pv-grub to chain-load grub-xen, which loaded a modern kernel. Turns out this works great. Let's start by creating a config for Linode's pv-grub to read and use. Now, since pv-grub is legacy grub, we can write out the following config to chain-load in grub-xen (which is just Grub 2.0, as far as I can tell) to /boot/grub/menu.lst. And to think, I almost forgot all about menu.lst. Almost. Just like riding a bike! Now, let's install and set up grub-xen to work for us. And, let's set the config for the GRUB image we'll create in the next step in the /boot/load.cf file: Now, lastly, let's generate the /boot/xen-shim file that we need to boot to: Next, change your boot configuration to use pv-grub, and give the machine a kick. Should work great! If you run into issues, use the lish shell to debug it, and let me know what else I should include in this post! Hack on!

This is the second post in a series of posts describing a secure alternative to applications like WhatsApp. I started with the following statement:

I believe it is possible to build a system with the simplicity and functionality of WhatsApp or Viber, which provides end-to-end encryption, is built on free software and open protocols, that supports federation and is almost decentralised, and that would allow interested companies to turn a profit without compromising any of these principles.

In this post, I will outline the concepts behind the most critical component of the architecture: the directory service.

Outline I say this is the most critical component, because here lies what makes this architecture different, but also because this is the weakest link in the whole idea. I expect criticism, specially on some security trade-offs, and I hope that people that know better than me can help me improve it. The directory service is what allows the users to register easily, without using passwords, to be able to receive calls and messages from other users, even if they are not part of the network, and to do all this with a reasonable security model.

Let's get technical The directory service is basically a DNSSEC-protected DNS zone serving ENUM records, along with public keys associated with each user identifier. A TLS-enabled API will enable account creation and validation, DNS records publishing, and encrypted records querying. Applications not supporting that API use standard ENUM querying, and the user manually uses traditional web-based methods for account and records management. This allows interoperability with any existing clients and SIP services. The service will authenticate users by using the usual methods to probe ownership of phone numbers: sending an encrypted SMS with a secret that the client application uses then to claim the phone number. This same method can be used to validate ownership of identifiers that are not phone numbers, like pre-existing SIP or email addresses. Once the user is authenticated, the directory service will publish the user's public key and SIP address, both associated with the phone number. When a user wants to place a call or send a message, it uses a DNSSEC-enabled resolver to get securely the other party's public key and SIP address. The user can also perform bulk look-ups, to discover which people on theirs address book is already in the system. These operations disclose an important amount of private data, and I don't think this can be mitigated in an acceptable manner, and therefore the directory service needs to forget the queries as soon as possible, and not to store any logs of these. Also, DNS queries are not encrypted, and are thus vulnerable to snooping by third parties. To mitigate this, the service needs to implement an encrypted but anonymous API to perform queries, and thus offer extra privacy to clients that support the API. The idea is to have more than one service running on different domain names, but not many: they need to keep consistency and replicate among them, and the security and privacy implications of one service not being properly implemented or administered are too big. Therefore, there must not be more than a handful of these, they need to be properly audited, and must not be operated by any for-profit organisation.

Security The Web of Trust is hard. End users don't like hard. Traditional PKI is prohibitely costly, and broken. OTR is good, but is still not hassle-free. Using one of the proposed extensions to DANE, we can solve this problem: using DNSSEC, we can have each users' public key published where everybody can retrieve it securely. This published key can then be used for end-to-end encryption and client authentication with all the components of this architecture. Who creates the key pair? In the simple case, the client application creates the key pair, and stores it in an appropriate container in the mobile device. It then chooses one of many cooperating directory services, and gets the public key associated with the phone number. If the private key is lost (lost your phone?), a new pair is generated and published, after passing the same checks of number ownership, and the old keys are discarded. This opens the door for some attacks, but those can be mitigated by having the client application verify the public records periodically, and the service requiring extra checks for key replacement. For example, by also using a challenge sent by email. What if I want to do things my way? Perfect, you create your keys, and then use the same mechanisms to register with the identity service. Also, you use the service to tell other users to connect to your own SIP server when they want to talk to your phone number. Does this sound like ENUM? It is ENUM, but better. Just by adding DNSSEC, an unified API, and the capability of publishing key material along with the routing information, you got yourself a reasonably secure way of distributing keys and locating users.

Interaction with other components Once the user records are published, the SIP server can use the public key to authenticate the user, and removes the need for passwords. The same principle applies to account creation: if the user has published key material under a phone number's record, the SIP server must accept account creation requests for the same phone number, provided these are authenticated with the private key. If the user wants to switch providers, it is as simple as creating a new account in the new provider, and then updating the ENUM record. The client application queries the service (and possibly other ENUM providers) before placing a call or sending a message. If the peer has keys published, the client can refuse to communicate if the keys don't match, or the peer is not offering call encryption. When public keys are not found, the client can downgrade to traditional unauthenticated encryption, or unencrypted communications.

To be continued In the next posts, I will talk about the overseeing organisation, the SIP service providers, and the client application, and how they all fit together. Stay tuned!

So I ve configured voice service a number of times, but never using Cisco equipment. There s a business starting up here on Orcas Island and they need a number of lines voice and fax service. I had a spare 2801 router laying around and heard that it s possible to provision voice service using these machines. So I looked on eBay for a module that will provide more than two FXS ports and decided on the VIC-4FXS. When it was delivered, I installed it and booted the router. It told me that it needed a PVDM DSP Module, so I got one of those as well. It has arrived. I have installed it. Now when I boot the router, I don t get a warning or an error. configure the router to send outbound calls to the SIP server configure the router to send inbound calls to FXS ports 2,3,4 in round robin

trunk group FXSlines
!
voice-port 0/2/1
 trunk-group FXSlines
!
voice-port 0/2/2
 trunk-group FXSlines
!
voice-port 0/2/3
 trunk-group FXSlines

configure the router to send inbound calls to the correct ports on the VIC-4FXS

dial-peer voice 1 pots
 preference 7
 destination-pattern 3602987792
 translate-outgoing called 10
 port 0/2/0
 forward-digits all
!
dial-peer voice 2 pots
 preference 2
 destination-pattern 3602987793
 translate-outgoing called 10
 port 0/2/1
 forward-digits all
!
dial-peer voice 3 pots
 preference 3
 destination-pattern 3602987794
 translate-outgoing called 10
 port 0/2/2
 forward-digits all
!
dial-peer voice 4 pots
 preference 4
 destination-pattern 3602987795
 translate-outgoing called 10
 port 0/2/3
 forward-digits all

configure the router to accept inbound calls from the asterisk call server

voice service voip
 allow-connections sip to sip
 no supplementary-service sip moved-temporarily
 no supplementary-service sip refer
 fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback cisco
 sip
  registrar server expires max 3600 min 3600
  localhost dns:8.8.8.8

configure the asterisk call server to send inbound calls to the router On asterisk call server, edit sip.conf to register with SIP server on cisco router at 172.16.78.209:

[fhvoice]
type=peer
insecure=port,invite
context=fhvoice
disallow=all
allow=ulaw
language=en
canreinvite=no
host=172.16.78.209
qualify=20000
dtmfmode=rfc2833

On asterisk call server, edit extensions.conf and add extensions to the incoming context:

exten => 3602987792,1,Dial(SIP/fhvoice/$ EXTEN ,30)
   same => n,Hangup()
exten => 3602987793,1,Dial(SIP/fhvoice/$ EXTEN ,30)
   same => n,Hangup()
exten => 3602987794,1,Dial(SIP/fhvoice/$ EXTEN ,30)
   same => n,Hangup()
exten => 3602987795,1,Dial(SIP/fhvoice/$ EXTEN ,30)
   same => n,Hangup()

configure the asterisk call server to accept outbound calls from the router

I ve been searching for interesting ways to manipulate RDF graphs in Python, to create an application that would handle Linked Data Resources in an OO-way, i.e. using Python classes and not tables/sets/lists of triples. The data will be persisted in graphs in a triple store, accessed through a SPARQL enpoint. In this post, I ll illustrate how I managed to tie RDFLib s SPARQLStore plugin and RDFAlchemy to reach a rather nice looking result.
RDFLib provides tools to manipulate graphs, but most of the examples I found didn t load Graph instances from SPARQL, and generally used SPARQLWrapper results (tables) manually. Here comes a first tool to the rescue : SPARQLStore, which allows to dynamically query a remote SPARQL endpoint when navigating an RDFLib graph. I couldn t find a lot of documentation about it, but I found some hints in slide 51 of the excellent presentation by Tatiana Al-Chueyr Linking the world with Python and Semantics. Now, I know how I can manipulate the RDFLib Graphs queried from a remote SPARQL endpoint with the usual methods, I m still not satisfied, because I want OO stuff, not lists of (predicate, object) tuples. Here comes the second tool, RDFAlchemy, which allows to create descriptor classes mapping RDF Resources to Python classes. Here again, there isn t much docs available, but I found the excellent tutorial by Ted Lawless Reading and writing RDF for VIVO with RDFAlchemy. Now we can put the 2 pieces together, modulo a few precautions : the SPARQLStore plugin of RDFLib will generate SPARQL queries everytime a graph is navigated, whereas RDFAlchemy expects the graph to be in memory (at least AFAIU). So we ll have to manually pre-load the contents of the graphs that we need for all the attributes of the descriptor classes. I ve written an example code that illustrates this by trying to query french films in Wikipedia. Here s a copy of the gist. Attention, it will query DBPedia a lot, so pay attention to the bandwidth and memory if you change parameters. It isn t perfect, and I still need to investigate benefits and limitations of the approach. On clear limitation is the number of SPARQL queries made on the endpoint, instead of a smarter pre-loading. Also, on a side note, during tests I could spot a few issues with SPARQLStore, which seems lagging behind probably not used by so many people. The RDFAlchemy project doesn t seem to be in great health, mostly unmaintained from what I can see (and notice that I linked to the GitHub clone/fork that seemed to be the latest maintained while the original author s seems dead), but nevertheless, the code works with a more recent RDFLib, so that s not so bad. Stay tuned for more adventures in Linked Data land in Python.

Today I released version 0.25 of my console mail client, which is a release focussed upon portability (DragonFly BSD, and MacOSX specifically). Over the past couple of weeks I've written a fair bit of code, wondering if I want to make the jump to a graphical email client, but the conclusion for the moment has to be no. With the scripting support built into my client, and even before then using the hooks/hacks that mutt supported, I just process mail so much more quickly than via a GUI system. I also benefit from reading the mail on the host to which it is delivered - mail gets filtered by something like procmail, and I read it in-situa. IMAP is available if I travel, but I rarely do so. Having a GUI client might be fun, but it would mean I'd read mail on my desktop - pretty much the only system I don't backup (except for images, videos, and local media). It would also involve running imapsync, or similar, to pull the mail in, and relaying through the remote server to avoid my ISPs poor IP-reputation. In short I believe if I use a GUI client I'll get slower, and I'll still need the remote host regardless. It was this time last year when I thought it was functional, but now it is functional, battle-tested, and reliable. So I guess I'm done with email for the next few years. Maybe in that time somebody will write something better - console based for preference, GUI as a last resort, and certainly not another webmail client. In other news .. I had a fun interview on Monday, it went well until they admitted they couldn't afford me - so their goal is to pay a junior member a small salary and hope to get somebody senior to work part-time for a similarly minimal salary. Might work for somebody else, but it wouldn't for me right now, so on that basis I declined. The most annoying thing about interviewing is the waiting, between the early flirting about duties and expectations, to scheduling meetings, and then awaiting decisions. On that note I'm half-way through building a new desk which is a nice physical job I can really concentrate upon. I'm currently waiting for the stain to dry on the legs, and then I'll get the damn thing finished. It probably looks more "rustic" than "modern", but it smells nice, so that's the main thing ;) Expect pictures when it is finished.

Random thoughts of a new contributor I've started to contribute to Mozilla - and particularly to the Firefox Desktop QA team - at the end of March, in order to apply for the OPW with Mozilla as Bug Wrangler.
While being already part of the Free Software world as contributor clearly helps, it's always difficult to find your way at first in such a big project, no matter how helpful the people you're working with are. It's about trying to understand how the project is organized and who works on what, what is expected from you as contributor and the specific style of interaction and contribution accepted in the project. So, here's a couple of thought about it: the necessary disclaimer is that I'm a long-time Debian contributor meaning that, inevitably, Debian is my reference model. Also, everything I'm writing here regards only the specific part of the project I've been working in: Desktop QA and Bugmastering. Documentation The first thing that I noticed is the huge amount of documentation. Everything is very well documented and while this is definitely a plus in my book, it's sometimes difficult to keep track of all this resources. AFAICT, there are basically three main sources of documentation:

1. the wiki
2. the Mozilla Developer Network
3. the site of the QA team

Some of the documents on these three different places are sometimes similar, making them redundant and it's difficult to remember where you read what. At least for me. My workaround has been to bookmark pages as a mad woman, and also to make a list on my wikipage of the pages I found more useful.
My top five of useful pages? Here we go!

1. a bug's life: lifecycle of bugs in BMO
2. Tyler's BMO survival guide (parts 1, 2 and 3)
3. Tyler's Triage Guidelines
4. on reducing testcases
5. bug verification walkthrough

And speaking of triage, special shout-out for the most useful addon ever for Mozilla triagers/testers: Nightly Tester Tools. Community interaction For someone coming from Debian, where everything is done via public mailing lists and/or IRC chans, Mozilla was a bit of a cultural shock. The mailing lists are not very much used, at least in the QA community (or I'm not subscribed to the right ones ;)). As for IRC, while there are many channels, they are not very active: meetings and important discussions are held using a proprietary videoconference software (Vidyo), and are mostly restricted to employees (but other people can join if they have a guest URL). On the other hand, every time I asked for help - even the most stupid question - on IRC, I got a useful reply. And thanks to the folks on #testdays and #qa (especially petruta and Aleksej) I was able to speed up the learning process and understand how things work in the project. So, while I'd like to see more public meetings, it's also true that the community is working well on interaction among contributors. Community outreach This is where I think Debian could borrow a couple of ideas. Mozilla basically got me hooked thanks to their Bugdays: every Monday and Wednesday are - respectively - dedicated to Triage and Verification of bugs. The events are open to everyone, the wikipages for the events provide a good tutorial explaining the workflow in detail, and if you have any doubts there are always people willing to help you on the dedicated IRC chan. Every bug worked on during these events is also tagged: so that later it's possible to check how successful the day was in terms of participation. Bugzilla and the triaging/verification workflow About Bugzilla I can only say that I like it. I like how flexible is for search queries, I like the possibility to have custom tags on the whiteboard (as the [bugday-xxxxxx] one) and the smart way to interact among people in the bug without making the bug go stale (ie, mostly the needinfo feature). But beside the software used as BTS, I must admit that I really like the workflow and the whole concept of triaging in Mozilla. The granularity of rights (everyone, canconfirm, editbugs) and the clear procedure for a permission upgrade; the presence of a team constantly working on cleaning the incoming bugs, regardless of the product/component, to make easier for the developers the filtering and the resolution as well; the attention to details of the verification process: each bug marked as Resolved Fixed need to be Verified, to be sure that it's been actually fixed... All these things are really impressive. This, obviously, is something that can be done inside an upstream project where there are people doing paid work, and where the products are not too many. I cannot see how this kind of QA process can be applied to bugs against an entire OS.
But there are some things we (as in Debian) could take inspiration from. Organizing regular Bugdays, for instance. Creating a team of triagers to help both with incoming and with very old bugs. And this, again, is a kind of work that can be done by everyone, not only coding contributors: meaning that an additional effect would be to increase the diversity in the contributors pool. As a side note: I'll start my OPW internship next Monday, and will spend three months playing with bugs and learning how to be a Bug Wrangler! \o/\o/

A release candidate for v1.0.0 of transloadit-api is out. You can install it via npm and give it a try.

npm install transloadit-api@1.0.0-rc1

Now it supports the full transloadit API, together with signature's creation, assemblies, notifications and templates management. The source is on github, the docs are in this website as well as in the comments in the code (which is the source for the website) and of course, any issue just report it on the github's tracker. It has a lot of tests but there are some tests missing, specially for operations that require internet. Hopefully I will have time to write them this week and then release a proper v1.0.0.

Did I get your attention with the title? Good. In this post I will outline something that I have been thinking about for some months:

I believe it is possible to build a system with the simplicity and functionality of WhatsApp or Viber, which provides end-to-end encryption, is built on free software and open protocols, that supports federation and is almost decentralised, and that would allow interested companies to turn a profit without compromising any of these principles.

Introduction This is the first post of a series that I will be publishing in the next few days. Many parts of these posts will be technical, but I expect that the main concepts can be understood by a wider audience. What I am proposing seems like a bold statement, I know. Maybe there is some fatal flaw somewhere in my thinking, and that is why I am publishing this: I hope to get constructive feedback, and maybe get enough traction to start implementing it Real Soon Now . I have been thinking about this problem since February, when I discussed this extensively with friends at FOSDEM. I have already published a critique of Telegram, which had way more impact than I ever imagined, showing that there is people out there interested in this kind of stuff. The last posts about DNSSEC and DANE were part of my musings about this, too. There are many components that need to be built for this to happen. But more importantly, this can only be useful if it gains a critical mass. And that's why I think making this a viable business tool is very important. At the same time, that means I need to think extra carefully to make it impossible for any for-profit company to mutate this effort into Just Another Walled Garden. My goals for this architecture are:

• First and foremost, target the same people that nowadays is using a plethora of walled gardens for their instant communication needs. That is WhatsApp, Viber, Skype, Facebook messenger, etc.
• It must focus on mobile, that is what people care about, without forgetting about other use cases.
• Creating an account and placing the first call/text message should be as easy as it is currently with the competition.
• All communication must be encrypted end-to-end with public-key cryptography; nobody but the user has access to the private keys.
• Most components must be decentralised, and allow for competition.
• There should be as little trust as possible placed on any part of the system.
• Anybody can set up a compatible service provider and offer it to its users, while having full interoperability with other providers.
• Compatible services which are not part of the network must be able to interoperate.
• Contacting a person should happen even if they are not subscribed to the service. The client application must fall-back seamlessly to using interoperability gateways, PSTN termination, or the mobile network.
• Interoperability with the competition is desirable, but possibly is better left to be implemented by the client applications.

Components I have identified a few components needed for this to work, I will expand on each one later.

1. A flagship mobile application for Android and iOS, based on Lumicall or CSIPSimple, but with several important modifications.
2. One or many directory and authentication services, based on ENUM and DNSSEC. These are the most critical piece of this idea, and possibly must only be operated by community-governed non-profits.
3. One or many service providers, that offer simple account creation, registration, and optionally PSTN termination (which can be the main way of generating profit). An API needs to be defined for operations that are not part of the communications protocol, like account creation, credit purchasing, and balance querying.
4. A network governing charter, and a trusted non-profit organisation that oversees that any participating parties are following the charter. This organisation defines which directory services are to be trusted (and possibly operates one of them), and which service providers the client application can use to create accounts.

Key points Some of the issues that need to be solved are:

• How to handle and distribute public keys securely without the user understanding anything about security.
• How to make registration painless and password-free, while offering an acceptable level of security.
• How to fund development of the client application, and maintenance of the directory services.
• How to get companies interested in this, so them would bring users to the network.
• How to allow the user to migrate from one service provider to another, to improve competition.
• How to prevent any party from subverting the spirit of the network.
• How to make the client application work everywhere and have reasonably quality.

To be continued I think I have answers to most of these problems. I will elaborate in the next few days, stay tuned!

Footnotes The name is something I've chosen a name in less than 2 minutes, while starting this post, so probably is awful. The distributed part is only half true, as the directory services need to be centralised, but I think it's good enough. I am aware that Lumicall seems to be trying to build something similar. I only found about that recently, when I was thinking about this design. Sadly, I think it has several shortcomings, but it is definitely one of the building blocks of this project.

Recently I've been seeing lot of posts about DNSSEC on Internet and I thought I should configure my domain to be secured by DNSSEC. copyninja.info domain is now secured with DNSSEC you can verify this by DNSSEC analyzer by Verisign and DNSViz online tool or by installing DNSSEC validator addon for your browser. There are good amount of tutorials and guides available to enable DNSSEC for your domain, still I want to note down steps I followed to here for the record (of course it will be helpful for me if I forget it ;-)) First step will be installing bind9 and dnssec-tools package, if you use aptitude installing dnssec-tools will pull down the bind9 unless you have configured aptitude to not install the Recommends. Next setting up the zone file for your domain, for this first make a copy of /etc/bind/db.local as /etc/bind/db.example.com, replace example.com with your domain name. Now you need to add your zone records to the zone file. Next edit the /etc/bind/named.conf.local file and add following lines

zone "example.com"  
    type master;
    file "/etc/bind/db.copyninja.info";
    allow-transfer  secondary; ;
 ;

Here replace secondary with your secondary DNS servers, if you don't have one you can ommit this but its always recommended to have secondary DNS servers for a zone, in cases when primary fails. After this we need to enable DNSSEC on bind, this is done by editing the file /etc/bind/named.conf.options. Add following lines into options section.

dnssec-validation yes;
dnssec-enable yes;
dnssec-lookaside auto;

A more explanation on this can be found on Linux Journal article. Now its time to create DNSSEC keys and sign your zone, more about different DNSSEC keys and records can be found in the Linux Journal Article on implementation. I used zonesigner utility from dnssec-tools which does job of signing and including KSK and ZSK keys into bind configuration which otherwise should be done manually. Here is the command line I used for generating keys, thanks to Jonas for this.

mkdir -p /etc/bind/keys
zonesigner -algorithm RSASHA256 -keydirectory /etc/bind/keys\
       -dsdir /etc/bind/keys -archivedir /etc/bind/keys/archive \
       /etc/bind/db.example.com

Here we store our keys into /etc/bind/keys directory, and use RSASHA256 algorithm for key generation which is more stronger than the default used RSASHA1 (atleast thats what Jonas told me). This will create ZSK and KSK for the signing zone and creates a signed zone file db.example.com.signed in same directory as original zone file. Now all you need to do is replace the zone file from db.example.com to db.example.com.signed in file directive with your named.conf.local file.

Note that this keys expire after 30 days so you need to resign your zone before 30 days. For resigning just run zonesigner from /etc/bind/keys. You can setup cron job to do this periodically.

zonesigner -zone example.com /path/to/db.example.com

Our signed zone is ready but we are not done yet! For DNSSEC to work others should trust your signed record for this you need to register your public keys with registrar for your domain and this can be done via your domain provider (in my case this is Gandi). You need to check your domain name providers documentation on how to do this. For Gandi users there is a nice documentation.

This is an updated version of an earlier post in March. A number of talks about Rcpp are scheduled over the next couple of months:

• On Wednesday May 14 I will be speaking at the Chicago R Users Group meeting charmingly titled Warm Up for R/Finance, along with fellow R/Finance organizer Josh Ulrich, fellow R/Finance regular Kent Hosxey as well as Cliff Clive. I will talk about Redis and my rather recent nascent RcppRedis package.
• Our sixth international conference R/Finance will take place May 16 and 17, 2014, at UIC in Chicago. See the current agenda for details of the program---which once again will be preceded by one-hour workshops. And as in the past, I will offer a one-hour gentle introduction to Rcpp. This workshop requires registration and a fee, and registraion will close shortly. I will also present a short lightning talk about the RcppRedis package as part of the conference proper.
• A few days later, on May 20, 2014, I will present a one-hour webinar which is part of a series organized by Ray DiGiacomo and the Orange County R Users Group. See this page for details and registration information; the talk itself will be free of charge.
• Later in the month, on May 30, 2014, I will give a talk / guest lecture about Rcpp and RcppArmadillo and over in Economics at the University of Chicago. I reckon that this event is not open to anybody not part of U of C.
• Another three-hour tutorial is scheduled for the tutorial day preceding useR! 2014 at UCLA in early July. This tutorial will also require registration as part of the annual useR! conference. I am very honoured to have been asked to give one of the invited keynotes at useR! 2014. The talk may (or may not) cover at least some aspects of Rcpp. As my talk proposal about the recent RcppZiggurat package for faster Normal RNGs was accepted, I will also give a regular conference talk.

So the month of June remains pretty open. If someone wants me to talk somewhere else, preferably on a Saturday, feel free to get in touch.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Oracle has demonstrated that implementing an API is effectively the same as copying code from a program. To me, as a non-lawyer programmer, this surprising court decision seems to mutate copyrights into a kind of Software-Patent-Lite(tm) without the benefit of examiners or a 15 year term limit. This seems like a chilling new tool for deep pockets companies like Oracle to go about tormenting people. Thinking more deeply, however, you begin to wonder if Oracle hasn t inadvertently created some kind of Free Software Doomsday weapon. After all, if simply implementing an API makes you code a derivative work then doesn t that mean the terms of the GPL will apply on any code that implements the API of a GPL d system? Even if you didn t copy code you have implemented that API and according to Oracle that s a derived work. If you ask me, its the most excitingly vauge and contagious information phenomena since the Open Data Base License.