People these days often do think about what worked well in the last year that they are proud of, what didn't work so well and what they plan to change the coming year. For me a fair amount of the resolutions were about my name. One of them was getting rid of my old name from the Debian Project Participants page. Actually, I started with it on new year's eve already:

Date	Package	Version
Dec 31	abook	0.6.1-1
Jan 01	tworld	1.3.2-1
Jan 01	blosxom	2.1.2-2
Jan 02	netris	0.52-10
Jan 03	t-prot	3.4-4
Jan 04	rungetty	1.2-16
Jan 05	tworld	1.3.2-2
Jan 06	tetrinet	0.11+CVS20070911-2
Jan 07	xblast-tnt-musics	20050106-3
Jan 08	xblast-tnt-sounds	20040429-3
Jan 09	xblast-tnt-levels	20050106-3
Jan 10	xblast-tnt-images	20050106-3
Jan 11	tetradraw	2.0.3-9
Jan 12	ldapvi	1.7-10

So far I've done a fair amount of my job. There are eight source package left to get tweaked. Those might be a bit more difficult and require more attention though. What I also did during those efforts: Convert all packages to source format 3.0 (quilt), and use a dh style debian/rules file. The latter enabled the packages to build reproducible too, which is also an added benefit. So this is a win situation on many levels. One of the most prominent reasons why I didn't convert to a dh style debian/rules file yet was that I considered it making easy things easy and difficult things difficult. Finding out what to override and how to do that was something I was unable to figure out, and speaking with people didn't help me there neither. Only recently someone told me that there is dh binary --no-act to figure out what would be called, and then you just prefix it with override_ in debian/rules to get to where you want to go. This worked extremely well for me.
I'm personally still not a big fan of source format 3.0 (quilt) with respect to that it insists on patches to be applied and leaves them that way after building the source package, which makes it difficult to deal with when having upstream source in the VCS too, but I managed to find my way around so many things in the past that I can live with that. The benefit of not having to repack upstream source if it isn't in .gz form is a far bigger benefit. So, I hope to stay productive and be able to get the remaining package also adjusted and fixed. Guess that's doable until the end of the month, and getting rid of all reproducible build bugreports against my packages along that lines. I will check those packages that carry my name already too after my old name is gone from the overview page.

/debian permanent link Comments: 5 Flattr this

The above sign was at the Melbourne Docks in December 2014 when I was returning from a cruise. I have no idea why there are 3 men and 1 woman on the sign (and a dock worker was also surprised when I explained why I was photographing it). I wonder whether a sign that had 3 women and 1 man would ever have been installed or not noticed if it was installed. At the start of the first day of LCA 2015 the above was displayed at the keynote as a flow-chart for whether someone should ask a question at a lecture. Given that the first real item in the list is that a question should fit in a tweet I think it was inspired by my blog post about the length of conference questions [1]. At the introduction to the Astronomy Miniconf the above slide was displayed. In addition to referencing the flow-chart for asking questions it recommends dimming laptop screens (among other things). The above sign was at a restaurant in Auckland in January 2015. I thought that sort of sexist joke went out of fashion a few decades ago. The above photo is from a Melbourne department store in February 2015. Why gender a nerf gun? That just doesn t make sense. Also it appeared that the only nerf crossbow was the purple/pink one, is a crossbow considered feminine nowadays? The above picture is a screen-shot of one of the Talking Angela series of Android games from March. Appropriating the traditional clothing of marginalised groups is a bad thing. People of Native American heritage who want to wear their traditional clothing face discrimination when they do so, when white people play dress-up in clothing that is a parody of Native American style it s really offensive. The site Racialicious.com has a tag for articles about appropriation [2]. The above was in a library advertising an Ebook reader. In this case they didn t even have pointlessly gendered products they just had pointlessly gendered adverts for the same product. They also perpetuate the myth that only girls read vampire books and only boys read about space. Also why is the girl lying down to read while the boy is sitting up? Above is an Advent calendar on sale in a petrol station. Having end of year holiday presents that have nothing to do with religious festivals makes sense. But Advent is a religious observance. I think this would be a better candidate for war on Christmas paranoia than a coffee cup of the wrong colour. The above photo is of boys and girls pipette suckers. Pointlessly gendered recreational products like Nerf guns is one thing, but I think that doing it to scientific equipment is a bigger problem. Are scientists going to stop work if they can t find a pipette sucker of the desired gender? Is worrying about this going to distract them from their research (really bad if working with infectious or carcinogenic solutions). The Integra advertising claims to be doing this to promote breast cancer research which is also bogus. Here is a Sociological Images article about the problems of using pink to market breast cancer research [3] and the Sociological Images post about pinkwashing (boobies against breast cancer) is also worth reading [4]. As an aside I made a mistake in putting a pipette sucker over the woman s chest in that picture. The way that Integra portreyed her chest is relevant to analysis of this advert. But unfortunately I didn t photograph that. Here is a link to my sociological images post from 2014 [5].

• [1] http://etbe.coker.com.au/2014/01/06/length-conference-questions/
• [2] http://www.racialicious.com/tag/cultural-appropriation/
• [3] http://thesocietypages.org/socimages/2013/10/10/breast-cancer-marketing-has-a-pink-problem/
• [4] http://thesocietypages.org/socimages/2013/10/11/boobies-against-breast-cancer/
• [5] http://etbe.coker.com.au/2014/04/21/sociological-images-2014/

I recently dug through my history of involvement with TeX (Live), and found out that in January there are a lot of anniversaries I should celebrate: 14 years ago I started building binaries for TeX Live, 11 years ago I proposed the packaging TeX Live for Debian, 10 years ago the TeX Live packages entered Debian. There are other things to celebrate next year (2017), namely the 10 year anniversary of the (not so new anymore) infrastructure in short tlmgr of TeX Live packaging, but this will come later. In this blog post I want to concentrate on my involvement in TeX Live and Debian. Those of you not interested in boring and melancholic look-back onto history can safely skip reading this one. For those a bit interested in the history of TeX in Debian, please read on. Debian releases and TeX systems The TeX system of choice has been for long years teTeX, curated by Thomas Esser. Digging through the Debian Archive and combining it with changelog entries as well as personal experiences since I joined Debian, here is a time line of TeX in Debian, all to my best knowledge.

Date	Version	Name	teTeX/TeX Live	Maintainers
1993-96	<1	?	?	Christoph Martin
6/1996	1.1	Buzz	?
12/1996	1.2	Rec	?
6/1997	1.3	Bo	teTeX 0.4
7/1998	2.0	Ham	teTeX 0.9
3/1999	2.1	Slink	teTeX 0.9.9N
8/2000	2.2	Potato	teTeX 1.0
7/2002	3.0	Woody	teTeX 1.0
6/2005	3.1	Sarge	teTeX 2.0	Atsuhito Kohda
4/2007	4.0	Etch	teTeX 3.0, TeX Live 2005	Frank K ster, NP
2/2009	5.0	Lenny	TeX Live 2007	NP
2/2011	6.0	Squeeze	TeX Live 2009
5/2013	7.0	Whezzy	TeX Live 2012
4/2015	8.0	Jessie	TeX Live 2014
???	???	Stretch	TeX Live 2015

