I always enjoy this time of year: lots of peace and quiet and time to work on whatever I feel like focusing on. That's been watching a lot of speedrunning and League of Legends, but also experimenting with systemd and upstart. I've now ported lbcd to both "properly," meaning that I make full use of their features as far as I currently understand them. I have some more packaging work to do, and need to make a release, but of course I started fixing various other things since I was in the code anyway, and now I don't want to release it without some testing. And that prompted another digression, since I didn't have a good test framework for spawning the server and pounding on it. That finally brings this journal entry to its actual topic: a new release of C TAP Harness. This release adds a new pair of functions, diag_file_add() and diag_file_remove(), which tell the TAP library to take the contents of log files as an additional source of diag() messages. This produces much nicer, and more readable, output from test cases that involve forking a background server that produces output to standard output and standard error. That output can be directed to a file and then included in the test output stream, properly tagged and in sequence with the result messages. You can get the latest release from the C TAP Harness distribution page.

For a number of weeks now, I have been forwarding traffic being sent to codesearch.debian.net to an instance of Debian Code Search running at Rackspace s public cloud offering. I feel like it s overdue to announce how they have been supporting the project and what that means. Context First of all, let s provide some context. Debian Code Search was launched in November 2012, hosted entirely on my private server. Since DebConf 13, I am in contact with DSA in order to get Code Search running on a DSA-provided machine and make it an official Debian service. Code Search runs best on flash storage, and only with adequate resources can we enable some use cases (e.g. package-level results) and make sure the existing use cases work at all (we currently have timeouts for some queries). Unfortunately, flash storage is scarce in Debian, hence we couldn t get any for Code Search. At some point, I got the suggestion to ask Rackspace for help, since they are quite friendly to the Open Source community. They agreed to help us out with a generous amount of resources in their public cloud offering! This means I can run Code Search at Rackspace the way it is meant to be run: with the index sharded onto 6 different machines and the source code being searched on fast flash storage. Concerns Now, when using third-party infrastructure, there are always two big concerns: proprietary infrastructure and vendor lock-in. As for the proprietary aspect, Rackspace s public cloud offering is based on OpenStack, which is FOSS. Granted, they have a couple of extensions that are not (yet?) released in OpenStack, but those are minor details and any automation that we use can trivially be ported to any other OpenStack offering. Who knows, maybe in the future we use OpenStack in Debian, too? Given the OpenStack situation, I am not concerned about vendor lock-in. However, to specifically address this concern and err on the side of caution, attention will be paid to keep Code Search able to run on non-cloud infrastructure, such that we can run our own instance on DSA-provided hardware. My current intention is that this instance will be the fall-back that we can use should there ever be problems with Rackspace. So far, however, I am very happy with Rackspace s stability. Future There are a number of improvements waiting: for users in the United States, traffic first goes to my server in Europe and then back to Rackspace in the US. Eventually, we should get rid of this indirection. Perhaps we can also spin up another instance in Europe eventually. Furthermore, Rackspace recently announced new available hardware, which we are not yet making use of. I expect a big speed-up, but will have to do some careful benchmarking. Also, I have some interesting performance data, which will be shared in subsequent blog posts. Stay tuned :). Conclusion I d like to thank Rackspace very much for their generous support of the Debian project and Code Search in particular. I hope you look forward to the upcoming posts with more details. Also, to be perfectly clear about it: I also thank DSA for their help, and hope they will continue working with me to have our independent (yet slower) instance of Code Search running on Debian hardware.

available from unstable, and hopefully soon from testing, too! The longer story: The xbmc package has been uninstallable and unbuildable in Debian unstable for quite some time. Mainly due to differing preferences of the XBMC project and Debian. Original XBMC source includes several embedded libraries, some patched to work with XBMC perfectly and to provide the best user experience the XBMC project prefers building XBMC with those libraries. In Debian, on the other hand, the recommended practice is not embedding libraries, but using the packaged versions instead to reduce the amount of security updates in case a library needs a security related fix, to save space on mirrors and to avoid divergence between the embedded versions of the libraries. One consequence of using externally packaged libraries is the need for making XMBC work with newer versions of the external libraries even when the embedded one would still work perfectly or (in some cases) there are even breakages due to changing APIs or new bugs in the library. XBMC depends on many libraries and the changes to them in Debian used to break one or another XBMC use case from time to time. The XBMC project received many direct bug reports from users of the Debian-shipped XBMC package which were harder than necessary to handle due to the lack of clear differentiation from the .deb packages provided directly by
them and using the embedded libraries. To help both users and developers the xbmc package starts using the XBMC from Debian name on the main screen and in the logs, the version number used inside the application is set to the Debian package s version, and README.Debian directs users of the package to Debian s BTS instead of XBMC s forums. The most notable difference between XBMC and XBMC from Debian is that XBMC uses
its embedded patched FFmpeg, while XBMC from Debian uses libav. If movies play too slow, too fast, without sound or too loud, you should definitely check BTS first. Happy Holidays and don t stay too much in front of the screen if XBMC from Debian happens to work for hours without any crash!

One topic that often gets discussed when it s near election time is whether clubs and societies should be political . Some organisations are limited in what they can do, for example in some jurisdictions religious organisations can theoretically lose their tax exempt status if they advocate for one party. In practice any organisation that has a wide membership will have a variety of political views represented so a policy of directly supporting one candidate or party is likely to lose some members. A common practice among some clubs is to send questionnaires to parties before elections. This might cause a policy change in the parties that do whatever it takes to get votes (as opposed to the parties who devise policy based on principle). But it also provides members a list of how the parties compare on the basis of the criteria that matter to the club. I think that organisations such as Linux Australia [1] and the Linux Users of Victoria [2] should send such questionnaires and publish an analysis of the results. I previously suggested a few questions that could be asked [3], the last one received some negative comments for being too tabloid but the others got some agreement. But obviously there would need to be some discussion about which questions are in scope and how they should be asked. Such a discussion would take a while and would need to be started well before an election was called, I think if we start now we should be able to get it done before the next federal election is called. There is one Australian political party that has a consistent record of having IT policies that are in line with the general aims of Linux Australia and which also has policies that meet the social standards that are generally agreed by most of the membership (EG opposing discrimination). But I know that there are some members of the Linux community who advocate various forms of discrimination and would vote accordingly so advocating for that party would get some negative reactions. But if someone wants to vote for a party that advocates discrimination against minority groups I don t think that there s any harm in providing information to allow them to vote for a pro-discrimination party that has a reasonable IT policy. In any case it doesn t seem likely that we can get most of the membership of an organisation like Linux Australia to agree on what parties are unacceptable, so sending a questionnaire to all parties avoids that debate. I would like to see this sort of thing done by LUGs for all state and territory elections. I will be involved in the process with LUV for the Victorian elections, but I have to just hope that my blog posts inspire people in other states and territories if anyone has already started on this then please let me know. I will also be involved with getting this done for the federal elections with Linux Australia, hopefully this post will help get people interested in that.

