When I set out a few weeks ago to figure out which multimedia player in Debian claimed to support most file formats / MIME types, I was a bit surprised how varied the sets of MIME types the various players claimed support for. The range was from 55 to 130 MIME types. I suspect most media formats are supported by all players, but this is not really reflected in the MimeTypes values in their desktop files. There are probably also some bogus MIME types listed, but it is hard to identify which one this is. Anyway, in the mean time I got in touch with upstream for some of the players suggesting to add more MIME types to their desktop files, and decided to spend some time myself improving the situation for my favorite media player VLC. The fixes for VLC entered Debian unstable yesterday. The complete list of MIME types can be seen on the Multimedia player MIME type support status Debian wiki page. The new "best" multimedia player in Debian? It is VLC, followed by totem, parole, kplayer, gnome-mpv, mpv, smplayer, mplayer-gui and kmplayer. I am sure some of the other players desktop files support several of the formats currently listed as working only with vlc, toten and parole. A sad observation is that only 14 MIME types are listed as supported by all the tested multimedia players in Debian in their desktop files: audio/mpeg, audio/vnd.rn-realaudio, audio/x-mpegurl, audio/x-ms-wma, audio/x-scpls, audio/x-wav, video/mp4, video/mpeg, video/quicktime, video/vnd.rn-realvideo, video/x-matroska, video/x-ms-asf, video/x-ms-wmv and video/x-msvideo. Personally I find it sad that video/ogg and video/webm is not supported by all the media players in Debian. As far as I can tell, all of them can handle both formats.

Children can use their imagination better than us because they are (still) immediately in contact with the Whole and they represent the most pristine prototype of the human being. From birth and for the first years of life, the child is the mirror of our species, who carries in himself the primary elements and the roots of evolution, without conditions or interference.

When then education begins, especially school, his imagination is restrained and limited, everything is being done to concentrate his interests only for what is real and to let him leave the world of fantasy. In the first drawing exercises to which the children are subjected at school, their imagination or the appearance of how they perceive some elements of nature are discarded; the drawing that best fit to a photographic vision of reality is rewarded, inhibiting their own imaginative potential from the very beginning, in favour of a more reassuring homologation <Read More [by Fabio Marzocca]>

After long months of testing and waiting for the DVD production, we have released TeX Live 2016 today! Detailed changes can be found here, the most important ones are:

• LuaTeX is updated to 0.95 with a sweeping change of primitives. Most documents and classes need to be adapted!
• Metafont got lua-hooks, mflua and mfluajit
• SOURCE_DATE_EPOCH support for all engines except LuaTeX and original TeX
• pdfTeX, XeTeX: some new primitives
• new programs: gregorio, upmendex
• tlmgr: system level configuration support
• installer, tlmgr: cryptographic verification (if gpg is available)

CTAN mirrors are working on getting the latest releases, but in a day or two all the servers should be updated. Thanks to all the developers, package writers, documentation writers, testers, and especially Karl Berry for his perfect organization. Now get the champagne and write some nice documents!