The history of TeX in Debian is thus split more or less in 10 years teTeX, and 10 years TeX Live. While I cannot check back to the origins, my guesses are that already in the very first releases (te)TeX was included. The first release I can confirm (via the Debian archive) shipping teTeX is the release Bo (June 1997). Maintainership during the first 10 years showed some fluctuation: The first years/releases (till about 2002) were dominated by Christoph Martin with Adrian Bunk and few others, who did most packaging work on teTeX version 1. After this Atsuhito Kohda with help from Hilmar Preusse and some people brought teTeX up to version 2, and from 2004 to 2007 Frank K ster, again with help of Hilmar Preusse and some other, took over most of the work on teTeX. Other names appearing throughout the changelog are (incomplete list) Julian Gilbey, Ralf Stubner, LaMont Jones, and C.M Connelly (and many more bug-reporters and fixers). Looking at the above table I have to mention the incredible amount of work that both Atsuhito Kohda and Frank K ster have put into the teTeX packages, and many of their contributions have been carried over into the TeX Live packages. While there haven t been many releases during their maintainership, their work has inspired and supported the packaging of TeX Live to a huge extend. Start of TeX Live I got involved in TeX Live back in 2002 when I started building binaries for the alpha-linux architecture. I can t remember when I first had the idea to package TeX Live for Debian, but here is a time line from my first email to the Debian Developers mailing list concerning TeX Live, to the first accepted upload:

Date	Subject/Link	Comment
2005-01-11	binaries for different architectures in debian packages	The first question concerning packaging TeX Live, about including pre-built binaries
2005-01-25	Debian-TeXlive Proposal II	A better proposal, but still including pre-built binaries
2005-05-17	Proposal for a tex-base package	Proposal for tex-base, later tex-common, as basis for both teTeX and TeX live packages
2015-06-10	Bug#312897: ITP: texlive	ITP bug for TeX Live
2005-09-17	Re: Take over of texinfo/info packages	Taking over texinfo which was somehow orphaned started here
2005-11-28	Re: texlive-basic_2005-1_i386.changes REJECTED	My answer to the rejection by ftp-master of the first upload. This email sparked a long discussion about packaging and helped improve the naming of packages (but not really the packaging itself).
2006-01-12	Upload of TeX Live 2005-1 to Debian	The first successful upload
2006-01-22	Accepted texlive-base 2005-1 (source all)	TeX Live packages accepted into Debian/experimental

One can see from the first emails that at that time I didn t have any idea about Debian packaging and proposed to ship the binaries built within the TeX Live system on Debian. What followed was first a long discussion about whether there is any need for just another TeX system. The then maintainer Frank K ster took a clear stance in favor of including TeX Live, and after several rounds of proposals, tests, rejections and improvements, the first successful upload of TeX Live packages to Debian/experimental happened on 12 January 2006, so exactly 10 years ago. Packaging Right from the beginning I used a meta-packaging approach. That is, instead of working directly with the source packages, I wrote (Perl) scripts that generated the source packages from a set of directives. There were several reasons why I choose to introduce this extra layer:

• The original format of the TeX Live packaging information (tpm) were xml files that were parsed with an XML parser (libxml). I guess (from what I have seen over the years) I was the only one ever properly parsing these .tpm files for packaging.
• TeX Live packages were often reshuffled, and Debian package name changed, which would have caused a certain level of pain for the creation of original tar files and packaging.
• Flexibility in creating additional packages and arbitrary dependencies

Till now I am not 100% sure whether it was the best idea, but the scripts remain in place till now, only adapted to the new packaging paradigm in TeX Live (without xml) and adding new functionality. This allows me to just kick off one script that does do all the work, including building .orig.tar.gz, source packages, binary packages. For those interested to follow the frantic activity during the first years, there is a file CHANGES.packaging which for the years from 2005 to 2011 documents very extensively the changes I made in these years. I don t want to count the hours the went into all this Development over the years TeX Live 2005 was just another TeX system but not the preferred one in Debian Etch and beyond. But then in May 2006, Thomas Esser announced the end of development of teTeX, which cleared the path for TeX Live as main TeX system in Debian (and the world!). The next release of Debian, Lenny (1/2009), already carried only TeX Live. Unfortunately it was only TeX Live 2007 and not 2008, mostly due to me having been involved in rewriting the upstream infrastructure based on Debian package files instead of the notorious xml files. This took quite a lot of attention and time from Debian away to upstream development, but this will be discussed in a different post. Similarly, the release of TeX Live included in Debian Squeeze (released 2/2011) was only TeX Live 2009 (instead of 2010), but since then (Wheezy and Jessie) the releases of TeX Live in Debian were always the latest released ones. Current status Since about 2013 I am trying to keep a regular schedule of new TeX Live packages every month. These helps me to keep up with the changes in upstream packaging and reduces the load of packaging a new release of TeX Live. It also bring to users of unstable and testing a very up-to-date TeX system, where packages at most lack 1 month of behind the TeX Live net updates. Future As most of the readers here know, besides caring for TeX (Live) and related packages in Debian, I am also responsible for the TeX Live Manager (tlmgr) and most of upstream s infrastructure including network distribution. Thus, my (spare, outside work) time needs to be distributed between all these projects (and some others) which leaves less and less time for Debian packaging. Fortunately the packaging is in a state that making regular updates once a month is less of a burden, since most steps are automatized. What is still a bit of a struggle is adapting the binary package (src:texlive-bin) to new releases. But also this has become simpler due to less invasive changes over the years. All in all, I don t have many plans for TeX Live in Debian besides keeping the current system running as it is. Search for and advise to future maintainers and collaborators I would be more than happy if new collaborators appear, with fresh ideas and some spare time. Unfortunately, my experience over these 10 years with people showing up and proposing changes (anyone remembers the guy proposing a complete rewrite in ML or so?) is that nobody really wants to invest time and energy, but search for quick solutions. This is not something that will work with a package like TeX Live, sized of several gigabyte (the biggest in the Debian archive), and complicated inner workings. I advise everyone being interested in helping to package TeX Live for Debian, to first install normal TeX Live from TUG, get used to what actions happen during updates (format rebuilds, hyphenation patters, map file updates). One does not need to have a perfect understanding of what exactly happens down there in the guts (I didn t have in the beginning, either), but if you want to help packaging and never heard about what format dumps or map files are, then this might be a slight obstacle. Conclusion TeX Live is the only TeX system in wide use across lots of architectures and operating systems, and the only comparable system, MikTeX, is Windows specific (also there are traces of ports to Unix). Backed by all the big user groups of TeX, TeX Live will remain the prime choice for the foreseeable future, and thus also TeX Live in Debian.

I've been using bridge networking and tap networking for containers and virtual machines on my system. Configuration for bridge network which I use to connect containers was configured using /etc/network/interfaces file as shown below. Basically I setup masquerading and IP forwarding when network comes up using this, so all my containers and virtual machines can access internet. This can be simply done using systemd-networkd with couple of lines, yes couple of lines. For this to work first you need to enable systemd-networkd. Now I need to write 2 configuration file for the above bridge interface under /etc/systemd/network. One file is natbr0.netdev which configures the bridge and the natbr0.network which configures IP address and other stuff for the bridge interface. The IPForward in above configuration is actually redundant, when I set IPMasquerade it automatically enables IPForward. So these configuration is equivalent of what I did in my interfaces file. It also avoids me doing additional iptables usage to add masquerading rules. This pretty much simplifies handling of virtual network devices. There are many other things which can you do with systemd-networkd, like running a DHCPServer on the interface and many other things. I suggest you to read manual pages on systemd.network(5) and systemd.netdev(5). systemd-networkd allows you configure all type of virtual networking devices and actual network interfaces. I've not myself used it to handle actual network interfaces yet.