• [1] http://linux.org.au/
• [2] http://luv.asn.au/
• [3] http://etbe.coker.com.au/2009/03/17/lobbying-for-free-software/

The Nexus 5 is the latest Android phone to be endorsed by Google (and manufactured by LG). It s getting good reviews and the price is good for the specs. I just bought one for my wife, I got her the 32G version because when I bought her a Nexus 4 at the start of the year [1] I chose the 8G version and regretted it ever since. The size of apps is always increasing (some Android games need more than 1G of storage) and higher resolution screens drives the use of high resolution video. Appearance Above I have pictures of the Nexus 4, the Nexus 5, and the Samsung Galaxy Note 2. The photo of the phone backs captures part of the sparkling pattern on the back of the Nexus 4 and it looks much better in real life (IMHO) because it shimmers as you move the phone. The Nexus 4 looks so good that there s even a transparent case specifically designed to show off the rear panel [2]. It doesn t seem likely that anyone will design such a transparent case for the Nexus 5, it s a good phone to cover up IMHO. The Note 2 isn t the most attractive phone, but I think it has a streamlined elegance of being optimised for it s function. The Nexus 5 has it s camera sticking out, it would be better if they had just made the entire phone thicker and given it a bigger battery but for people who don t want good battery life I guess it s a way of providing a better focal length without making the phone thicker. Sticking the IMEI number on the back of the phone will be useful on rare occasions (and might be a security issue on more occasions) but it definitely makes the phone less attractive. Full HD The quality of the Full HD (1920*1080) display is obvious. The text is slightly clearer when viewing maps and the graphics in Ingress look nicer. Before I used the Nexus 5 I didn t think that there would be any benefit in having such a high resolution in a phone but now I realise that I was wrong. The higher resolution is clearly better. Chris Chavez wrote an article for Phandroid about a rumored Samsung phone with a 2560*1440 display [3]. If such a device had a 6.6 display (IE a new version of the Galaxy Mega) then it would have the same dot-pitch as the Nexus 5. If such a device had a 5.5 display (like the Galaxy Note 3) then it would have a 15% greater DPI than the Nexus 5. It seems that a higher DPI provides a real benefit and this is probably the biggest reason to choose the Nexus 5 over the Nexus 4 and most other Android devices. Comparing with the Nexus 4 The Nexus 5 has the same amount of RAM (2G), a slightly larger display (4.95 vs 4.7 ), higher resolution (a big deal), faster CPU and GPU, and optical zoom. Faster CPU isn t usually going to be a big deal (apart from the fact that more CPU power is needed as well as more GPU power to drive the higher resolution display). The Nexus 5 can come with 16G or 32G of storage while the Nexus 4 has options of 8G and 16G. If you want more than 16G of storage then that s a real benefit for the Nexus 5, but if you only need 16G then it s not an issue. It seems that when playing Ingress on a Nexus 5 it s more likely that running another program (such as Google Hangouts) will cause Ingress to be reloaded than it does on a Nexus 4 or a Galaxy Note 2. While I haven t done a good comparison of the Nexus 4 and the Nexus 5 in this regard I ve compared the Galaxy Note 2 and the Nexus 5 well. My Galaxy Note 2 (which has many daemons running) is much less likely to cause a reload of Ingress (IE have run low on memory and terminated Ingress) than the Nexus 5 my wife is using (which has very little running). So it seems that the OS build on the Nexus 5 uses more memory than the Galaxy Note 2. The Nexus 5 has Gorilla Glass 3 vs Gorilla Glass 2 on the Nexus 4. As my older Android phones with Gorilla Glass 1 (Galaxy S and Sony Ericsson Xperia X10i) didn t get any scratches that matter I don t think this is a benefit for me. Maybe if I lived near a beach I d care more about this. I think that the most significant benefit of the Nexus 5 over the Nexus 4 is the higher resolution display. The optical zoom should provide a theoretical benefit when taking photos, whether that results in better pictures in practice would probably depend on how you hold your phone, the available light, and other factors. I think that if it was possible to buy a Nexus 4 at a sensible price (IE something less than the $250 that Google last charged) then for most people the Nexus 4 would be a better choice than the Nexus 5. But as ebay is full of Nexus 4 phones selling for a higher prices than the Nexus 5 it seems that buying a Nexus 5 is the only option. The range of phones that Kogan sells [4] doesn t have anything for the same price that compares on features. Heat The heat produced by the Nexus 5 is significant and noticable. After some light Ingress playing on a cold day my Galaxy Note 2 with a gel case (that keeps it warm) reported itself as having a battery temperature of 34C. My wife s Nexus 5 reported a temperature of 43C. While the thermometer in the phone might not be the most accurate I don t think there was an accuracy problem, holding my wife s phone was unpleasant and felt like it could burn my hand if I held it tight (40C is the minimum temperature for burns). It seems that a Nexus 5 isn t a good choice if you want to play Ingress in a warm part of the world (EG most of Australia in summer). Also heat dissipated is directly proportional to power use which is going to be a problem for a phone that doesn t permit replacing it s battery. Conclusion I m quite disappointed with the Nexus 5. I expected it to be at least as good as the Nexus 4 in every way and better in many ways. Instead it s not always as good as the Nexus 4 and the ways that it is better won t necessarily provide benefits for everyone. The heat and power use problems are really going to hurt the use of it. But I guess we can always hope that Google release a new Android build that reduces the power use, they might even have a new build that uses less RAM too. I would not consider getting a Nexus 5 for my own use. For my use the Note 2 is clearly more suitable, the larger screen more than compensates for the clarity that the Nexus 5 gets from it s high resolution display. Also I REALLY like having a hardware home button. I ll probably get a Note 3 when the price drops, I m not interested in paying $649 for a phone and I m also not interested in replacing a phone that s less than a year old. So maybe I ll get a Note 3 in the second half of next year.