This was a holiday week for me, so my time was rather crammed into a short space.
I still managed to make progress though. kapptemplate:
https://bugs.kde.org/show_bug.cgi?id=363448
I was given the green light to push this upstream. So this will eventually trickle down and all will benefit, not just debian.
I will leave bug open though as it will need to be applied to all the releases I expect.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825122 choqok:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825322
For this I was able to come up with a patch for kconfig_compiler to encode generated files to utf-8.
Review request is here:
https://git.reviewboard.kde.org/r/128102/ kxmlgui:
WIP this has been a steep learning curve, according to the notes it was an easy embedded kernel version, that was not the case! After grueling hours of
trying to sort out randomness in debug output I finally narrowed it down to cases where QStringLiteral was used and there were non letter characters eg. ( <") These were causing debug symbols to generate with ( lambda() ) which caused unreproducible symbol/debug files. It is now a case of fixing all of these in the code to use QString::fromUtf8 seems to fix this. I am working on a mega patch for upstream and it should be ready early in the week. Other items were minor and not notable enough to blog about Have a great day.

Short trip to Opio en Provence I had a short work-related trip this week to Opio en Provence. It was not a working trip, but rather a team event, which means almost a vacation! Getting there and back I dislike taking the plane for very short flights (and Z rich-Nice is indeed only around one hour), as that means you're spending 3 as much going to the airport, at the airport, waiting to take off, waiting to get off the plane, and then going from the airport to the actual destination. So I took the opportunity to drive there, since I've never driven that way, and on the map the route seemed reasonably interesting. Not that it's a shorter trip by any measure, but seemed more interesting. Leaving Z rich I went over San Bernardino pass, as I never did that before. On the north side, the pass is actually much less suited to traffic than the Gotthard pass (also on the north side), as you basically climb around 300m in a very short distance, with very sharp hairpins. There was still snow on the top, and the small lake had lots of slush/ice floating on it. As to the south side, it looked much more driveable, but I'm not sure as I made the mistake of re-joining the highway, so instead of driving reasonably nice on the empty pass road, I spent half an hour in a slow moving line. Lesson learned Entering Italy was the usual Como-Milan route, but as opposed to my other trips, this time it was around Milan on the west (A50) and then south on the A7 until it meets the A26 and then down to the coast. From here, along the E80 (Italian A10, French A8) until somewhere near Nice, and then exiting the highway system to get on the small local roads towards Opio. What I read in advance on the internet was that the coastal highway is very nice, and has better views of the sea than the actual seaside drive (which goes through towns and is much slower). I should know better than trust the internet , and I should read maps instead, which would have shown me the fact that the Alps are reaching to the sea in this region, so The road was OK, but it definitely didn't feel like a highway: maximum allowed speed was usually either 90km/h or 110km/h, and half the time you're in a short tunnel, so it's sun, tunnel/dark, sun, dark, and you're eyes get quite tired from this continuous switching. The few glimpses of the sea were nice, but the road required enough concentration (both due to traffic and the amount of curves) that one couldn't look left or right. So that was that a semi-failure; I expected a nice drive, but instead it was a challenge drive If I had even more time to spend, going back via the Rhone valley (Grenoble, Geneva, Z rich) would have been a more interesting alternative. France Going to France always feels strange for me. I learned (some) French way before German, so the French language feels much more familiar to me, even without never actually having used it on a day-to-day basis; so going to France feels like getting back to somewhere where I never lived. Somewhat similar with Italian due to the language closeness between Romanian and Italian, but not the same feeling as I didn't actually hear or learn Italian in the childhood. So I go to France, and I start partially understand what I hear, and I can somewhat talk/communicate. Very weird, while I still struggle with German in my daily life in Z rich. For example, I would hesitate before asking for directions in German, but not so in French, unrelated to my actual understanding of either language. The brain is funny The hotel We stayed at Club Med Opio-en-Provence, which was interesting. Much bigger than I thought from quick looks on the internet (this internet seems quite unreliable), but also better than I expected from a family-oriented, all-inclusive hotel. The biggest problem was the food - French P tisserie is one of my weaknesses, and I failed to resist. I mean, it was much better than I expected, and I indulged a bit too much. I'll have to pay that back on the bike or running The other interesting part of the hotel was the wide range of activities. Again, this being a family hotel, I thought the organised activities would be pretty mild; but at least for our group, they weren't. The mountain bike ride included an easy single-trail section, but while easy it was single-trail and rocky, so complete beginners might have had a small surprise. Overall it was about 50 minutes, 13.5km, with 230m altitude gain, which again for sedentary people might be unusual. I probably spent during the ride one of the deserts I ate later that day The "hike" they organised for another sub-group was also interesting, involving going through old tunnels and something with broken water pipes that caused people to either get their feet wet or monkey-spidering along the walls. Fun! After the bike ride, on the same afternoon, while walking around the hotel, we found the Ecole de Trap ze volant open, which looked way to exciting not to try it. Try and fail to do things right, but nevertheless it was excellent and unexpected fun. I'll have to do that again some day when I'll be more fit! Plus that the hotel itself had a very nice location and olive garden, so short runs in the morning were very pleasant. Only one cookie though each Back home and then it was over; short, but quite good. The Provence area is nice, and I'd like to be back again someday, for a proper vacation longer and more relaxed. And do the trap ze thing again, properly this time.

Quite a lot has happened in xdg-app since last time I blogged about it. Most noticeably, it isn't called xdg-app any more, having been renamed to Flatpak. It is now available in Debian experimental under that name, and the xdg-app package that was briefly there has been removed. I'm currently in the process of updating Flatpak to the latest version 0.6.4. The privileged part has also spun off into a separate project, Bubblewrap, which recently had its first release (0.1.0). This is intended as a common component with which unprivileged users can start a container in a way that won't let them escalate privileges, like a more flexible version of linux-user-chroot. Bubblewrap has also been made available in Debian, maintained by Laszlo Boszormenyi (also maintainer of linux-user-chroot). Yesterday I sent a patch to update Laszlo's packaging for 0.1.0. I'm hoping to become a co-maintainer to upload that myself, since I suspect Flatpak and Bubblewrap might need to track each other quite closely. For the moment, Flatpak still uses its own internal copy of Bubblewrap, but I consider that to be a bug and I'd like to be able to fix it soon. At some point I also want to experiment with using Bubblewrap to sandbox some of the game engines that are packaged in Debian: networked games are a large attack surface, and typically consist of the sort of speed-optimized C or C++ code that is an ideal home for security vulnerabilities. I've already made some progress on jailing game engines with AppArmor, but making sensitive files completely invisible to the game engine seems even better than preventing them from being opened. Next weekend I'm going to be heading to Toronto for the GTK Hackfest, primarily to to talk to GNOME and Flatpak developers about their plans for sandboxing, portals and Flatpak. Hopefully we can make some good progress there: the more I know about the state of software security, the less happy I am with random applications all being equally privileged. Newer display technologies like Wayland and Mir represent an opportunity to plug one of the largest holes in typical application containerization, which is a major step in bringing sandboxes like Flatpak and Snap from proof-of-concept to a practical improvement in security. Other next steps for Flatpak in Debian:

• To get into the next stable release (Debian 9), Flatpak needs to move from experimental into unstable and testing. I've taken the first step towards that by uploading libgsystem to unstable. Before Flatpak can follow, OSTree also needs to move.
• Now that it's in Debian, please report bugs in the usual Debian way or send patches to fix bugs: Flatpak, OSTree, libgsystem.
• In particular, there are some OSTree bugs tagged help. I'd appreciate contributions to the OSTree packaging from people who are interested in using it to deploy dpkg-based operating systems - I'm primarily looking at it from the Flatpak perspective, so the boot/OS side of it isn't so well tested. Red Hat have rpm-ostree, and I believe Endless do something analogous to build OS images with dpkg, but I haven't had a chance to look into that in detail yet.
• Co-maintainers for Flatpak, OSTree, libgsystem would also be very welcome.

Many years ago, when koffice was fresh and with few users, I decided to test its presentation tool when making the slides for a talk I was giving for NUUG on Japhar, a free Java virtual machine. I wrote the first draft of the slides, saved the result and went to bed the day before I would give the talk. The next day I took a plane to the location where the meeting should take place, and on the plane I started up koffice again to polish the talk a bit, only to discover that kpresenter refused to load its own data file. I cursed a bit and started making the slides again from memory, to have something to present when I arrived. I tested that the saved files could be loaded, and the day seemed to be rescued. I continued to polish the slides until I suddenly discovered that the saved file could no longer be loaded into kpresenter. In the end I had to rewrite the slides three times, condensing the content until the talk became shorter and shorter. After the talk I was able to pinpoint the problem kpresenter wrote inline images in a way itself could not understand. Eventually that bug was fixed and kpresenter ended up being a great program to make slides. The point I'm trying to make is that we expect a program to be able to load its own data files, and it is embarrassing to its developers if it can't. Did you ever experience a program failing to load its own data files from the desktop file browser? It is not a uncommon problem. A while back I discovered that the screencast recorder gtk-recordmydesktop would save an Ogg Theora video file the KDE file browser would refuse to open. No video player claimed to understand such file. I tracked down the cause being file --mime-type returning the application/ogg MIME type, which no video player I had installed listed as a MIME type they would understand. I asked for file to change its behavour and use the MIME type video/ogg instead. I also asked several video players to add video/ogg to their desktop files, to give the file browser an idea what to do about Ogg Theora files. After a while, the desktop file browsers in Debian started to handle the output from gtk-recordmydesktop properly. But history repeats itself. A few days ago I tested the music system Rosegarden again, and I discovered that the KDE and xfce file browsers did not know what to do with the Rosegarden project files (*.rg). I've reported the rosegarden problem to BTS and a fix is commited to git and will be included in the next upload. To increase the chance of me remembering how to fix the problem next time some program fail to load its files from the file browser, here are some notes on how to fix it. The file browsers in Debian in general operates on MIME types. There are two sources for the MIME type of a given file. The output from file --mime-type mentioned above, and the content of the shared MIME type registry (under /usr/share/mime/). The file MIME type is mapped to programs supporting the MIME type, and this information is collected from the desktop files available in /usr/share/applications/. If there is one desktop file claiming support for the MIME type of the file, it is activated when asking to open a given file. If there are more, one can normally select which one to use by right-clicking on the file and selecting the wanted one using 'Open with' or similar. In general this work well. But it depend on each program picking a good MIME type (preferably a MIME type registered with IANA), file and/or the shared MIME registry recognizing the file and the desktop file to list the MIME type in its list of supported MIME types. The /usr/share/mime/packages/rosegarden.xml entry for the Shared MIME database look like this:

<?xml version="1.0" encoding="UTF-8"?>
<mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info">
  <mime-type type="audio/x-rosegarden">
    <sub-class-of type="application/x-gzip"/>
    <comment>Rosegarden project file</comment>
    <glob pattern="*.rg"/>
  </mime-type>
</mime-info>

This states that audio/x-rosegarden is a kind of application/x-gzip (it is a gzipped XML file). Note, it is much better to use an official MIME type registered with IANA than it is to make up ones own unofficial ones like the x-rosegarden type used by rosegarden. The desktop file of the rosegarden program failed to list audio/x-rosegarden in its list of supported MIME types, causing the file browsers to have no idea what to do with *.rg files:

% grep Mime /usr/share/applications/rosegarden.desktop
MimeType=audio/x-rosegarden-composition;audio/x-rosegarden-device;audio/x-rosegarden-project;audio/x-rosegarden-template;audio/midi;
X-KDE-NativeMimeType=audio/x-rosegarden-composition
%

The fix was to add "audio/x-rosegarden;" at the end of the MimeType= line. If you run into a file which fail to open the correct program when selected from the file browser, please check out the output from file --mime-type for the file, ensure the file ending and MIME type is registered somewhere under /usr/share/mime/ and check that some desktop file under /usr/share/applications/ is claiming support for this MIME type. If not, please report a bug to have it fixed. :)