This is not a new world, this is simply an extension of the old one. I'm not going to write here about sweeping changes that are happening now, but changes that have been taking place in plain sight for many decades. No one has flipped a switch, only tweaked and tuned variables here and there to lead us down this path. I'd like to reflect on where we are now but there is no way I could describe how it is we got here, the journey was far too complex and filled with ommissions, half-truths and outright lies. It's likely we will never know what has brought us here. I live in Scotland, a country that is a part of the United Kingdom and a member of the European Union. We have a Scottish Government, although certain matters are still handled by the UK Government. The European Government also handles some matters and these can take effect across the entire European Union. I do not feel that I can hold trust in any of these bodies anymore. The European Convention on Human Rights was, for me at least, a beacon of hope. A series of fundamental rights guaranteed to be upheld for every person within the European Union. A series of fundamental rights that has been ignored by governments repeatedly:

• 1999: it was held the UK had violated the human rights of several homosexual soldiers who had been dismissed from the armed forces because of their sexuality
• 2002: it was held the UK had violated the human rights of a widower regarding entitlement to receive bereavement benefits who had been discriminated against on account of his gender
• 2005: it was held that the UK violated the human rights of prisoners by denying them the ability to vote
• 2010: the stop and search procedures used by the UK police pursuant to the Terrorism Act 2000 were considered illegal under the ECHR because they did not require the police to have grounds for suspicion before using them

This is not an exhaustive list, just select cross-sections of our recent history. It is important to remember that in each of these cases, it took a citizen to take the case to the European Court of Human Rights. These rights were violated by the UK government until the actions were challenged, the legislation that allowed them was currently enacted into UK law without regard for the ECHR. It should also be noted that the ban on prisoners voting is still in effect in the UK. We've learnt that the ECHR is not an effective safeguard against the abuse of powers by government. The UK government also sees the Human Rights Act as a problem, although at least scrapping it has been delayed for now. Much of these breaches of human rights are justified by the government as in the interest of the runaway train known as "national security". I have recently had direct contact with one aspect of this during my journey home from 32c3. You can read about my experiences with airport security here and here. My experiences at these airports angered me for a number of reasons. The first of which was that I was asked to expose my genitals as part of the routine screening, which I do not believe to be proportionate at all. At Luton, I was at the point where I was intending to leave the airport and take the train instead before I was allowed to excercise my right to opt-out of the nude body scanner. Since these incidents, I have conducted some research into these scanners and started an article on the Open Rights Group wiki. While the security officer at Luton had tried to tell me that the radio waves used could not penetrate clothing, they in fact can and this is the entire purpose of them. While the security officer at Luton told me that the machines did not generate an image, they are in fact doing exactly that, even if that image is processed by computer vision algorithms as opposed to being viewed by a human reviewer. A leaflet by the Department for Transport, made available on the Aberdeen Airport website, also states that no image is created, and yet this is exactly how the scanners work. I have never seen this leaflet printed and available in the airport itself, although I admit I do not fly regularly and may have missed it. That said, it does not provide a true representation of the scan process and I would go as far to say it contains an outright lie. In a document published by the UK Government titled "Response to the consultation on the use of security scanners in an aviation security environment", they state:

"nearly all passengers, if they fully understand the procedures, would be unlikely to opt for [the alternative of a private search]"

Even with this display of confidence that they believe the public are happy with the invasion of privacy brought by the security scanners, they have still chosen to not fully inform the public in the way in which the scanner operates. It is the lies that anger me the most. We claim to live in a democracy and you cannot have a democracy without transparency. It is not too late for the Government to earn back my trust, but for now, they haven't given me good reason to believe anything they produce. If you have read this article and you would like to support efforts for change in the United Kingdom, please consider joining the Open Rights Group and perhaps getting involved in their work.

Modern versions of Linux and MythTV enable infrared remote controls without the need for lirc. Here's how I migrated my Streamzap remote to evdev.

Installing packages In order to avoid conflicts between evdev and lirc, I started by removing lirc and its config:

apt purge lirc

and then I installed this tool:

apt install ir-keytable

Remapping keys While my Streamzap remote works out of the box with kernel 3.16, the keycodes that it sends to Xorg are not the ones that MythTV expects. I therefore copied the existing mapping:

cp /lib/udev/rc_keymaps/streamzap /home/mythtv/

and changed it to this:

0x28c0 KEY_0
0x28c1 KEY_1
0x28c2 KEY_2
0x28c3 KEY_3
0x28c4 KEY_4
0x28c5 KEY_5
0x28c6 KEY_6
0x28c7 KEY_7
0x28c8 KEY_8
0x28c9 KEY_9
0x28ca KEY_ESC
0x28cb KEY_MUTE #  
0x28cc KEY_UP
0x28cd KEY_RIGHTBRACE
0x28ce KEY_DOWN
0x28cf KEY_LEFTBRACE
0x28d0 KEY_UP
0x28d1 KEY_LEFT
0x28d2 KEY_ENTER
0x28d3 KEY_RIGHT
0x28d4 KEY_DOWN
0x28d5 KEY_M
0x28d6 KEY_ESC
0x28d7 KEY_L
0x28d8 KEY_P
0x28d9 KEY_ESC
0x28da KEY_BACK # <
0x28db KEY_FORWARD # >
0x28dc KEY_R
0x28dd KEY_PAGEUP
0x28de KEY_PAGEDOWN
0x28e0 KEY_D
0x28e1 KEY_I
0x28e2 KEY_END
0x28e3 KEY_A

The complete list of all EV_KEY keycodes can be found in the kernel. The following command will write this mapping to the driver:

/usr/bin/ir-keytable w /home/mythtv/streamzap -d /dev/input/by-id/usb-Streamzap__Inc._Streamzap_Remote_Control-event-if00

and they should take effect once MythTV is restarted.

Applying the mapping at boot While the na ve solution is to apply the mapping at boot (for example, by sticking it in /etc/rc.local), that only works if the right modules are loaded before rc.local runs. A much better solution is to write a udev rule so that the mapping is written after the driver is loaded. I created /etc/udev/rules.d/streamzap.rules with the following:

# Configure remote control for MythTV
# https://www.mythtv.org/wiki/User_Manual:IR_control_via_evdev#Modify_key_codes
ACTION=="add", ATTRS idVendor =="0e9c", ATTRS idProduct =="0000", RUN+="/usr/bin/ir-keytable -c -w /home/mythtv/streamzap -D 1000 -P 250 -d /dev/input/by-id/usb-Streamzap__Inc._Streamzap_Remote_Control-event-if00"

and got the vendor and product IDs using:

grep '^[IN]:' /proc/bus/input/devices

The -D and -P parameters control what happens when a button on the remote is held down and the keypress must be repeated. These delays are in milliseconds.

What happened in the reproducible builds effort between December 27th and January 2nd: Infrastructure dak now silently accepts and discards .buildinfo files (commit 1, 2), thanks to Niels Thykier and Ansgar Burchardt. This was later confirmed as working by Mattia Rizzolo. Packages fixed The following packages have become reproducible due to changes in their build dependencies: banshee-community-extensions, javamail, mono-debugger-libs, python-avro. The following packages became reproducible after getting fixed:

• avrdude/6.2-5 by Milan Kupcevic.
• blosxom/2.1.2-2 uploaded by Rhonda D'Vine, original patches (#777292, #793001) by Chris Lamb and akira.
• buzztrax/0.10.2-2 uploaded by Sebastian Dr ge, original patch by Chris Lamb, fixed upstream.
• dx/1:4.4.4-8 by Graham Inggs.
• gap-guava/3.12+ds1-3 by Jerome Benoit.
• goffice/0.10.26-1 uploaded by Dmitry Smirnov, fixed upstream.
• gunroar/0.15.dfsg1-8 uploaded by Markus Koschany, original patch by Reiner Herrmann.
• iceweasel/43.0.2-1 by Mike Hommey.
• ii-esu/1.0a.dfsg1-7 uploaded by Markus Koschany, original patch by Reiner Herrmann.
• jing-trang/20131210+dfsg+1-4 by Samuel Thibault.
• mstflint/4.1.0+1.46.gb1cdaf7-1 by Mehdi Dogguy.
• mu-cade/0.11.dfsg1-9 uploaded by Markus Koschany, original patch by Reiner Herrmann.
• mumble/1.2.12-1 by Christopher Knadle.
• netris/0.52-10 by Rhonda D'Vine, original patches (#778201, #793707) by Chris Lamb and akira.
• onboard/1.1.2-2 uploaded by Mike Gabriel, original patch by Reiner Herrmann.
• parsec47/0.2.dfsg1-7 uploaded by Markus Koschany, original patch by Reiner Herrmann.
• pathological/1.1.3-14 by Markus Koschany.
• projectl/1.001.dfsg1-8 uploaded by Markus Koschany, original patch by Reiner Herrmann.
• re2c/0.15.3-1 by JCF Ploemen.
• s3d/0.2.2-14 by Sven Eckelmann.
• tulip/4.8.0dfsg-2 by Yann Dirson.
• val-and-rick/0.1a.dfsg1-5 uploaded by Markus Koschany, original patch by Reiner Herrmann.
• xterm/321-1 by Sven Joachim.

Some uploads fixed some reproducibility issues, but not all of them:

• debian-installer/20160101 uploaded by Cyril Brulebois with several fixes from Steven Chamberlain.
• drbd-utils/8.9.5-1 by Apollon Oikonomopoulos.
• hhvm/3.11.0+dfsg-1 by Faidon Liambotis.
• rkward/0.6.4-1 uploaded by Thomas Friedrichsmeier, original patch by Philip Rinn.
• rsbackup/3.0-2 uploaded by Matthew Vernon, original patches (#777394, #793716) by Chris Lamb and akira.
• tin/1:2.3.2-1 by Marco d'Itri.
• transdecoder/2.0.1+dfsg-2 uploaded by Andreas Tille, original patch by Chris Lamb.
• tumiki-fighters/0.2.dfsg1-7 uploaded by Markus Koschany, original patch by Reiner Herrmann.

Untested changes:

• fltk1.1/1.1.10-20 by Aaron M. Ucko, currently FTBFS.
• fltk1.3/1.3.3-5 by Aaron M. Ucko, currently FTBFS.

reproducible.debian.net The testing distribution (the upcoming stretch) is now tested on armhf. (h01ger) Four new armhf build nodes provided by Vagrant Cascandian were integrated in the infrastructer. This allowed for 9 new armhf builder jobs. (h01ger) The RPM-based build system, koji, is now in unstable and testing. (Marek Marczykowski-G recki, Ximin Luo). Package reviews 131 reviews have been removed, 71 added and 53 updated in the previous week. 58 new FTBFS reports were made by Chris Lamb and Chris West. New issues identified this week: nondeterminstic_ordering_in_gsettings_glib_enums_xml, nondeterminstic_output_in_warnings_generated_by_breathe, qt_translate_noop_nondeterminstic_ordering. Misc. Steven Chamberlain explained in length why reproducible cross-building across architectures mattered, and posted results of his tests comparing a stage1 debootstrapped chroot of linux-i386 once done from official Debian packages, the others cross-built from kfreebsd-amd64.

As I posted earlier, I have migrated to use tor on my machine. Though I had a couple of unsolved issues back then. One of them being my Mail Transport Agent (MTA) did not support tor. A regular user might not have a lot of use for a MTA on their laptop. However, it is needed for a lot of Debian development scripts (bts, mass-bug, nmudiff), if they are to file/manipulate bugs for you. I have some requirements for my MTA

• tor support (or at least torsocks -able)
• support end-to-end encryption with my provider (STARTTLS)
• verify that it is talking to my provider.
• rewrite my From if it is not correct (otherwise the mail will just be rejected)
• support the auth mechanisms of my provider
• it should be simple to configure

I also have some non-requirements:

• Local mail delivery is not required
• The MTA will not be used as a general mail relay.
  • One target relay
  • No relaying from other hosts
• Mail delivery queue is nice to have but not a strict requirement.

Originally, I used postfix, which supported most of these requirements. Except:

• My attempt to make it use tor failed. The best suggestion I found was to divert its smtp handler and then replace it with a torsocks call to the original handler. Sadly, it just seg. faulted.
• While postfix is almost certainly able to verify it is talking with my provider, I never got it configured to do that. In the end, postfix was to complicated for what I was ready to put up with.

Per suggestion of Jakub Wilk, I tried msmtp, which turned out do what I wanted.

• There is a trivial config file example to start with. I did not need to read any manuals or extended documentation to figure out what they were doing.
• You probably also want to specify tls_priorities (assuming msmtp is linked against gnutls)
  • A code dive suggests it defaults to NORMAL:-VERS-SSL3.0 if not set. It is probably not too bad, but could be better. :)
    
  • From a quick look at the gnutls manual PFS:%PROFILE_<name> seems like decent value (requires gnutls >= 3.2.4 and that your provider has decent/modern SSL setup).
  • You probably want to have a look at the values for the %PROFILE_<name> before deciding on one.
• The msmtp program supports connecting through SOCKS proxies and even has a sample config snippet for using it with tor.
  • Of course, by the time I had discovered that I had already been using torsocks /usr/sbin/sendmail a couple of times. :)

The only feature I will probably miss is having a local queue, which can be rate limited. But all in all, I am quite happy with it so far. :)
Filed under: Debian

In the 4th quarter of 2016, we will freeze Debian Stretch. If you are hoping to do any larger changes for Stretch, please consider starting on them now. This also includes features that need to be in APT/dpkg (etc.) in Stretch, so we can start using them for Buster. Even something as trivial as the automatic dbgsym packages took over 8 months to complete (from the prototype was announced in April). I call it trivial because:

• The specs were simple and were fairly easy to implement
  • Not to mention, the basic idea was already implemented before in e.g. Ubuntu (albeit differently).
• The chosen implementation only had 3 primary tools affected that truly blocked deploying dbgsym packages in Debian.
  • dak
  • debhelper
  • dpkg
• I have yet to hear anyone being against the idea itself.
  • There were some concerns about various implementation details. Fortunately almost all of them had trivial or obvious solutions.
• We could deploy dbgsym packages immediately once the primary tools had been patched in/for unstable.
  • Compared to Multi-Arch, Build-Profiles etc., where we had to wait till the next release before using the feature.
  • It also meant we could immediately test that the feature worked as intended (rather than discovering bugs post release).

NB: There were certainly other parties involved. But these were the most important ones. Mind you, the dbgsym saga is not complete yet. We are still lacking support for migrating dbgsym packages to testing (and, by extension, the next stable release as well). Meanwhile, you can pull the dbgsym packages from snapshot.debian.org. In summary: If you want a larger change to land in Debian Stretch, please start already now. :)
Filed under: Debian, Release-Team