• [1] http://etbe.coker.com.au/2013/05/29/nexus-4/
• [2] http://etbe.coker.com.au/2013/08/13/nexus-4-ringke-fusion-case/
• [3] http://tinyurl.com/nhfkmg3
• [4] http://www.kogan.com/au/shop/phones/android/?order_by=price

Review: They Had to Go Out, by Gary J. Hudson

Publisher:	Xlibris
Copyright:	2008
ISBN:	1-4363-8132-0
Format:	Trade paperback
Pages:	165

They Had to Go Out, as noted on the cover, is the story of the tragedy of the Triumph and the Mermaid, a marine incident that occurred off the Oregon coast of the United States near the mouth of the Columbia River on January 12, 1961. But it's also much more than that. It's a detailed and thoroughly-researched account of a Coast Guard rescue operation, starting with background on the two coastal lifeboat stations and the types of ships involved. It covers everything from crew backgrounds to equipment issues to the general shape of the subsequent inquiry, and in the process provides a wealth of detailed information about the nature of Coast Guard rescue operations and the technology and equipment available at the time. But, beyond that, it's a gripping story, in part because of the authenticity of the authorial voice. Gary Hudson spent twenty years in the Coast Guard, ten on coastal lifeboat stations like the ones in this book, and was assigned to Point Adams (the primary station involved in this story) until 12 days before the incident, when he transferred to a light station for unrelated reasons. The writing is rough, the paragraphs are not always well-organized, the punctuation doesn't always end up in the right place, and it could have used an editor (Xlibris is a printing service company for self-publishing). But he understands the subject matter completely, and he clearly spent years of effort putting together all the details of the story. The first few chapters, where he establishes the necessary background and tells a few related stories, feel quite rough, but once he gets into the heart of the story, the rough prose stops mattering. Obviously, one of the things that makes this story so appealing is that it's a gripping human story, with the unconstructed and unexpected twists and turns of reality rather than a plot. Hudson has lived the life of the people he's writing about and can put many of their fears and thoughts into words. He captures some of what it would feel like to be out on the water in the middle of the worst seas that most of them had ever seen. And reality is unpredictable. I'm avoiding giving the exact details of what happened and I would recommend not researching the incident on Google if you plan to read this book; there's a lot of drama here, and spoilers are possible. Hudson's factual, detailed narrative style gives the reader a lot of material with which to build mental pictures, and he preserves the drama and the human impact of the story by telling it in straight chronological order. The writing is rough, but he shows a talent for pacing and perspective in the way he weaves together the viewpoints of multiple Coast Guard stations and ship crews. This is also a case study and an accident report, put together with extensive research and scope, but made approachable for the average reader. Hudson takes out the dryness and technical language and weaves the events into a narrative, but he doesn't lose much of the detail. You can know nothing at all about ships or Coast Guard operations and come away from this book with strong opinions about self-righting capabilities (and, more to the point, accurate communication to crews of the capabilities of their vessels). And, by showing a full day of Coast Guard operations (admittedly, a very unusual and difficult day), Hudson also provides the previously unfamiliar reader with a great "day in the life" picture of what Coast Guard lifesaving operations at their most dangerous look like (or at least looked like; one also gets a sense of just how much has improved, and how important the improvements are, in the final chapters). Finally, unlike most accident reports, Hudson carries the story through to the immediate family impact (which may well bring you to tears) and then, given forty years of hindsight, some of the subsequent effects on the people involved. I really liked this. One of the aspects of stories like this that often gets short shrift is that the people involved carry the incident with them for the rest of their lives, often with profound impact. Unlike a movie, where the movie ends and the characters disappear as soon as the primary action is complete, real life has messy and lingering endings, and I think Hudson manages to capture some of that feeling. Some of the best non-fiction books are not written by professional writers. Instead, they're written by people who have both expertise and passion for a particular topic and who know or teach themselves enough about telling a story to manage to get that expertise and passion out on paper. Hudson puts every aspect of this day into the book, from the people to the family impact, from the questionable decisions to the equipment failures and shortages, from the initial conditions through the inquiry and up to the subsequent impact on the lives of the people involved (including, sadly, the Coast Guard's lack of understanding of how to help people with traumatic stress). Some of the paragraphs clunk, some of the sentence construction is awkward, and some of the short biographies are a bit lost in details, but Hudson's desire to tell the complete truth as he was able to reconstruct it, and his deep empathy and understanding of how it felt to the people involved, shine through and carry this book. This is great stuff, and worth seeking out. Recommended. Rating: 9 out of 10

I've said recently that pervasive surveillance is wrong. I don't think anyone from the NSA should have a leadership position in the development or deployment of Internet communications, because their interests are at odds with the interest of the rest of the Internet. But someone at the NSA is in exactly such a position. They ought to step down. Here's the background: The Internet Research Task Force (IRTF) is a body tasked with research into underlying concepts, themes, and technologies related to the Internet as a whole. They act as a research organization that cooperates and complements the engineering and standards-setting activities of the Internet Engineering Task Force (IETF). The IRTF is divided into issue-specific research groups, each of which has a Chair or Co-Chairs who have "wide discretion in the conduct of Research Group business", and are tasked with organizing the research and discussion, ensuring that the group makes progress on the relevant issues, and communicating the general sense of the results back to the rest of the IRTF and the IETF. One of the IRTF's research groups specializes in cryptography: the Crypto Forum Research Group (CFRG). There are two current chairs of the CFRG: David McGrew <mcgrew@cisco.com> and Kevin M. Igoe <kmigoe@nsa.gov>. As you can see from his e-mail address, Kevin M. Igoe is affiliated with the National Security Agency (NSA). The NSA itself actively tries to weaken cryptography on the Internet so that they can improve their surveillance, and one of the ways they try to do so is to "influence policies, standards, and specifications". On the CFRG list yesterday, Trevor Perrin requested the removal of Kevin M. Igoe from his position as Co-chair of the CFRG. Trevor's specific arguments rest heavily on the technical merits of a proposed cryptographic mechanism called Dragonfly key exchange, but I think the focus on Dragonfly itself is the least of the concerns for the IRTF. I've seconded Trevor's proposal, and asked Kevin directly to step down and to provide us with information about any attempts by the NSA to interfere with or subvert recommendations coming from these standards bodies. Below is my letter in full:

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: cfrg@ietf.org, Kevin M. Igoe <kmigoe@nsa.gov>
Date: Sat, 21 Dec 2013 16:29:13 -0500
Subject: Re: [Cfrg] Requesting removal of CFRG co-chair
On 12/20/2013 11:01 AM, Trevor Perrin wrote:
> I'd like to request the removal of Kevin Igoe from CFRG co-chair.
Regardless of the conclusions that anyone comes to about Dragonfly
itself, I agree with Trevor that Kevin M. Igoe, as an employee of the
NSA, should not remain in the role of CFRG co-chair.
While the NSA clearly has a wealth of cryptographic knowledge and
experience that would be useful for the CFRG, the NSA is apparently
engaged in a series of attempts to weaken cryptographic standards and
tools in ways that would facilitate pervasive surveillance of
communication on the Internet.
The IETF's public position in favor of privacy and security rightly
identifies pervasive surveillance on the Internet as a serious problem:
https://www.ietf.org/media/2013-11-07-internet-privacy-and-security.html
The documents Trevor points to (and others from similar stories)
indicate that the NSA is an organization at odds with the goals of the IETF.
While I want the IETF to continue welcoming technical insight and
discussion from everyone, I do not think it is appropriate for anyone
from the NSA to be in a position of coordination or leadership.
----
Kevin, the responsible action for anyone in your position is to
acknowledge the conflict of interest, and step down promptly from the
position of Co-Chair of the CFRG.
If you happen to also subscribe to the broad consensus described in the
IETF's recent announcement -- that is, if you care about privacy and
security on the Internet -- then you should also reveal any NSA activity
you know about that attempts to subvert or weaken the cryptographic
underpinnings of IETF protocols.
Regards,
	--dkg