First, many thanks to Planet Debian readers for your thoughtful and constructive feedback to my Signal and Mobile Instant Messaging blogs. I learned a lot. Particularly useful was the comment directing me to Daniel Gultsch's The State of Mobile in 2016 post. I had previously listed the outstanding technical challenges as:

• Implement end-to-end encryption
• Receive messages the moment they are sent without draining the battery

I am now fairly convined that both problems are well-solved on Android via the Conversations app and a well-tuned XMPP server (I had no idea how easy it was to install your own Prosody modulues -- the client state indicator module is only 22 lines of lua code!) I think the current technical challenges could be better summarized as: adding iOS (iPhone) support. Both end-to-end encryption and receiving messages consistently seem to be hurdles. However, it seems that Chris Ballinger and the Chat Secure team are well on their way toward solving the push issue and facing funder skittishness on the encryption front. Nonetheless, but seem to be progressing. With the obvious technical hurdles in progress, we have the luxury of talking about the less obvious ones - particularly the ones requiring trade-offs. In particular: Signal replaces your SMS client. It looks and feels like an SMS client and automatically sends un-encrypted messages to everyone your address book that is not on signal and sends encrypted messages to those that are on signal. The significance of this feature is hard to over-state. It differentiates tools by and for technically minded people and those designed for a mass audience. When I convince people to use Conversations, in contrast, I have to teach them to:

• Create an entirely new address book by entering addresses for your friends that you don't already have
• Use a new and different app for sending encrypted messages

For most people who don't (yet) have their friends XMPP addresses or for people who don't have any friends who use XMPP, it means that they will install it, send me a few messages and then never use it again. The price Signal pays for this convenience is steep: Signal seems to synchronize your entire address book to their servers so they can keep a map of cell phone numbers to signal users. It's not only creepy (I get a text message everytime someone in my address book joins Signal) but it's flies in the face of expectations for a privacy-minded application. How could we take advantage of this feature, without the privacy problems? What if...

• Our app could send both XMPP messages and SMS messages
• Everytime you added a new XMPP contact, it added the contact to your address book with a new XMPP field
• Anytime you send a message to a contact with an XMPP field filled in, it would send via XMPP and otherwise it would send a normal SMS message

The main downside (which Signal faces as well) is that you have to contend with the complexities of sending SMS messages on top of the work needed to write a well-functioning XMPP client. As I mentioned in my Signal blog, there are no shortage of MMS bugs against Signal. Nobody wants that head-ache. Additinally, we would still lose one Signal feature: with Signal, when a user joins, everyone automatically sends them encrypted messages. With this proposed app, each user would have to manually add the XMPP address and have no way of knowing when one of their friends gets an XMPP address. Any other ideas?

April 23rd to May 23rd The period of introducing ourselves to the Debian community. I have updated my debian wiki page to introduce more about myself to the Debian community. https://wiki.debian.org/SummerOfCode2016/StudentApplications/Jaminy There was a webRTC session of MiniDebconf through Jitsi on 3oth April to know more about the Debian resources. During this period I have updated my PC with the Debian latest version, Jessie and got practised with the new platform.I have also learnt some basic theories on my project such as VoIP and IMAP. I was assigned by my mentor Daniel Pocock to work on telepathy reSIProcate.

• Steps to install reSIProcate

System used

• Debian GNU/Linux 8.3 (jessie)
• Ubuntu 14.04.4 LTS (trusty)

Telepathy-Qt

First you have to configure the telepathy-qt library properly to be able to install reSIProcate. It s important to notice that you shouldn t install telepathy-qt from apt-get because in this way it wont have the telepathy-qt4-service shared library.

$ mkdir ~/telepathy-qt-stuff
$ cd ~/telepathy-qt-stuff
$ git clone https://github.com/dpocock/telepathy-qt-debian
$ cd telepathy-qt-debian
$ git checkout jessie-build-all-shared
$ cd ..