Review: One Salt Sea, by Seanan McGuire

Series:	October Daye #5
Publisher:	DAW
Copyright:	September 2011
ISBN:	1-101-54760-X
Format:	Kindle
Pages:	368

This is the fifth book of the October Daye series. It's the best book of the series to date, at least in my opinion, but this is a series with a substantial cast and political complications. You could probably start here and work out things on the fly, since each story is largely self-contained, but much of the emotional resonance would be lost. As expected for this series, Toby's life doesn't have much time to stabilize after the events of Late Eclipses. This time, though, the initial threat is less personal and more political. The children of the rulers of the Duchy of Saltmist have been kidnapped, and war between Saltmist and the Kingdom of the Mists (Toby's home) is very near. All that stands in the way of horrible casualties, of fae that can scarce afford more death, is Toby's desperate detective work. Toby's confidence and belief in her own abilities has been growing steadily throughout this series. One of my favorite themes in fiction is someone who doesn't really believe in themselves but tries anyway, because they couldn't live with themselves if they didn't, and discovers they're more capable than they thought. In this series, I think that works best when Toby is less scared and more angry, which is very true in One Salt Sea. That's one reason why I liked this book better than either An Artificial Night or Late Eclipses. Another is that I love the politics and the depth of world-building and lore that McGuire brings to this series, and One Salt Sea is a showcase of both. We get the Undersea Duchy of Saltmist, which comes from both different traditions and different fae than the series so far. We get a plot that combines political maneuvering with a more traditional detective story than the last few books. We get more hidden traditions, past alliances and enmity that Toby didn't know about, and further development of Toby's own abilities. She has to tug hard on some threads, move between levels of the fae world, and draw on her network for uniquely fae forms of forensic analysis. I thoroughly enjoyed it, particularly the rocks. (You'll know what I mean when you get to that part.) But the best thing about this book, by far, is the Luidaeg. I've mentioned in reviews of previous books that the Luidaeg is my favorite character of the series. One Salt Sea just cements that. This is the deepest that the Luidaeg has been involved in a story: she gives Toby her mission at the start, substantial help along the way, and is deeply involved in the ending. We even learn some of her own background, and some of her own worries and pain. (And foreshadowing that there's more of this to come, which I'm eagerly looking forward to.) She's moved from a strange ally through a cautious friend to some combination of aunt and mother to Toby, while always staying her irascible and occasionally painful self. The bits with her in this book are the best so far, and there are a lot of them. It's a delightful reading experience. McGuire also uses this story to clear up a plot element that's been lingering since the first book of the series, but that never worked emotionally for me. (I'm talking about this indirectly since it's a significant spoiler.) It's a great resolution, one with heft and emotion and hard choices and pain, and largely makes up for the showing rather than telling that we've gotten in the previous books, while also (at least I suspect) graciously shuffling that plot out of the way in future books. It's a good bit of series work and personal growth for Toby, and I think frees the series to focus on the bits I enjoy the most. The ending of One Salt Sea hurts, but it's a good hurt, full of hard choices made well, bravery, and sacrifice. The best moments of this series have always had that, but I think this book is the most successful delivery of the whole package to date. This has always been a solid urban fantasy series, but I think it's getting better as it goes along. One major reason is that McGuire doesn't seem to be running out of world-building oomph. In a lot of urban fantasy, particularly the werewolf and vampire sort, I feel like the lore gets thinner, more rehashed, and more mundane as the series ages. But McGuire is still introducing new elements, showing existing elements from new directions and in new light, and has been slowly building major puzzles around Toby's life and abilities that intrigue me. And, even more rare, the eventual revelations usually live up to the preceding tension. It's certainly a recipe to keep me reading. Followed by Ashes of Honor. Rating: 9 out of 10

Since the last version 0.0.9 on Debian, I have made some changes until version 0.0.14. The version 0.0.15 is only to include a fix for the new findutils. I thank you to Andreas Metzler for the fix and the prompt NMU. The files are here, take notice about the replaced ~ in the original by _: switchconf_0.0.15.orig.tar.xz switchconf_0.0.15-1_wip1.debian.tar.xz switchconf_0.0.15-1_wip1_all.deb If you need the dsc file, just ask me. Here comes the changelog since 0.0.9, without the lastest NMU:

switchconf (0.0.15-1~wip1) UNRELEASED; urgency=low
  * New upstream version:
    * Replace 'find -perm +1' by 'find -perm /1', thank you Andreas
      Metzler for the patch and the NMU.
  * Add systemd service file, thank you Felipe Sateler for reviewing it.
  * Bump standards-version to 3.9.6, no changes needed.
  * New maintainer email address.
 -- Jose M Calhariz <jose@calhariz.com>  Tue, 29 Dec 2015 19:59:07 +0000
switchconf (0.0.14-1) UNRELEASED; urgency=low
  * Force the use of bash, instead of a POSIX shell.
 -- Jose M Calhariz <jose.calhariz@ist.utl.pt>  Sun, 24 Aug 2014 04:37:04 +0100
switchconf (0.0.13-2) UNRELEASED; urgency=low
  * Add Homepage field pointing to alioth page of the project
 -- Jose M Calhariz <jose.calhariz@ist.utl.pt>  Sun, 02 Mar 2014 18:01:07 +0000
switchconf (0.0.13-1) wheezy; urgency=low
  * New upstream version:
    * Distribution tar is now compressed by xz
  * Change to source format 3.0 (quilt)
 -- Jose M Calhariz <jose.calhariz@ist.utl.pt>  Sun, 02 Mar 2014 15:56:31 +0000
switchconf (0.0.12-1) wheezy; urgency=low
  * Fixed some typos on switchconf
 -- Jose M Calhariz <jose.calhariz@ist.utl.pt>  Sun, 02 Mar 2014 15:39:09 +0000
switchconf (0.0.11-1) wheezy; urgency=low
  * New upstream version:
    * Makefile: add target dist-exp to build distribution files.
    * Add flag -f with the path to the configuration file.
  * Update debian/rules to version 0.24.
  * Update debian/control with new name and email address of Maintainer.
  * Update copyright.
 -- Jose M Calhariz <jose.calhariz@ist.utl.pt>  Sun, 16 Feb 2014 18:04:22 +0000
switchconf (0.0.10-1) UNRELEASED; urgency=low
  * New upstream version:
    * Fix return code on error.
    * Use syslog system to report errors.
 -- Jose M Calhariz <jose.calhariz@ist.utl.pt>  Thu, 16 Jan 2014 20:23:46 +0000

In a world far away, in the dark Land of Digitos only populated by machines and computers, the evil Mister Woo was ruling over all. Over time, this terrible dictator was becoming a horrendous fire-eyed giant, walking the whole day by vibrating the heavy steps into his Kingdom, leaving behind him a trail of smoke and terror. Mr. Woo always wore a long, shabby and dirty top hat that had once been white, so old and ragged that he could not even keep it up straight on his head. Throughout the Land of Digitos, the inhabitants computers were scattered, each <Read more >

the upload of perl 5.22 to unstable some days ago provided ample opportunity to fix some new RC bugs. here's the list of my work:

• #768687 src:libdata-hal-perl: "libdata-hal-perl: FTBFS: test suite broken by newer liburi-namespacemap-perl versions"
  add patch from new upstream's git repo (pkg-perl)