I'm aware that an abdication by Kevin (or his removal by the IETF chair) would probably not end the NSA's attempts to subvert standards bodies or weaken encryption. They could continue to do so by subterfuge, for example, or by private influence on other public members. We may not be able to stop them from doing this in secret, and the knowledge that they may do so seems likely to cast a pall of suspicion over any IETF and IRTF proceedings in the future. This social damage is serious and troubling, and it marks yet another cost to the NSA's reckless institutional disregard for civil liberties and free communication. But even if we cannot rule out private NSA influence over standards bodies and discussion, we can certainly explicitly reject any public influence over these critical communications standards by members of an institution so at odds with the core principles of a free society. Kevin M. Igoe, please step down from the CFRG Co-chair position. And to anyone (including Kevin) who knows about specific attempts by the NSA to undermine the communications standards we all rely on: please blow the whistle on this kind of activity. Alert a friend, a colleague, or a journalist. Pervasive surveillance is an attack on all of us, and those who resist it are heroes.

This is the end of the year and time for me to look back and summarize what happened to my Debian life during 2013. In short, it clearly seems that this year is the "year after peak of involvment" year. Up to 2010 included, my involvment in Debian constantly increased. 2011 and 2012 have seen some kind of stagnation with still some high involvment in some areas (i18n obviously, DebConf-related stuff, font packaging...) but already some reduction in others (D-I for instance...where the overall involvment of Debian developers is nos quite low, Kibi excepted). But, clearly, in 2013, something changed. And, indeed, it's easy to see what happened. In 2007, I started to motivate myself to resume my practice of sports (I used to be a well-trained volleyball player back in 80's) and I started running. More and more and more and more. 992km in 2008, 1700km in 2009 (and my first marathon), 2200km in 2010 (and my first ultras), 2500km in 2011 (and my first 80km), 2900km in 2012 (and more ultras) and....about 4700km in 2013 (with many many firsts). What changed is now obvious. Running and sports (and related activites such as a lot of socializing with other runners) took over free software activities. Last summer and autumn made it clear, indeed. While I was attending my 10th DebConf in a row (I think we're very few people to have achieved this), it was not my summer's "peak". I spent some great time in Switzerland, still enjoyed a lot meeting again with old and new friends from all over the world. I did some good hacking and achived quite some good things over there. But, still, that was not what I will keep from this summer because.....I had two great moutain races in July and August and *this* is what I'll keep. So, here we are: I'm reducing my involvment in Debian, obviously. Some things are handed over to other people, formally or informally. Some other things will indeed wait for someone to pick them up....or might slowly die as it sometimes happens in this project. I will very probably not attend DebConf14 in Portland even though I have been among the people who were enthusiastic when we picked that bid. But the dates conflict with the Ultra Tour du Mont-Blanc races in Chamonix, where I'll hopefully try to complete my first "over 100km" race in moutains. I will probably decline being part of the Debconf bids team for DC15 as well as the sponsoring team. I nearly stopped working on Samba packages and will not attend SambaXP in May. That's my challenge now. I don't want to completely quit this project and it's indeed harder than it seems, when one's involvment is going down. I'm currently trying to find the right balance to still stay involved in what has been a great part of my life in the last 15-20 years. For instance, I'll try to successfully mentor two applicants from the Outreach Program for Women. Or still continue to work occasionnally on font packages. Or still continue to manage D-I i18n. But you'll be seeing (and hearing) me less. The challenge is to still continue seeing and hearing me about Debian and free software and it's indeed less easy than it seems. I hope I'll succeed.

For a long time now I ve used mechanize (via either Perl or Python) for doing website interaction automation. Stuff like playing web games, checking the weather, or reviewing my balance at the bank. However, as the use of javascript continues to increase, it s getting harder and harder to screen-scrape without actually processing DOM events. To do that, really only browsers are doing the right thing, so getting attached to an actual browser DOM is generally the only way to do any kind of web interaction automation. It seems the thing furthest along this path is Selenium. Initially, I spent some time trying to make it work with Firefox, but gave up. Instead, this seems to work nicely with Chrome via the Chrome WebDriver. And even better, all of this works out of the box on Ubuntu 13.10 via python-selenium and chromium-chromedriver. Running /usr/lib/chromium-browser/chromedriver2_server from chromium-chromedriver starts a network listener on port 9515. This is the WebDriver API that Selenium can talk to. When requests are made, chromedriver2_server spawns Chrome, and all the interactions happen against that browser. Since I prefer Python, I avoided the Java interfaces and focused on the Python bindings:

#!/usr/bin/env python
import sys
from selenium import webdriver
from selenium.common.exceptions import NoSuchElementException
from selenium.webdriver.common.keys import Keys
caps = webdriver.DesiredCapabilities.CHROME
browser = webdriver.Remote("http://localhost:9515", caps)
browser.get("https://bank.example.com/")
assert "My Bank" in browser.title
try:
    elem = browser.find_element_by_name("userid")
    elem.send_keys("username")
    elem = browser.find_element_by_name("password")
    elem.send_keys("wheee my password" + Keys.RETURN)
except NoSuchElementException:
    print "Could not find login elements"
    sys.exit(1)
assert "Account Balances" in browser.title
xpath = "//div[text()='Balance']/../../td[2]/div[contains(text(),'$')]"
balance = browser.find_element_by_xpath(xpath).text
print balance
browser.close()

This would work pretty great, but if you need to save any state between sessions, you ll want to be able to change where Chrome stores data (since by default in this configuration, it uses an empty temporary directory via --user-data-dir=). Happily, various things about the browser environment can be controlled, including the command line arguments. This is configurable by expanding the desired capabilities variable:

caps = webdriver.DesiredCapabilities.CHROME
caps["chromeOptions"] =  
        "args": ["--user-data-dir=/home/user/somewhere/to/store/your/session"],
     

A great thing about this is that you get to actually watch the browser do its work. However, in cases where this interaction is going to be fully automated, you likely won t have a Xorg session running, so you ll need to wrap the WebDriver in one (since it launches Chrome). I used Xvfb for this:

#!/bin/bash
# Start WebDriver under fake X and wait for it to be listening
xvfb-run /usr/lib/chromium-browser/chromedriver2_server &
pid=$!
while ! nc -q0 -w0 localhost 9515; do
    sleep 1
done
the-chrome-script
rc=$?
# Shut down WebDriver
kill $pid
exit $rc

Alternatively, all of this could be done in the python script too, but I figured it s easier to keep the support infrastructure separate from the actual test script itself. I actually leave the xvfb-run call external too, so it s easier to debug the browser in my own X session. One bug I encountered was that the WebDriver s cache of the browser s DOM can sometimes get out of sync with the actual browser s DOM. I didn t find a solution to this, but managed to work around it. I m hoping later versions fix this. :)