Then you should download the tar http://http.debian.net/debian/pool/main/t/telepathy-qt/telepathy-qt_0.9.6.1.orig.tar.gz in the telepathy-qt-stuff folder and continue:

$ tar xzf telepathy-qt_0.9.6.1.orig.tar.gz
$ cd telepathy-qt_0.9.6.1
$ [ -d debian ] && echo "warning: debian/ already exists!"
$ cp -r ../telepathy-qt-debian/debian .
$ dpkg-buildpackage -rfakeroot -i.* -j13 -us -uc
$ cd ..
$ ls *.deb

Now you should see a list of libtelepathy-qt* and telepathy-qt* .deb packages. You just have to install a few more packages:

$ dpkg -i libtelepathy-qt4-2_0.9.6.1-2_amd64.deb libtelepathy-qt4-dev_0.9.6.1-2_amd64.deb libtelepathy-qt4-farstream2_0.9.6.1-2_amd64.deb

After that you have the necessary packages to install reSIProcate.

$ dpkg -l   grep telepathy-qt

Should return you something like this:

ii

libtelepathy-qt4-2:amd64

0.9.6.1-2

amd64

Telepathy framework Qt 4 library

ii

libtelepathy-qt4-dev

0.9.6.1-2

amd64

Qt 4 Telepathy library (headers and static library)

ii

libtelepathy-qt4-farstream2:amd64

0.9.6.1-2

amd64

Telepathy/Farsight integration Qt 4 library

reSIProcate

After installing telepathy-qt properly you would be able to configure reSIProcate.

Make sure you have added backports to your /etc/apt/sources.list file

$ git clone https://github.com/resiprocate/resiprocate
$ cd resiprocate
$ apt-get install libpq-dev dh-autoreconf
$ apt-get build-dep resiprocate
$ apt-get install -t jessie-backports libradcli-dev
$ ./build/debian.sh
$ make

And then you are done!