• #787912 src:libdata-dump-streamer-perl: "libdata-dump-streamer-perl: FTBFS with perl 5.22"
  upload new upstream release (pkg-perl)
• #789142 src:libdata-hal-perl: "libdata-hal-perl: FTBFS with perl 5.22 (Module::Build)"
  upload with explicit build dependency on Module::Build (pkg-perl)
• #791520 libmojomojo-perl: "libmojomojo-perl: FTBFS: test failures"
  close bug in the BTS, already fixed since months (pkg-perl)
• #801659 libxml-compile-dumper-perl: "libxml-compile-dumper-perl: depends on libdata-dump-streamer-perl, broken by perl 5.22"
  close as the dependency is fixed (pkg-perl)
• #808284 libalien-wxwidgets-perl: "libalien-wxwidgets-perl: Broken dependencies in binary package after BinNMU"
  fix wxwidgets version detection logic (pkg-perl)
• #808310 libchemistry-formula-perl: "libchemistry-formula-perl: bogus dependency on perlapi-5.20.2"
  fix perl library paths in debian/rules, NMU
• #808327 wmanager: "wmanager: Depends on virtual package "perl5" which will is gone with perl/5.22"
  sponsor maintainer upload
• #808395 src:libprelude: "libprelude: FTBFS everywhere"
  add patch to handle swig changes, NMU
• #808412 src:ippl: "ippl: Depends on virtual package "perl5-base" which is gone with perl/5.22"
  drop perl5-base dependency, NMU with maintainer's permission
• #808454 src:libdata-faker-perl: "libdata-faker-perl: FTBFS under some locales (eg. fr_CH.UTF-8)"
  set C locale for tests (pkg-perl)
• #808473 liblemonldap-ng-manager-perl: "liblemonldap-ng-manager-perl: manager unaccessible without doc symlink in /var/lib/lemonldap-ng"
  upload package prepared by Xavier Guimard (pkg-perl)
• #808474 liblemonldap-ng-manager-perl: "liblemonldap-ng-manager-perl: Manager shows garbage where the menu is supposed to be"
  upload package prepared by Xavier Guimard (pkg-perl)
• #808480 libdevel-bt-perl: "libdevel-bt-perl: FTBFS on mips*: test failures"
  add (build)dep on perl-debug (pkg-perl)
• #808489 src:acm: "acm: FTBFS: Type of arg 1 to dbmclose must be hash (not constant item) at ./create-tables-5 (perl 5.22?)"
  send patch to BTS
• #808507 uwsgi-plugin-mono: "uwsgi-plugin-mono: Please refresh architectures list for current Mono in Unstable"
  sponsor upload for jonas
• #808825 libperl-apireference-perl: "libperl-apireference-perl: FTBFS: missing support for Perl 5.22.1"
  add support for 5.22.1 (pkg-perl)
• #809006 libnet-cups-perl: "libnet-cups-perl: empty package"
  add patch to fix broken version check in Makefile.PL (pkg-perl)

the upload of perl 5.22 to unstable some days ago provided ample opportunity to fix some new RC bugs. here's the list of my work:

• #768687 src:libdata-hal-perl: "libdata-hal-perl: FTBFS: test suite broken by newer liburi-namespacemap-perl versions"
  add patch from new upstream's git repo (pkg-perl)
• #787912 src:libdata-dump-streamer-perl: "libdata-dump-streamer-perl: FTBFS with perl 5.22"
  upload new upstream release (pkg-perl)
• #789142 src:libdata-hal-perl: "libdata-hal-perl: FTBFS with perl 5.22 (Module::Build)"
  upload with explicit build dependency on Module::Build (pkg-perl)
• #791520 libmojomojo-perl: "libmojomojo-perl: FTBFS: test failures"
  close bug in the BTS, already fixed since months (pkg-perl)
• #801659 libxml-compile-dumper-perl: "libxml-compile-dumper-perl: depends on libdata-dump-streamer-perl, broken by perl 5.22"
  close as the dependency is fixed (pkg-perl)
• #808284 libalien-wxwidgets-perl: "libalien-wxwidgets-perl: Broken dependencies in binary package after BinNMU"
  fix wxwidgets version detection logic (pkg-perl)
• #808310 libchemistry-formula-perl: "libchemistry-formula-perl: bogus dependency on perlapi-5.20.2"
  fix perl library paths in debian/rules, NMU
• #808327 wmanager: "wmanager: Depends on virtual package "perl5" which will is gone with perl/5.22"
  sponsor maintainer upload
• #808395 src:libprelude: "libprelude: FTBFS everywhere"
  add patch to handle swig changes, NMU
• #808412 src:ippl: "ippl: Depends on virtual package "perl5-base" which is gone with perl/5.22"
  drop perl5-base dependency, NMU with maintainer's permission
• #808454 src:libdata-faker-perl: "libdata-faker-perl: FTBFS under some locales (eg. fr_CH.UTF-8)"
  set C locale for tests (pkg-perl)
• #808473 liblemonldap-ng-manager-perl: "liblemonldap-ng-manager-perl: manager unaccessible without doc symlink in /var/lib/lemonldap-ng"
  upload package prepared by Xavier Guimard (pkg-perl)
• #808474 liblemonldap-ng-manager-perl: "liblemonldap-ng-manager-perl: Manager shows garbage where the menu is supposed to be"
  upload package prepared by Xavier Guimard (pkg-perl)
• #808480 libdevel-bt-perl: "libdevel-bt-perl: FTBFS on mips*: test failures"
  add (build)dep on perl-debug (pkg-perl)
• #808489 src:acm: "acm: FTBFS: Type of arg 1 to dbmclose must be hash (not constant item) at ./create-tables-5 (perl 5.22?)"
  send patch to BTS
• #808507 uwsgi-plugin-mono: "uwsgi-plugin-mono: Please refresh architectures list for current Mono in Unstable"
  sponsor upload for jonas
• #808825 libperl-apireference-perl: "libperl-apireference-perl: FTBFS: missing support for Perl 5.22.1"
  add support for 5.22.1 (pkg-perl)
• #809006 libnet-cups-perl: "libnet-cups-perl: empty package"
  add patch to fix broken version check in Makefile.PL (pkg-perl)

Before I disappear into the Japanese winter holidays, here the Christmas update of all TeX Live packages. Nothing spectacular here, just the usual bunch of updates of loads of packages. There is a bug with respect to a file move from one package to another, will be fixed in an upload soon. Updated packages apnum, appendix, archaeologie, babel, babel-french, babel-greek, babel-hungarian, bangorcsthesis, beamer-verona, bhcexam, bibarts, bidi, bxjscls, chemfig, commado, comprehensive, context, cslatex, csplain, ctanify, doclicense, dvips, ejpecp, exsheets, fbb, fibeamer, fithesis, fontools, francais-bst, gitinfo2, glossaries, gnuplottex, greek-fontenc, hyph-utf8, indextools, ksp-thesis, l3build, l3experimental, l3kernel, l3packages, latexcourse-rug, lollipop, lstbayes, lualibs, luaotfload, luatexja, luatexko, luatodonotes, make4ht, mcf2graph, media9, mex, mfirstuc, mhchem, mptopdf, nameauth, nevelok, newtx, nicetext, nucleardata, ocgx2, pageslts, petri-nets, phonrule, pkuthss, powerdot, proofread, proposal, pst-labo, pst-solides3d, reledmac, sapthesis, serbian-lig, showlabels, t2, tcolorbox, tempora, testhyphens, tetex, tex4ebook, tex4ht, texlive-scripts, texsis, thuthesis, toptesi, tudscr, ucharcat, versonotes, xcharter, xepersian, xifthen, xindy, xint. New packages beamertheme-detlevcm, beamertheme-metropolis, beamertheme-phnompenh, beamer-verona, bitpattern, carbohydrates, delimseasy, drawmatrix, einfuehrung2, ellipse, ffslides, gitlog, greektonoi, ksp-thesis, longfbox, options, simpler-wick, unicode-data. Enjoy.