2013, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.

Greetings from the FAU Security Team (FAUST), the Uni Erlangen CTF group. We were participating in the RuCTFe competition and made it to 4th place. Following is my write-up on the nsaless service, the main crypto challenge in the competition. nsaless is a nodejs webservice providing a short message service. People can post messages and their followers receive the message encrypted to their individual RSA key.

Yes, the title is just a scootch self-aggrandising, but I m rather chuffed with myself at the moment, so please forgive me. It all started with my phone (a regular Samsung Galaxy S3) suddenly refusing to boot, stuck at the initial splash screen ( Samsung Galaxy SIII GT-I9300 ). After turning it off and on again a few times (I know my basic problem-solving strategies) and clearing the cache, I decided to start looking deeper. In contrast to pretty much every other Android debugging experience ever, I almost immediately found a useful error message in the recovery system:

E:Failed to mount /efs (Invalid Argument)

Excellent! , thought I. An error message. Google will tell me how to fix this! Nope. The combined wisdom of the Internet, distilled from a great many poorly-spelled forum posts, unhelpful blog posts, and thoroughly pointless articles, was simple: You re screwed. Send it back for service. I tried that. Suffice it to say that I will never, ever buy anything from Kogan ever again. I have learnt my lesson. Trying to deal with their support people was an exercise in frustration, and ultimately fruitless. In the end, I decided I d have some fun trying to fix it myself after all, it s a failure at the base Linux level. I know a thing or two about troubleshooting Linux, if I do say so myself. If I really couldn t fix it, I d just go buy a new phone. It turned out be relatively simple. Here s the condensed version of my notes, in case someone wants to follow in my footsteps. If you d like expansion, feel free to e-mail me. Note that these instructions are specifically for my Galaxy S3 (GT-I9300), but should work with some degree of adaptation on pretty much any Android phone, as far as I can determine, within the limits of the phone s willingness to flash a custom recovery.

1. Using heimdall, flash the TeamWin recovery onto your phone (drop into download mode first hold VolDown+Home+Power):

   heimdall flash --recovery twrp.img
   

2. Boot into recovery (VolUp+Home+Power), select Advanced -> Terminal , and take an image of the EFS partition onto the external SD card you should have already in the phone:

   dd if=/dev/block/mmcblk0p3 of=/external_sd/efs.img
   

3. Shutdown the phone, mount the SD card on your computer, then turn your EFS partition image into a loopback device and fsck it:

   sudo losetup -f .../efs.img
   sudo fsck -f /dev/loop0
   

   With a bit of luck, the partition won t be a complete write-off and you ll be able to salvage the contents of the files, if not the exact filesystem structure. Incidentally, if the filesystem was completely stuffed, you could get someone else s EFS partition and change the IMEI and MAC addresses and you d probably be golden, but that would quite possibly be illegal or something, so don t do that.
4. Now comes the fun part putting the filesystem back together. After fscking, mount the image somewhere on your computer:

   mount /dev/loop0 /mnt
   

   In my case, I had about a dozen files living in lost+found, and I figured that wasn t a positive outcome. I did try, just in case, writing the fsck d filesystem image back to the phone, in the hope that it just needed to mount the filesystem to boot, but no dice. Instead, I had to find out where these lost soul^Wfiles were supposed to live. Luckily, a colleague of mine also has an S3 (the ever-so-slightly-different GT-I9300T), and he was kind enough to let me take a copy of his EFS partition, and use that as a file location template. Using a combination of file sizes, permissions/ownerships, and inode numbers (I knew the -i option to ls would come in handy someday!), I was able to put all the lost files back where they should be.
5. Unmount all those EFS filesystems, losetup -d /dev/loop0, and put the fixed up EFS partition image back onto your SD card for the return trip to the phone.
6. Now, with a filesystem image that looks reasonable, it s time to write it back onto the phone and see what happens. Copy it onto the SD card, boot up into recovery again, get a shell, and a bit more dd:

   dd if=/external_sd/efs.img of=/dev/block/mmcblk0p3
   

7. With a bit of luck, your phone may just boot back up now. In my case, I d done so many other things to my phone trying to get it back up and running (including flashing custom ROMs and what have you) that I needed to flash Cyanogen, boot it, and wait at the boot screen for about 15 minutes (I shit you not, 15 minutes of Gah is my phone going to work?!? ) before it came up and lo! I had a working phone again. And about 27 SMSes. Sigh, back to work

