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. :)
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?
- 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?