Review: The Steerswoman, by Rosemary Kirstein

Series:	Steerswomen #1
Publisher:	Del Rey
Copyright:	1989, 2003
Printing:	2003
ISBN:	0-345-46105-3
Format:	Trade paperback
Pages:	264

I read this novel as part of The Steerswoman's Road omnibus, which is the edition reflected in the metadata (except for the page count, which is just this novel). Rowan is a steerswoman, a member of an order of traveling scholars in a world of generally medieval customs. This is a world of small villages and town blacksmiths, of swords, sailing ships, and lots of walking. Steerswomen (the order does include some men, but only rarely; the gender balance is left delightfully unexplained and unremarked) mostly travel routes through the Inner Lands until they decide to retire and do research and study. Sometimes, though, they get on the trail of something unexplained, and are driven to explain it. That's the case for Rowan at the start of this book: she's run across several peculiar flat jewels. No one seems to know what they are, their pattern of distribution is odd, and they're discovered in some decidedly strange places, such as embedded deep in a tree. It's a puzzle, and Rowan is determined to understand it. The Steerswoman opens with Rowan investigating a jewel owned by an innkeeper, and a chance meeting in his inn with an Outskirter who wears a whole belt of the same jewels. The Outskirters are nomadic tribes from the far west known for their prickly attitude, their ability in warfare, and their occasional raids. Those who live in the Inner Lands consider them barbarians. But Bel is curious, thoughtful, and happy to tell Rowan of the origin of her belt: her father found a huge number of the jewels embedded in the side of a cliff, far into the Outskirts. Rowan is immediately tempted to go there, but she has to report to the Archives first. Much to her surprise, Bel asks to accompany her. And then wizards start trying to kill them. The steerswomen are Kirstein's best bit of world-building and the anchor around which the rest of the story is told. Steerswomen have to answer all questions they're asked, truthfully. In return, they can ask a question of anyone and have to be answered truthfully. If anyone refuses to answer, or tells a deliberate lie, they're placed under the steerswomen's ban, and no steerswoman will answer their questions. This is woven deep into the culture of the Inner Lands... except for the wizards, who refuse to explain what they're doing or how to anyone, are under the ban, and don't care. They protect cities from dragons, build magical lighting, and occasionally start wars with other wizards in which numerous people die. They're effectively the rulers of this world insofar as it has rulers, and they're apparently quite interested in Rowan's search for these unexplained jewels. Rowan is a wonderful character. At the start of the book, she's the only steerswoman that the reader knows, so much of her early behavior is also world-building, showing us steerswomen. But as the story develops, we meet other steerswomen and Rowan develops into her own character: innocent in a way, but determined, ethical, and with a very deep store of self-knowledge and inner contemplation. I found the middle part of the book somewhat frustrating for the same reasons Rowan did. The ending lets her shine, in her own way, and it's deeply satisfying. The Steerswoman does pick up a third character along the way, a young boy named Will who hopes to become a wizard's apprentice, and to whom I never warmed. Part of the problem was structural: he's very suspicious of characters that the reader knows are entirely honorable. This is a difficult tone to pull off without irritating me, and Kirstein doesn't quite manage. She also shifts the story to the Will's perspective from time to time, and I never found his viewpoint very interesting. I warmed to him a bit by the climax, but I still don't think he added much to the story. Bel, though... Bel competes with Rowan as best character of this book. The other characters all have roles to play: Rowan is the steerswoman, integral to the world-building, and Will exemplifies another corner of the analytical process so central to this book and represents the appeal of the wizards. But Bel is just herself: irreverent, curious, loyal, dangerous, decisive, and adventurous. Rowan is the heart of the book and the primary protagonist, but I think Bel is its soul. I haven't said too much about the themes of this book, intentionally. Kirstein is doing something very interesting and subtle with the reader's expectations of a medieval world with wizards, and I think it's better experienced without spoilers. But it's also a character-driven story, a story of unlikely friendship between two very different women, and a story about the value of being true to yourself even when it's exceptionally dangerous. Rowan delighted me immediately, Bel grew on me over the course of the story, and the rough patches in the middle of the book faded in comparison to an excellent ending. Unfortunately, this is only part of a story. There is a climax, and we do know what the jewels are by the end of the book. But the journey has raised many more questions, most of which are not solved. The world has become far more complicated. Rowan has a lot left to learn and investigate. I recommend the omnibus, or getting the ebooks from Amazon where you can quickly get more, because you'll probably want to immediately start the second book. Followed by The Outskirter's Secret. Rating: 8 out of 10

The Software Freedom Conservancy is currently running a fundraising program in an attempt to raise enough money to continue funding GPL compliance work. If they don't gain enough supporters, the majority of their compliance work will cease. And, since SFC are one of the only groups currently actively involved in performing GPL compliance work, that basically means that there will be nobody working to ensure that users have the rights that copyright holders chose to give them.

Why does this matter? More people are using GPLed software than at any point in history. Hundreds of millions of Android devices were sold this year, all including GPLed code. An unknowably vast number of IoT devices run Linux. Cameras, Blu Ray players, TVs, light switches, coffee machines. Software running in places that we would never have previously imagined. And much of it abandoned immediately after shipping, gently rotting, exposing an increasingly large number of widely known security vulnerabilities to an increasingly hostile internet. Devices that become useless because of protocol updates. Toys that have a "Guaranteed to work until" date, and then suddenly Barbie goes dead and you're forced to have an unexpected conversation about API mortality with your 5-year old child.

We can't fix all of these things. Many of these devices have important functionality locked inside proprietary components, released under licenses that grant no permission for people to examine or improve them. But there are many that we can. Millions of devices are running modern and secure versions of Android despite being abandoned by their manufacturers, purely because the vendor released appropriate source code and a community grew up to maintain it. But this can only happen when the vendor plays by the rules.

Vendors who don't release their code remove that freedom from their users, and the weapons users have to fight against that are limited. Most users hold no copyright over the software in the device and are unable to take direct action themselves. A vendor's failure to comply dooms them to having to choose between buying a new device in 12 months or no longer receiving security updates. When yet more examples of vendor-supplied malware are discovered, it's more difficult to produce new builds without them. The utility of the devices that the user purchased is curtailed significantly.

The Software Freedom Conservancy is one of the only organisations actively fighting against this, and if they're forced to give up their enforcement work the pressure on vendors to comply with the GPL will be reduced even further. If we want users to control their devices, to be able to obtain security updates even after the vendor has given up, we need to keep that pressure up. Supporting the SFC's work has a real impact on the security of the internet and people's lives. Please consider giving them money.

comments

In my previous post, I talked about the udev hack I had used with the YubiKey and how it was not the correct way to do things. I recieved a lot of feedback on this post, and here I'm hoping to summarise what the correct way to do it is. The rule I was originally using was:

SUBSYSTEMS=="usb", ATTRS idVendor =="1050",ATTRS idProduct =="0111", OWNER="irl"  

The problem with this rule was that it always made my own username the owner of the YubiKey. For my use on my laptop, this was fine, as I'm the only user ever logged into my laptop, but this is not the right way to do this. On a multi-user system you would want the user logged into the console, and so the one that has plugged in the USB device by implication, to be the owner of the device. Sam Morris followed up to my last post by e-mail to suggest the following rule:

SUBSYSTEMS=="usb", ATTRS idVendor =="1050", ATTRS idProduct =="0111", TAG+="uaccess"  

The difference here is that instead of explicitly setting an owner, the uaccess tag is added to the device. This tag has meaning to systemd-logind and will add the necessary ACLs to the device to allow the console user to access it. The ACL should also be removed by systemd-logind when you log out. He also suggested using getfacl (from the acl package) to check the ACLs that have been assigned to devices.

irl@orbiter$ getfacl /dev/hidraw0  
# file: hidraw0
# owner: irl
# group: root
user::rw-  
user:irl:rw-  
group::---  
mask::rw-  
other::---  

Here we can see that the device has been set to being owned by my username. (Note that on your system, the YubiKey may have a different path, check your dmesg output to see what device name it is assigned.) If you don't have systemd-logind available, fear not as there is an alternative approach you can take that was suggested by Simon Josefsson, who actually wrote a blog post in 2014 about using an offline GnuPG master key with subkeys on a YubiKey. If you install the pcscd package this will provide you with a daemon that runs as root and provides access to the smartcard for ordinary users. I haven't looked at how pcscd handles limiting access to the device for other users as this isn't an approach I've taken. Thanks to everyone who gave feedback, I feel like I've learnt something and taken another step closer to doing things The Right Way .

Around three years ago, I created the isenkram system to get a more practical solution in Debian for handing hardware related packages. A GUI system in the isenkram package will present a pop-up dialog when some hardware dongle supported by relevant packages in Debian is inserted into the machine. The same lookup mechanism to detect packages is available as command line tools in the isenkram-cli package. In addition to mapping hardware, it will also map kernel firmware files to packages and make it easy to install needed firmware packages automatically. The key for this system to work is a good way to map hardware to packages, in other words, allow packages to announce what hardware they will work with. I started by providing data files in the isenkram source, and adding code to download the latest version of these data files at run time, to ensure every user had the most up to date mapping available. I also added support for storing the mapping in the Packages file in the apt repositories, but did not push this approach because while I was trying to figure out how to best store hardware/package mappings, the appstream system was announced. I got in touch and suggested to add the hardware mapping into that data set to be able to use appstream as a data source, and this was accepted at least for the Debian version of appstream. A few days ago using appstream in Debian for this became possible, and today I uploaded a new version 0.20 of isenkram adding support for appstream as a data source for mapping hardware to packages. The only package so far using appstream to announce its hardware support is my pymissile package. I got help from Matthias Klumpp with figuring out how do add the required metadata in pymissile. I added a file debian/pymissile.metainfo.xml with this content:

<?xml version="1.0" encoding="UTF-8"?>
<component>
  <id>pymissile</id>
  <metadata_license>MIT</metadata_license>
  <name>pymissile</name>
  <summary>Control original Striker USB Missile Launcher</summary>
  <description>
    <p>
      Pymissile provides a curses interface to control an original
      Marks and Spencer / Striker USB Missile Launcher, as well as a
      motion control script to allow a webcamera to control the
      launcher.
    </p>
  </description>
  <provides>
    <modalias>usb:v1130p0202d*</modalias>
  </provides>
</component>

The key for isenkram is the component/provides/modalias value, which is a glob style match rule for hardware specific strings (modalias strings) provided by the Linux kernel. In this case, it will map to all USB devices with vendor code 1130 and product code 0202. Note, it is important that the license of all the metadata files are compatible to have permissions to aggregate them into archive wide appstream files. Matthias suggested to use MIT or BSD licenses for these files. A challenge is figuring out a good id for the data, as it is supposed to be globally unique and shared across distributions (in other words, best to coordinate with upstream what to use). But it can be changed later or, so we went with the package name as upstream for this project is dormant. To get the metadata file installed in the correct location for the mirror update scripts to pick it up and include its content the appstream data source, the file must be installed in the binary package under /usr/share/appdata/. I did this by adding the following line to debian/pymissile.install:

debian/pymissile.metainfo.xml usr/share/appdata

With that in place, the command line tool isenkram-lookup will list all packages useful on the current computer automatically, and the GUI pop-up handler will propose to install the package not already installed if a hardware dongle is inserted into the machine in question. Details of the modalias field in appstream is available from the DEP-11 proposal. To locate the modalias values of all hardware present in a machine, try running this command on the command line:

cat $(find /sys/devices/ grep modalias)

To learn more about the isenkram system, please check out my blog posts tagged isenkram.

I was first interested in the idea of using a smartcard to store OpenPGP subkeys when I joined the Free Software Foundation Europe as a Fellow and recieved my FSFE Fellowship Card. By performing all cryptographic operations on the smartcard it would remove almost all the routes by which the secret key material could be compromised as the host operating system never has access to that secret material. I decided that this was something I wanted to try out and I purchased two Cherry G83-6644 keyboards. One of the nice things I noticed about this product was that it was both FIPS 201 approved and GOST R approved. If both the Americans and the Russians could agree it was a good keyboard, it had a good chance of being a good keyboard. A little udev magic to handle permissions and the card worked great, but there was a problem. This was not the most friendly form-factor and a USB keyboard was a bit big to be carrying around to use the smartcard with my laptop. I intended to get a smaller reader for my laptop but never did and the Fellowship card fell into disuse. Later, I came across the YubiKey NEO. The YubiKey NEO is capable of emulating an OpenPGP smartcard, just like the Fellowship card, but in the form-factor of a USB stick. This improved form factor was enough to make me give it a go. Since August 2015 I've been using a YubiKey NEO to store my OpenPGP subkeys and, excluding some occasional udev mishaps, it's been working great. When you first get the YubiKey NEO, it does not have the OpenPGP applet enabled. You'll need to enable it yourself using the ykpersonalize tool:

sudo apt install yubikey-personalization  
sudo ykpersonalize -m 82  

Once you've enabled the OpenPGP module, the USB product ID will change, and you can now add a udev rule that will allow you to interact with the device when it's plugged in as your normal user.

/etc/udev/rules.d/99-yubikeys.rules:
------------------------------------
SUBSYSTEMS=="usb", ATTRS idVendor =="1050",ATTRS idProduct =="0111", OWNER="irl"  

This is not the correct way to do this. I've set it so that any YubiKey with the OpenPGP module inserted is set to be owned by my username (irl) when the correct way to do this would be to have it set to the current console user. I do not know enough udev magic to know how to do that. UPDATE: I recieved a lot of good feedback on this, which you can find here. Of course, for my key 0xE9846C49, this key started life as an ordinary key just stored on my laptop, so seperating subkeys onto the YubiKey has not massively increased security as an attacker that has stolen the secret key material can generate new subkeys. I would hopefully notice these new rogue subkeys (I do monitor keyservers for changes to my key regularly), but I would prefer to make the possibility of the key being compromised as low as possible. For this reason I am performing a key transition to a new key, F540ABCD, where the master key is stored offline. In my next post, hopefully within a day or so, I'll explain how I used Tails to generate a key offline and load the subkeys into the YubiKey.