So, yeah, neener-neener to the collected wisdom of the tubes. I fixed my EFS partition, and in the great, grand scheme of things, it wasn t even all that difficult. For any phone which (a) allows you to flash a custom recovery and (b) you can find another of the same model to play with, EFS corruption doesn t necessarily mean a fight with tech support. Incidentally, if you happen to have an S3 exhibiting this problem, but you re not comfortable fiddling with it, I m happy to put your EFS back together again if you pay shipping both ways. It s about a 5 minute job now I know how to do it. E-mail me.

A few hours ago I posted about share-file, a small tool to make a local file available at a public URL so that it is transferred from my machine, without being stored at some central server. I wanted to create something like FileTea, but usable from the command line. My post made it to HackerNews (which brought my server to its knees for a while; let s say I had the opportunity to find out what setting for apache s MaxClient option works on my machine...), where the comments (besides some misunderstanding about the notable features of share-file) contained interesting links related to solving #949:

• First of all, James Brechin implemented a command line client for FileTea. It is not clear to me whether he created it in response to my posting, or whether it lay around for a while, but I don t care: It does precisely what I need, making share-file obsolete for me. Lazyweb works!
• There is a service very similar to FileTea, but seemingly developed independently, at https://fipelines.org. It seems that this task is best solved using unorthodox programming language choices; while FileTea uses C and glib (not common in web applications), fipes, the software behind fipelines, is implemented in Erlang.
• The new and shiny thing for peer-to-peer communication without additional software is WebRTC, which only needs a modern browser, and there is a chat- and file-transfer program at https://rtccopy.com/. I did not test how well it handles the case where both sides are behind a NAT, though, and sending a ready-to-use link is still simpler for the other side.
• I found another WebRTC-based tool that focuses on sharing files only, and where users who have downloaded a file will, as long as their browser tab is open, help uploading it a bit like Bittorrent. So if you need to share a file with many people (all of which are using up-to-date non-IE browsers), sharefest is worth a try.
  

If you maintain software in debian, one of your regular maintenance tasks is checking for new upstream versions, reviewing them, and preparing them for debian if appropriate. One of those steps is often to verify the cryptographic signature on the upstream source archive. At the moment, most maintainers do the cryptographic check manually, or maybe even don't bother to do it at all. For the common case of detached OpenPGP signatures, though, uscan can now do it for you automatically (as of devscripts version 2.13.3). You just need to tell uscan what keys you expect upstream to be signing with, and how to find the detached signature. So, for example, Damien Miller recently announced his new key that he will be using to sign OpenSSH releases (his new key has OpenPGP fingerprint 59C2 118E D206 D927 E667 EBE3 D3E5 F56B 6D92 0D30 -- you can verify it has been cross-signed by his older key, and his older key has been revoked with the indication that it was superceded by this one). Having done a reasonable verification of Damien's key, if i was the openssh package maintainer, i'd do the following:

cd ~/src/openssh/
gpg --export '59C2 118E D206 D927 E667  EBE3 D3E5 F56B 6D92 0D30' >> debian/upstream-signing-key.pgp

And then upon noticing that the signature files are named with a simple .asc suffix on the upstream distribution site, we can use the following pgpsigurlmangle option in debian/watch:

version=3
opts=pgpsigurlmangle=s/$/.asc/ ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-(.*)\.tar\.gz 

I've filed this specific example as debian bug #732441. If you notice a package with upstream signatures that aren't currently being checked by uscan (or if you are upstream, you sign your packages, and you want your debian maintainer to verify them), you can file similar bugs. Or, if you maintain a package for debian, you can just fix up your package so that this check is there on the next upload. If you maintain a package whose upstream doesn't sign their releases, ask them why not -- wouldn't upstream prefer that their downstream users can verify that each release wasn't tampered with? Of course, none of these checks take the the place of the real work of a debian package maintainer: reviewing the code and the changelogs, thinking about what changes have happened, and how they fit into the broader distribution. But it helps to automate one of the basic safeguards we should all be using. Let's eliminate the possibility that the file was tampered with at the upstream distribution mirror or while in transit over the network. That way, the maintainer's time and energy can be spent where they're more needed.Tags: crypto, devscripts, openpgp, package maintenance, signatures, uscan

Sometimes it makes sense to ship a program to linux users in ready-to-run form that will work no matter what distribution they are using. This is hard. Often a commerical linux game will bundle up a few of the more problimatic libraries, and ship a dynamic executable that still depends on other system libaries. These days they're building and shipping entire Debian derivatives instead, to avoid needing to deal with that. There have been a few efforts to provide so-called one click install package systems that AFAIK, have not been widely used. I don't know if they generally solved the problem. More modern appoaches seem to be things like docker, which move the application bundle into a containerized environment. I have not looked at these, but so far it does not seem to have spread widely enough to be a practical choice if you're wanting to provide something that will work for a majority of linux users. So, I'm surprised that I seem to have managed to solve this problem using nothing more than some ugly shell scripts. My standalone tarballs of git-annex now seem fairly good at running on a very wide variety of systems. For example, I unpacked the tarball into the Debian-Installer initramfs and git-annex could run there. I can delete all of /usr and it keeps working! All it needs is a basic sh, which even busybox provides. Looks likely that the new armel standalone tarball of git-annex will soon be working on embedded systems as odd as the Synology NAS, and it's already been verified to work on Raspbian. (I'm curious if it would work on Android, but that might be a stretch.) Currently these tarballs are built for a specific architecture, but there's no particular reason a single one couldn't combine binaries built for each supported architecture. technical details The main trick is to ship a copy of ld-linux.so, as well as all the glibc libraries and associated files, and of course every other library and file the application needs. Shipping ld-linux.so lets a shell script wrapper be made around each binary, that runs ld-linux.so and passes it the library directories to search. This way the binary can be run, bypassing the system's own dynamic linker (which might not like it) and using the included glibc. For example a shell script that runs the git binary from the bundle:

exec "$GIT_ANNEX_LINKER" --library-path "$GIT_ANNEX_LD_LIBRARY_PATH" "$GIT_ANNEX_SHIMMED/git/git" "$@"