I have been using mutt for about half a year already and I m very happy with it. The previous email client I used was Thunderbird (with the Enigmail extension to handle GPG). There were two main reasons that made me switch. The first one was that I often would like to check my email while I m offline, and it seems that Thunderbird is not very good at this. Sometimes not all my email would have been downloaded (just the headers), and I also found it frustrating that after marking more than 50 emails as read while offline, they would be marked as unread again once I went back online. With mutt I m using mbsync (which apparently is faster than offlineimap) to sync my email to a local folder with a cron job. I couldn t be happier. The other issue was that I like having many filters, and it was tedious to customize filters in Thunderbird: there s no way to copy a filter and modify it, and there s a limit in the combinations of ANDs and ORs for fields. I m using procmail now, which allows me save the filter configuration in plaintext and define patterns with more flexibility. The setup for mutt took several weeks, but I never felt that I couldn t accomplish what I wanted (unlike in Thunderbird). I m using mutt with several python and bash scripts that I wrote. But the reason for this post is an issue that I believe happens in every email client (or should I say, MUA, to be more precise). I ve seen it happening to people using both Thunderbird and mutt, and I bet it has happened in other cases: sending an email to someone for which you have their GPG key unencrypted unwillingly. I ve seen this happening in email replies with several participants: after a few encrypted messages are exchanged, someone replies in the clear, quoting all the previous messages. I tried to avoid this by configuring mutt to encrypt and sign by default, forcing me to set sign only manually before sending every email that I can t send encrypted (I d like to send all my emails encrypted, but not everybody has a GPG key :( ). So what happened? I got so used to sending many unencrypted emails that I would press P S (PGP setting, Sign only) before sending emails as a reflex act. And I sent an email unencrypted to a friend for which I have his GPG key :( So I thought: It s a very rare case to want to send an unencrypted email to someone for which you have their GPG key. I think extensions like Enigmail should give you a warning when this happens, to alert you about it. In my case, I solved it with a python script that inspects the email, and, if it s unencrypted and the recipient/s is/are in your GPG keyring it warns you about it and returns an error. The script stores a temporary file with the Message-ID so that if you run it again with the same email it will properly send the email without returning an error. Now, I only needed to configure mutt to use this script as the sendmail command:

per_account:set sendmail  = "$HOME/bin/check-mail-gpg /usr/bin/msmtp -a $my_email"

And here goes the python script check-mail-gpg:

#! /usr/bin/python3
import os
import sys
import subprocess
import email.parser
from email.header import decode_header
from email.utils import parseaddr
STATUS_FILE = '/tmp/check-mail-gpg.tmp'
def dec(header):
    head = decode_header(header)
    if len(head) == 1 and head[0][1] == None:
        return head[0][0]
    else:
        return ''.join([h.decode(enc) if enc else h.decode('ascii') \
                for (h,enc) in head])
def send_mail(mail):
    print('Calling external email client to send the email...')
    #return -1 # testing mode
    p = subprocess.Popen(sys.argv[1:], stdin=subprocess.PIPE)
    p.stdin.write(mail.encode('utf-8'))
    p.stdin.close()
    return p.wait()
def main():
    mail = sys.stdin.read()
    heads = email.parser.Parser().parsestr(mail, headersonly=True)
    content = heads['Content-Type'].split(';')[0].strip()
    print('Content is:', content)
    if content == 'multipart/encrypted':
        print('Ok: encrypted mail, we can return now...')
        sys.exit(send_mail(mail))
    addrs = [parseaddr(addr) for addr in heads['To'].split(',')]
    print('Found emails:', addrs)
    gpg_cnt = 0
    for name, addr in addrs:
        print('Looking for', addr, 'in the keyring...')
        res = subprocess.call(['gpg', '--list-keys', addr],
                stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
        if res == 0:
            gpg_cnt += 1
    if gpg_cnt == 0:
        print('Ok: no email found in the gpg keyring, we can return now...')
        sys.exit(send_mail(mail))
    if not os.path.exists(STATUS_FILE):
        open(STATUS_FILE, 'w').close()
    msg_id = heads['Message-ID']
    msg_id_prev = ''
    with open(STATUS_FILE, 'r') as f:
        msg_id_prev = f.read()
    if msg_id.strip() == msg_id_prev.strip():
        sys.exit(send_mail(mail))
    else:
        with open(STATUS_FILE, 'w') as f:
            f.write(msg_id)
        print('Alert: trying to send an unencrypted email to', addrs,
                ', for which some gpg keys were found in the keyring!')
        print('Try again if you are sure to send this message unencrypted.')
        sys.exit(1)
if __name__ == '__main__':
    main()

Update I ve been told about the option crypt_opportunistic_encrypt in mutt, which provides a feature very similar to what I was looking for. This option will automatically enable encryption when the recipient has a GPG key in your keyring. From mutt s man page:

3.41. crypt_opportunistic_encrypt Type: boolean Default: no Setting this variable will cause Mutt to automatically enable and disable encryption, based on whether all message recipient keys can be located by mutt. When this option is enabled, mutt will determine the encryption setting each time the TO, CC, and BCC lists are edited. If $edit_headers is set, mutt will also do so each time the message is edited. While this is set, encryption settings can t be manually changed. The pgp or smime menus provide an option to disable the option for a particular message. If $crypt_autoencrypt or $crypt_replyencrypt enable encryption for a message, this option will be disabled for the message. It can be manually re-enabled in the pgp or smime menus. (Crypto only)

Debian is quite probably the project that most uses a OpenPGP implementation (that is, GnuPG, or gpg) for many of its internal operations, and that places most trust in it. PGP is also very widely used, of course, in many other projects and between individuals. It is regarded as a secure way to do all sorts of crypto (mainly, encrypting/decrypting private stuff, signing public stuff, certifying other people's identities). PGP's lineage traces back to Phil Zimmerman's program, first published in 1991 By far, not a newcomer PGP is secure, as it was 25 years ago. However, some uses of it might not be so. We went through several migrations related to algorithmic weaknesses (i.e. v3 keys using MD5; SHA1 is strongly discouraged, although not yet completely broken, and it should be avoided as well) or to computational complexity (as the migration away from keys smaller than 2048 bits, strongly prefering 4096 bits). But some vulnerabilities are human usage (that is, configuration-) related. Today, Enrico Zini gave us a heads-up in the #debian-keyring IRC channel, and started a thread in the debian-private mailing list; I understand the mail to a private list was partly meant to get our collective attention, and to allow for potentially security-relevant information to be shared. I won't go into details about what is, is not, should be or should not be private, but I'll post here only what's public information already. What are short and long key IDs? I'll start by quoting Enrico's mail:

there are currently at least 3 ways to refer to a gpg key: short key ID (last 8 hex digits of fingerprint), long key ID (last 16 hex digits) and full fingerprint. The short key ID used to be popular, and since 5 years it is known that it is computationally easy to generate a gnupg key with an arbitrary short key id. A mitigation to this is using "keyid-format long" in gpg.conf, and a better thing to do, especially in scripts, is to use the full fingerprint to refer to a key, or just ship the public key for verification and skip the key servers. Note that in case of keyid collision, gpg will download and import all the matching keys, and will use all the matching keys for verifying signatures.

So... What is this about? We humans are quite bad at recognizing and remembering randomly-generated strings with no inherent patterns in them. Every GPG key can be uniquely identified by its fingerprint, a 128-bit string, usually encoded as ten blocks of four hexadecimal characters (this allows for 160 bits; I guess there's space for a checksum in it). That is, my (full) key's signature is:

AB41 C1C6 8AFD 668C A045  EBF8 673A 03E4 C1DB 921F

However, it's quite hard to recognize such a long string, let alone memorize it! So, we often do what humans do: Given that strong cryptography implies a homogenous probability distribution, people compromised on using just a portion of the key the last portion. The short key ID. Mine is then the last two blocks (shown in boldface): C1DB921F. We can also use what's known as the long key ID, that's twice as long: 64 bits. However, while I can speak my short key ID on a single breath (and maybe even expect you to remember and note it down), try doing so with the long one (shown in italics above): 673A03E4C1DB921F. Nah. Too much for our little, analog brains. This short and almost-rememberable number has then 32 bits of entropy I have less than one in 4,000,000,000 chance of generating a new key with this same short key ID. Besides, key generation is a CPU-intensive operation, so it's quite unlikely we will have a collision, right? Well, wrong. Previous successful attacks on short key IDs Already five years ago, Asheesh Laroia migrated his 1024D key to a 4096R. And, as he describes in his always-entertaining fashion, he made his computer sweat until he was able to create a new key for which the short key ID collided with the old one. It might not seem like a big deal, as he did this non-maliciously, but this easily should have spelt game over for the usage of short key IDs. After all, being able to generate a collision is usually the end for cryptographic systems. Asheesh specifically mentioned in his posting how this could be abused. But we didn't listen. Short key IDs are just too convenient! Besides, they allow us to have fun, can be a means of expression! I know of at least two keys that would qualify as vanity: Obey Arthur Liu's 0x29C0FFEE (created in 2009) and Keith Packard's 0x00000011 (created in 2012). Then we got the Evil 32 project. They developed Scallion, started (AFAICT) in 2012. Scallion automates the search for a 32-bit collision using GPUs; they claim that it takes only four seconds to find a collision. So, they went through the strong set of the public PGP Web of Trust, and created a (32-bit-)colliding key for each of the existing keys. And what happened now? What happened today? We still don't really know, but it seems we found a first potentially malicious collision that is, the first "nonacademic" case. Enrico found two keys sharing the 9F6C6333 short ID, apparently belonging to the same person (as would be the case of Asheesh, mentioned above). After contacting Gustavo, though, he does not know about the second That is, it can be clearly regarded as an impersonation attempt. Besides, what gave away this attempt are the signatures it has: Both keys are signed by what appears to be the same three keys: B29B232A, F2C850CA and 789038F2. Those three keys are not (yet?) uploaded to the keyservers, though... But we can expect them to appear at any point in the future. We don't know who is behind this, or what his purpose is. We just know this looks very evil. Now, don't panic: Gustavo's key is safe. Same for his certifiers, Marga, Agust n and Maxy. It's just a 32-bit collision. So, in principle, the only parties that could be cheated to trust the attacker are humans, right? Nope. Enrico tested on the PGP pathfinder & key statistics service, a keyserver that finds trust paths between any two arbitrary keys in the strong set. Surprise: The pathfinder works on the short key IDs, even when supplied full fingerprints. So, it turns out I have three faked trust paths into our impostor. What next? There are several things this should urge us to do.

• First of all, configure your local GPG to never show you short IDs. This is done by adding the line keyid-format 0xlong to ~/.gnupg/gpg.conf.
  • I just checked both in /usr/share/gnupg/options.skel and /usr/share/gnupg2/gpg-conf.skel, and that setting is not yet part of the packages' defaults. I'll check a bit deeper and file bugs right away if needed!
• Have you written or maintained any program that deals with GPG keys in any way? Make sure it specifies --keyid-format long or 0xlong in any relevant call. It might even be better to use the machine-oriented representation instead: --with-colons.
  • ...Of course, your computer will not feel tired or confused at comparing 160-bit full fingerprints instead of 64-bit long IDs, so it's better if our scripts use the full version for everything.
• Only sign somebody else's key if you see and verify its full fingerprint (this is not a new issue, but given we are talking about it, and that DebConf is around the corner, and that we will have a KSP as usual...)

And there are surely many other important recommendations. But this is a good set of points to start with. [update] I was pointed at Daniel Kahn Gillmor's 2013 blog post, OpenPGP Key IDs are not useful. Daniel argues, in short, that cutting a fingerprint in order to get a (32- or 64-bit) short key ID is the worst of all worlds, and we should rather target either always showing full fingerprints, or not showing it at all (and leaving all the crypto-checking bits to be done by the software, as comparing 160-bit strings is not natural for us humans). [update] This post was picked up by LWN.net. A very interesting discussion continues in their comments.

I am part of the group of students working with the Debian organization. You can see my profile on the Debian wiki here.

Improving distributed and secure communication using free software This the title of my project for this summer. It sounds good, but what am I going to really do? Well, since I m a student at Universit du Qu bec Montr al, I have had the opportunity to meet with the company Savoir-Faire Linux in Montreal last year and that s when I found out about their exciting project: Ring.

Ring is one of the few projects which bring communication confidentiality and freedom in the hands of the users.

OpenDHT Ring is divided in multiple components as explained here: https://ring.cx/en/about/technical. The component I work on is called OpenDHT. This is the distributed hash table which enables Ring users to communicate in a decentralized network. I have already been working on this project for a year now, so you won t see me posting reports where I say I have to find my way around in this project. In fact, I have contributed to rewriting a major part of the code for better maintainability. In the begining of last summer, I was able to be part of a research association between Savoir-Faire Linux and Universit du Qu bec Montr al. We have been working on adding two major features to OpenDHT.

Short introduction to Distributed Hash Tables OpenDHT is based on the Kademlia design. If you know about DHTs, you are aware that they define the notion of distance using the XOR metric. This makes the tuple (H_n, xor) a metric space, where H_n is the space of identifier keys of length n. This way, you can find an identifier be the closest to a target hash than the rest of the nodes in the network.

In order to find some data that is associated with some hash h, you have to find the nodes in the network for which the distance between their hash identifier and the target hash h is minimized. The group of nodes which are the closest to the target hash (OpenDHT allows up to 8 nodes) will hold data for that hash.

Data persistence Let s say you ask a group of 8 nodes to hold some data for a hash and you want the data to hold the whole time until its expiration time as come. If the group of 8 nodes change because that for some reason those nodes leave or others just arrive and have an id that is closer to the target hash than the initial group of 8 nodes. The data would then not be found on the new group of 8 nodes. A first and simple solution was to count on the initial creator of the value to periodically announce the value to the group of 8 nodes. However, what if this node leaves? This is one of the main problem that I ve been working on solving since 2015. A first version of this was produced on September 2015. However, we experienced traffic issues and were forced to redesign the OpenDHT network requests engine. We are presently working on adding a Query feature that would enable filtering of data on remote nodes, hence substantially lowering the overall traffic produced by a response to a get request.

Indexation During the last year, I have also been working on the design of a solution for the use case of indexation. In a more technical way, this is the capability to find data by providing a map where its key is a string field and the mapped value is the value associated to that field, much like in a form. This could help find data for which you don t know the hash, but you have specific information about its content. In other words, this would be a search engine for OpenDHT. I have already created a working, but still in progress, version of this. You can find it on http://opendht.net, on the index branch. Now, Nicolas Reynaud (kaldoran) is contributing to this during the GSOC.

Roadmap As I explained on my page on the Debian Wiki, I am going to work on:

1. Developing new functionalities in OpenDHT aiming at reducing overall generated traffic.
2. Maintenance and optimization of the OpenDHT code in general.
3. Optimizing data persistence solution over the distributed hash table.
4. Merge (1) in the Ring daemon component in order to benefit from lower traffic in Ring.
5. Make OpenDHT use TCP protocol instead of UDP. This is going to reduce code complexity and enhance robsutness of the DHT.

For further details, read my reports!

This is a concise report on my previous week. I started working from 28 May as the exams ended. This report is bit late. I started work on hide=profiles flag. Till now, I did/doing following tasks:

• Read documentation related to argparse python module.
• Debug the code to find the ways to implement the solution
• Discussed the problem with the community.
• Based on progress I have pushed some code here (work is in progress)

Lunar suggested me to create the specification for hide=profiles. It can be found here https://wiki.debian.org/ReproducibleBuilds/HideProfilesSpecification General purpose of addition of hide=profiles to diffoscope is because we want to provide an alternative for tool like OBS pkg-diff. We want to increase userbase of diffoscope and thus number of contributors. Hopefully, I will finish this part as soon as possible. We are still discussing, how things should be done! Right now, I am researching diff of unreproducible packages and trying to develop use cases. I will update the HideProfilesSpecification wiki with my findings. Lunar has given me a proper directions and community is very much helpful. :) My goal for an upcoming week is to search for packages which are unreproducible and generate use cases for diffoscope. This week I will also try to fix the reproducibility of Debian packages. I am loving, contributing to Debian and free software and it s a great learning experience. Many things to come in upcoming time :)

My monthly report covers a large part of what I have been doing in the free software world. I write it for my donators (thanks to them!) but also for the wider Debian community because it can give ideas to newcomers and it s one of the best ways to find volunteers to work with me on projects that matter to me. Debian LTS Due to some departure and increased workload, I wanted to find out a few new paid contributors for Debian LTS. So I sent a mail to debian-jobs@lists.debian.org and contrary to last time (where I posted the announce only here on my blog), I had plenty of replies I ended up enrolling 6 new contributors and refusing 3 persons that did not have the required profile. All new contributors are supposed to handle at least one LTS update on their free time to get up to speed. But from the 6 new contributors only 3 managed to handle their training update in May. During the month I spent quite some time providing guidance to the new contributors both in private mails and on the debian-lts mailing list. I also reviewed a xen update where I had (rightfully) some doubts about the work done. Packaging work fonts-cantarell. After having diagnosed the problem last month, I got annoyed enough by the lack of a fixed package that I found a way to package a newer upstream release of fonts-cantarell without requiring a fontforge update that was likely to take some time still so I prepared and uploaded 0.0.24-1. cpputest. Bug #823711 reported some license issues with some of the files. I immediately forwarded this upstream (issue 961) and fixed it in Debian by repacking the upstream tarball. Fortunately upstream has been quick to handle his and there s a new upstream release (3.8) where the problematic files have been dropped. live-boot. Kali s live images were no longer booting (stuck in the initrd) and with the help of Ben Hutchings we diagnosed this back to #823069 which I fixed in live-boot 20160511. udev. I filed #824025 to request that the rule defining the MAC-based name of USB network interfaces be isolated in its own file so that it can be easily disabled (we do that in Kali). Misc stuff. I packaged Django 1.8.13 in jessie-backports. I filed
#824165 against sbuild being broken with $apt_allow_unauthenticated = 1; in .sbuildrc. I filed a wishlist bug #824168 against apt-listchanges to suggest that it ignores news from auto-installed packages. I filed #825923 to report a regression in python-nltk (discovered in Kali first). Infrastructure work packages.debian.org. A few months ago, I wrote a patch for packages.debian.org so that it forwards emails to tracker.debian.org instead of packages.qa.debian.org. At that time, I was in touch with Rhonda and was hoping that she would apply it rather quickly (the patch is rather short). After a few more pings, she made it clear that she was not alone and that I should rather file a proper request so that someone else can also process it. So I filed #824085 and tried to find someone else to apply my patch. Most of the members of pkg_maint said that they were part of the group only due to generic webmaster involvement but that they did not want to touch that part. Fortunately, Martin Zobel Helas was more receptive to my request and helped me to deploy my changes. I committed my change and Martin pulled it in the live checkout on picconi.debian.org. This update is also a first step towards the possibility to use foo@packages.debian.org and/or teams+foo@tracker.debian.org in the Maintainer field of a package. With this we can get rid of dedicated mailing lists that just duplicate the work of the package tracker. And we no longer need to care about the fact that the Maintainer is handled differently than Uploaders since all (human) co-maintainers would then be listed in Uploaders only (and the package tracker would deal appropriately with mails sent to the Maintainer). Distro Tracker. I improved the import process to be able to force a new processing of source packages that were already imported. This was useful to let it recognize architectures which were newly added in its database (and that were ignored and thus not displayed up to now). I also made a first review of the AppStream patch submitted by Matthias Klump in #806740. Thanks See you next month for a new summary of my activities.

No comment Liked this article? Click here. My blog is Flattr-enabled.

Debian Long Term Support (LTS) is a project created to extend the life of all Debian stable releases to (at least) 5 years. Thanks to the LTS sponsors, Debian's buildd maintainers and the Debian FTP Team are excited to announce that two new architectures, armel and armhf, are going to be supported in Debian 7 Wheezy LTS. These architectures along with i386 and amd64 will receive two additional years of extended security support. Security updates for Debian LTS are not handled by the native Debian Security Team, but instead by a separate group of volunteers and companies interested in making it a success. Wheezy's LTS period started a few weeks ago and more than thirty updates have been announced so far. If you use Debian 7 Wheezy, you do not need to change anything in your system to start receiving those updates. More information about how to use Debian Long Term Support and other important changes regarding Wheezy LTS is available at https://wiki.debian.org/LTS/Using

Debian Long Term Support (LTS) is a project created to extend the life of all Debian stable releases to (at least) 5 years. Thanks to the LTS sponsors, Debian's buildd maintainers and the Debian FTP Team are excited to announce that two new architectures, armel and armhf, are going to be supported in Debian 7 Wheezy LTS. These architectures along with i386 and amd64 will receive two additional years of extended security support. Security updates for Debian LTS are not handled by the native Debian Security Team, but instead by a separate group of volunteers and companies interested in making it a success. Wheezy's LTS period started a few weeks ago and more than thirty updates have been announced so far. If you use Debian 7 Wheezy, you do not need to change anything in your system to start receiving those updates. More information about how to use Debian Long Term Support and other important changes regarding Wheezy LTS is available at https://wiki.debian.org/LTS/Using

Now that I've gone down the signal road, when can I get off of it? The two contenders I've found for more politically conscious mobile-friendly instant messaging are Tox and XMPP. And the problems to solve are:

• Implement end-to-end encryption
• Receive messages the moment they are sent without draining the battery

The Tox Project has a great design (peer-to-peer) and handles end-to-end encryption as part of its core design. However, the Antox mobile client has not only failed to solve the battery drain problem but seems to also have a serious bandwidth issue as well. Also, what is up with this drama? How about XMPP? For years, XMPP clients have been using OTR - and many instant messaging applications support it, including ChatSecure. And now, there seems to be quite a bit of excitement around implementing a better protocol called OMEMO. Incidentally, the OMEMO protocol uses the same Double Ratchet (previously referred to as the Axolotl Ratchet) protocol that Signal uses. While there are some irritating hiccups around using the available GPL library for Double Ratchet on iPhone apps, it seems like these issues are being sorted out and soon we'll have some kind of standard way for XMPP clients to exchange end-to-end encrypted messages. Let's move on to notifications and battery drain. If you believe the author of the Android Conversations App there doesn't seem to be a problem. However, client state indication seems to be the only issue related to battery drainage he addresses and I couldn't figure out how to easily install that extension on our Debian Jessie prosody instance since it isn't included in the prosody-modules package in Debian and it requires additional modules for it to work. Chris Ballinger, the author of ChatSecure (iOS and Android XMPP app), is less optimistic about this problem in general. In short, he thinks we need a proper "push" mechanism and has even started to implement one. At the same time, a new (and different) XMPP standard called Push Notifications - XEP-0357 has been released and it is even implemented in Prosody (although not yet available in Debian). So the future seems bright, right? Well, not exactly. All of this "push" activity seems to solve this problem: A federated/decentralized application cannot properly use Apple's APNs or Google's GCM. In the words of Chris Ballinger:

The biggest problem is that there is no easy way to send push messages between my app and your app. For me to send a push to one of your app s users on iOS, I must first obtain an APNs SSL certificate/key pair from you, and one of your user s push token that uniquely identifies their device to Apple. These push tokens are potentially sensitive information because they allow Apple to locate your device (in order to send it a push).

So, even if we manage to get one of these two standards for push notifications up and running, we have only succeeded in solving Signal's centralization problem, not the dependence on Google Play Services and Apple Push Network (in fact it's quite mysterious to me how you could even use the Prosody implementation of Push Notifications with GCM or APN). So... what we really would need would be to figure out how to implement one of these two push standards and then get it to work with an alternative to GCM and APN (perhaps MQTT)? Which, I think would require changes to the XMPP client. Geez. I may be on Signal longer than I planned.

I just installed Signal on my Android phone. It wasn't an easy decision. I have been running Cyanogenmod, a Google-free version of Android, and installing apps from F-Droid, a repository of free software android apps, for several years now. This setup allows me to run all the applications I need without Google accessing any of my cell phone data. It has been a remarkably successful experiment leaving me with all the phone software I need. And it's consistent with my belief that Google's size, reach and goals are a menace to the left's ability to develop the autonomous communications systems on the Internet that we need to achieve any meaningful political change. However, if I want to install Signal, I have to install Google Play, and the only way to install Google Play is to install Google's base line set of apps and to connect your cell phone to a Gmail account. Why in the world would Signal require Google Play? There is plenty of discussion of the technical debate on this topic, but politically it boils down to this: security is about trade-offs, and the trade-offs you find important are based on your politics. While I consider Signal to be on the same team in the big picture, I think Signal's winning a short term victory for more massively adopted end-to-end encryption at the expense of a longer term and more important struggle for autonomous communication systems specifically for communities fighting corporate power (of which Google itself is an important target) and fighting US hegemony on a global scale. Furthermore, Signal's lead developer's outright hostility to alternate clients connecting to the centralized signal servers demonstrates another political decision that favors central control over any confidence in a broader movement control over what could have become a power new protocol for secure communication. And his refusal to grant an exemption for other developers to use just the encryption algorythm is frustrating to say the least. Given this reasoning, why install Signal? The main reason is because I have yet to convince anyone to remove Google Apps from their phone and Signal, right now, represents a dramatic improvement over most people's current communications habit. And, when it comes down to it, I need to run what I recommend. I'm still running both conversations and Antox which are far better alternatives in the long run. However until they gain more widespread adoption, I'll be experimenting with Signal. Technical Details Oh, and by the way, installing Google Apps nearly bricked my phone. Cyanogenmod's web site conveniently provides instructions for installing Google Apps. However, confusingly, they provide two different links to choose from, one is from OpenGapps which provided my a link to download the zip file to flash on a non-https page (the link itself was over https). The other link was to an https-enabled page on androidfilehost.com that offered a non-https download (but did provide a md5 checksum). I am now sure why people offering software downloads don't enable https from start to finish (well, maybe I do - I haven't yet enabled https on this site...). However, more confusing is that both links were to different files. The OpenGapps one seemed to be a daily build and the androidfilehost was to a file with the date 20140606 in it's name, suggesting it was built nearly 2 years ago. I went with the daily build. When I restarted, I got the error "Unfortunately, Android Keyboard (Aosp) Has Stopped." If you search the web for this error you will see loads of people getting it. However, none of them seem to be using an encrypted disk. Yes, that is a bigger problem since you can't enter your encrypted disk passphrase if your keyboard app has crashed and you can't boot your phone if you can't even hit enter at the passphrase prompt. If you can't boot, you can't clear the keyboard app cache or most of the suggestions. In fact, when you press and hold the power key you don't even get the option to reboot into recovery mode. And, if you connect your device to your USB cable and run the adb tool on your computer, the tool reports that you are not authorized to connect your device. Oh damn. Did I just brick my phone? Fortunately, you can still boot into recovery mode on a Samsung S4 by powering it off. Then, press and hold the up volume button while turning it on. In recovery mode, I as able to convince the adb tool to connect to my device and I copied over the other Gapps zip file from androidfilehost.com and flashing that one seems to have fixed the problem. Once I booted, I ran Google Play and opted to create a new Google Account. I chose the option to not sync my data. Then, I checked in Settings -> Accounts I saw that a Google Account was there and was synchronizing. Great. What was it synchronizing? I clicked the account, then clicked "Accounts and Privacy" and ensured that everything was turned off. Let's hope that works. [Update] Signal's option to take over as your default SMS client and send un-encrypted normal SMS messages while sending encrypted messages to other Signal users is a very good way to smooth adoption. Unfortunately I had some problems with MMS message for which I found a work-around. But sheesh, lots of MMS problems at the moment.

FTP assistant This month I marked 286 packages for accept and rejected 35. I also sent 13 emails to maintainers asking questions. Apart from this nothing unusual happened this month. Debian LTS This was my twenty-third month that I did some work for the Debian LTS initiative, started by Raphael Hertzog at Freexian. This month my all in all workload reached a new high with 31.00h. This resulted in patches for 35 CVEs and the following uploads:

• [DLA 454-1] minissdpd security update
• [DLA 453-1] extplorer security update
• [DLA 455-1] asterisk security update
• [DLA 457-1] mplayer security update
• [DLA 458-1] mplayer2 security update
• [DLA 459-1] mercurial security update
• [DLA 466-1] ocaml security update
• [DLA 467-1] xerces-c security update
• [DLA 485-1] extplorer security update
• [DLA 493-1] openafs security update
• [DLA 495-1] libtasn1-3 security update
• [DLA 499-1] php5 security update

Thanks a lot to all the people who answered my calls for testing, especially Gabriel Filion, Joost van Baal-Ili and Stefan! This month I also had another term of doing frontdesk work and looked for CVEs that are important for Wheezy LTS or could be ignored. Other stuff As already mentioned in an earlier post, I tried to enliven the Internet of Things in Debian. If you would like to help in this field, please drop me a line.