I have to set quite a lot of environment variables, to avoid using any files from the system and instead use ones from my tarball. One important one is GCONV_PATH. Note that LD_LIBRARY_PATH does not have to be set, and this is nice because it allows running a few programs from the host system, such as its web browser. worse is better Of course I'll take a proper distribution package anytime over this. Still, it seems to work quite well, in all the horrible cases that require it.

There are numerous benefits to shopping online you can order stuff and pay for it from the comfort of your own home and it ll arrive on your doorstep in just a few days. wonderful, and so many words have been written about the benefits over the years that there s no need to belabour the point, But there are some things about it that really suck and make me NOT want to order stuff online most of the time my distaste for the privacy and delivery problems is enough to dissauade me from buying anything, helped by the fact that I live a fairly non-consumerist lifestyle (and for a geek, I have an almost non-existent gadget-fetish) but occasionally I want or need something that isn t available locally or which my ill-health makes impractical to buy in person (i ve been effectively housebound or in hospital for most of the year) so here are the things that piss me off most about shopping online.

1. Loss of anonymity and privacy. You can walk into any shop and pay cash for whatever you want, they don t need to know who you are or where you live, and they don t get to accidentally add you to a mailing list against your express wishes oh, we didn t realise that when you said DO NOT SPAM ME, you actually meant DO NOT SPAM ME we ll just keep spamming you for another six months until we get around to processing your removal request . partial solution: use a different email address with each online shop. boycott the shop and destroy the address if they spam. what sucks is that this is actually necessary. it doesn t matter how loudly I say DO NOT SPAM ME. DO NOT ADD ME TO ANY MAILING LISTS. DO NOT ASK ME TO COMPLETE A SURVEY. DO NOT CONTACT ME FOR ANY REASON NOT DIRECTLY RELATED TO DELIVERING MY ORDER. MY PERSONAL INFORMATION IS PROVIDED SOLELY SO THAT YOU CAN SHIP MY ORDER TO ME AND MAY NOT BE USED FOR ANY OTHER PURPOSE. FAILURE TO RESPECT MY PRIVACY WILL RESULT IN IMMEDIATE AND PERMANENT BOYCOTT (yes, that IS the text I use in the comments/instructions field of every order I place), marketing vermin will decide that I really want their spam after all because their spam is super interesting and important and isn t really spam at all.
2. nosy demands for unneccessary information. OK, they need your addresss to ship your parcel but they don t need your phone number, and they don t need to tie your order to your facebook or other bullshit social-spam account. most online order forms have phone number as a required field. Fortunately, they usually accept 0000000 or some other bogus non-phone number as a valid number .if not, i give them their own phone number.
3. the thing that really shits me the most about online shopping is that both couriers and australia post suck. the lazy fuckers usually don t even bother attempting to deliver to residential addressess. at best, they just stick a non-delivery card in your letterbox without even attempting to knock on the door ..and sometimes they don t even bother doing that. the delivery driver just files a bogus failed to deliver or recipient refused delivery with their office.

i ve made four online purchases in the last month and a half. only one of them was delivered correctly to my door, even though I was sitting at my desk in the front room of the house, a few feet from my front door, and regularly monitoring the parcel s tracking web page so I knew it was arriving. parcel 1 (Nov 16): DHL from NZ to AU. delivered perfectly. delivered in about two days for $17. order value: around $35. parcel 2 (Nov 20): Aust Post from WA to Vic, Express Post (costs a few bucks more than standard post). order value: around $80. lazy driver didn t bother to attempt delivery. left card in letter box. i had to pick it up 2 days later from a post office the next suburb over (it wasn t there yet on the first attempt to pick up, the next day). Aust Post offered to maybe put me in touch with their re-delivery people who might possibly be able to re-deliver the parcel next week sometime maybe, if they felt like it. knowing that I had another hospital appt the next week, I declined (if i hadn t, it would have been an absolute certainty that they would try to deliver it while i was out). parcel 3 (nov 29): DHL from NZ to AU. order value: around $85. lazy courier didn t even bother to leave a card, just logged it as Recipient refused delivery . This refused delivery lie infuriated me when i saw it on the tracking page so i phoned and yelled at them a lot. DHL delivered it later the same day. if they hadn t I would have had to get myself over to the other side of town during business hours and pick it up from their South Melbourne depot. parcel 4 (today, Dec 16): Aust Post from NSW to Vic, Express Post . order value: around $160. lazy driver didn t even bother to leave a card, just logged it as Attempted delivery being carded to Australia Post outlet . Complete bullshit. There was no delivery attempt, not even a card in the letterbox, let alone a knock on the door with my parcel. Rang Aust Post on 8847 9045 (a phone number curiously absent from their tracking page, but which I had written down after their failure to deliver on Nov 20) and complained. they claim that they will try to deliver it today. i ll believe it when I see it. UPDATE @4.30pm: no, it s not going to be delivered today. they say they might choose to deliver it tomorrow or sometime in the future, if the delivery center manager feels like it. i told them that this is not an option my parcel WILL be delivered, it is what they were paid to do so it is what they ARE going to do. btw, the tracking page says that they attempted delivery at 12.15 today (they didn t not even a card in the letterbox), but the tracking page wasn t updated with that until about 2.30pm. by a complete non-coincidence their delivery center allegedly closes at 2pm, so it s impossible to complain about non-delivery in time for the complaint to do any good. Score so far: DHL 50% delivery rate. Aust Post: 100% failure rate. Annoyance Rate: extremely high. Desire to repeat the experience: non-existent. The Australia Post delivery problems are particularly annoying. I ve always thought of the network of local post offices to be a huge advantage for parcel delivery if i m not home, my parcel will go to a local post office and I can pick it up from there. And this is a great advantage. I used to take advantage of it when I was well enough to work. In fact, I d insist on delivery by Aust. Post rather than by a courier for exactly this reason, a local post office is far more convenient than some courier s depot on the other side of town or out in some far outer-suburban hellhole. But when it s used as an excuse to not even bother attempting delivery, it sucks. I m not well, and I should have been lying in bed reading or sleeping today, not wasting what little energy I have waiting for a parcel that never arrived and I certainly shouldn t have to phone Aust Post or DHL to yell at them for failing to do the job that they have been paid to do. shopping online whinge of the day is a post from: Errata

In the past few days I have been messing around with Linux namespaces, and developed a little tool (pflask) that automates the creation of simple Linux containers based on them (a sort of chroot(8) on steroids if you will). While the whole raison d' tre behind this project was "just because", and many more mature solutions exist, I decided that it'd be nice to find an actual use case for this (otherwise I tend to lose interest pretty quickly) so I wrote a lil (and rather dumb) pbuilder clone that uses pflask instead of chroot. The nice thing about pflask is that, differently from e.g. LXC, it doesn't need any pre-configuration and can be used directly on a vanilla debootstrap(8)ed Debian system:

$ sudo mkdir -p /var/cache/pflask
$ sudo debootstrap --variant=buildd $DIST /var/cache/pflask/base-$DIST-$ARCH

Where $DIST and $ARCH are e.g. unstable and amd64. Once that's done just run pflask-debuild on the package sources:

$ apt-get source somepackage
$ cd somepackage-XYX
$ pflask-debuild

The script will take care of creating a new container, chroot(2)ing into it, installing all the required dependencies, building and signing the package (it also runs lintian!). The main difference from pbuilder is that pflask will mount a copy-on-write filesystem (using AuFS) on the / of the container so that any modification (e.g. installation of packages) can be easily discarded once the container terminates (similarly to what cowbuilder(8) does, modulo the hardlinks hack). Additionally, thanks to the mount namespace created inside the container, all of this will be isolated from the host system and other containers, so that multiple packages can be built simultaneously on the same base debootstrapped directory. Another possibility would be that of disabling the network inside the container using a network namespace, in order to prevent the package build system from downloading stuff from Internet while at the same time maintaining the network active on the host system, but I haven't done any experiment in this direction yet. Note though that all of this is rather crude and experimental, but as a little hack it seems to work rather well (YMMV).

In June 2008 I received a Dell PowerEdge T105 server to run in my home for a client [1]. That system has run well for over 5 years for the purposes of my client and also as my own home fileserver and as a workstation. But now it s getting a bit old, while it was still basically working the cooling fans were getting noisy, faster systems are available, and it was crashing occasionally which could have been due to hardware or software. On the 7th of November I got a new Dell PowerEdge T110. It s got a i3-3220 CPU (speed of 4218 according to cpubenchmark.net) which is a lot better than the AMD 1212 (speed of 982). It takes up to 4*3.5 SATA disks (as opposed to 2 disks) and has more options for memory expansion. Next time I run out of disk space I ll add another RAID-1 pair of disks instead of buying new disks. Generally this system is much the same as the one it replaces. It s a cheap server which unfortunately lacks sound hardware and usable video hardware. Sound is a problem I already solved with USB speakers but for the new system I bought a PCIe video card. Fortunately the system has PCIe*16 sockets (which apparently only have PCIe*8 wires) which avoids the problem I had in the past trying to obtain a suitable video card. The crashes turned out to be due to BTRFS and now that I ve made some tweaks everything is running well. I ll probably buy another Dell PowerEdge in about 5 years time.

• [1] http://etbe.coker.com.au/2008/06/26/dell-poweredge-t105/

So SteamOS has been released. While that's marginally interesting in and as of itself, there are two observations to be made:

1. Microsoft, Nintendo, and Sony will feel an impact. More functionality on cheaper hardware which can easily by upgraded; I bet quite a few managers are not happy, at the moment.
2. While the stand-alone Linux Steam client was initially targeted at Ubuntu, SteamOS is based on Debian Wheezy.

Actual Linux (not Android) for the end user The first one means more Linux installations. In the living room. On a machine that children are really focussed on and will want to play with, quite literally. The next logical step is for people who play games to install SteamOS on their other machines; desktops, laptops, everywhere they want to game. This could really be the tipping point where the average adolescent computer enthusiast does not need to reboot into Linux to fool around with, but the other way round: To need to boot to Windows for a few select legacy applications which don't run on the FLOSS variant of Wine like Office or Photoshop. And once this momentum starts to shift, other software vendors will follow the money trail. Could 2014 finally be.... the year of Linux on the desktop...? Debian vs Debian-based The latter one is also really interesting... Obviously, I don't know why Valve decided to go down this road, but there are several reasons which come to mind:

• No need for the extra bloat
• They wanted to avoid the tie-in with another for-profit entity
• Unhappiness with some technical decisions made by UbuntuCanonical
• Lack of faith in the long-term governance of Ubuntu

What we are left with is a major player entering the ring of Linux for end-users and choosing Debian over Ubuntu. Hopefully, improvements to the base system will be fed back upstream, enabling all Debian-based distributions to profit easily, not only Ubuntu-based ones. I am willing to bet that two years ago, SteamOS would have been based on Ubuntu, not Debian. Recently, there's been a lot of backlash over various decisions which Canonical forced onto Ubuntu and it will be interesting to see how this plays out in the long run... I will be interesting to see how much pain Linux Mint and Kubuntu will endure. Forecast Users All in all, we are looking at a massive influx of new users into the Debian ecosystem. How massive? 65 million registered users massive. 7 million concurrent users at once, 1.2 million users actively playing the top 100 games at the same time massive. This is huge. Contributors In time, a substantial part of that userbase will switch over one or more of their machines over to SteamOS. The tinkerers among them will realize they can install plain Debian and install Steam as a package. The hackers among those will start to improve upon their systems; and what better way to do that then to go upstream? If even a tiny fraction of users makes it this far, the count of actively involved contributors with Debian will skyrocket if we let them join. Raspbian and some other not-quite-ideal decisions come to mind. Vendors Commercial software vendors need to stay profitable. Thus, they are forced to support distributions which promise enough paying users. In the past, this meant mainly SuSE and Red Hat; they had commercial backers, went through certifications, etc. In the recent past, this also meant Ubuntu. All of a sudden, Debian stable has a potential market of tens of millions of average computer users and computer enthusiasts. A lot of whom will want to continue to use their OS of choice at work, as well. Oh boy...

This morning when preparing the update of a package, and I saw a PNG file in its documentation. Even before opening it, I felt old, tired, distressed and unable to escape the situation. Inspecting the file confirmed that the image was not hand made. The source file is missing. The proof: anther image in the same directory has the same style and a SVG source. To make things worse, there are no instructions on how to generate the PNG from the SVG. More and more in these cases, I give up and abandon the package. I lost time and energy make Upstream some requirements for which I personally have no concrete interest. SVG in addition to PNG is better, but PNG alone for the documentation of a Free software is Free enough for me. However, the points of view expressed on debian-devel give me the impression that it is not good enough for Debian, so I just give up