Search Results: "cas"

26 October 2013

Russ Allbery: Review: Why We Fail

Review: Why We Fail, by Victor Lombardi
Publisher: Rosenfeld Media
Copyright: 2013
ISBN: 1-933820-17-9
Format: Kindle
Pages: 248
Subtitled Learning from Experience Design Failures, Why We Fail is a case study book. It defines experience design, discusses the usefulness of analyzing failure, and then walks through ten marketplace failures attributed to failures of user experience (as opposed to engineering or user interface) and tries to draw some conclusions about those failures and how they could have been prevented. Lombardi then presents a more general (if fairly simple) framework for iterative experience design, along with some discussion of how that approach could have helped in these cases. Hardware and software designs can work properly but still fail with users and customers because the overall experience isn't right. Sometimes this is because something else got there first with more market share and people got used to it, sometimes it's because a system is too complicated, sometimes it's too simple, sometimes it's just uninspiring. Most of the news media coverage and many of the blog posts on this topic look to inspirational examples of successes. Lombardi points out here that successes can be accidental and failures are often more informative, a concept already common in many more mature areas of engineering. His hope, with Why We Fail, is to push a broader industry practice of taking apart and analyzing the failures. User experience design is still in its infancy, since many of the complex interactions now possible in modern hardware and software have just recently crossed into levels of complexity that qualify as experiences rather than interactions, and could benefit from more rigor. The concept sounds great. The approach in Why We Fail is at least interesting; Lombardi tells good stories, and I think they do tell some useful lessons. Drawing general principles is harder, which is always the weakness of case-study books. Lombardi's own attempt doesn't go far beyond a familiar mantra of the scientific method, small and responsive teams, cross-functional teams with flexibility to address a whole range of technical and business issues, and honest and forthright analysis of and iteration after failure. All of this is doubtless good advice; none of it should surprise anyone with even a smattering of engineering background or familiarity with current software design philosophy. The heart of the book is in the stories, and I did like that Lombardi captured a wide range of different designs. Included are embedded systems (BMW's iDrive), traditional software packages, web services of various types, and even a protocol (OAuth). Some were vaguely familiar and some were not familiar at all, although I don't follow UI and UX discussions to any large extent. In each case, Lombardi gives a short but effective introduction to the problem space and the product, walks through the design choices, and then talks about the failure. Usefully, he doesn't stop with the failure but continues the story through the reaction of the company to the failure and any subsequent actions they took, which in some cases contain their own useful lessons. All of this, I should note, is a bit far afield of my own area of expertise (architectural building blocks and sub-surface components without as much direct interaction with the user), so I'm not the best person to judge the quality and originality of the analysis. But I liked Lombardi's approach and his analysis of multiple possible failure causes, and all of his conclusions seemed quite plausible and sensible given the case studies as described. I'm best-qualified to judge the chapter on OAuth, since I've worked extensively on web authentication systems, and his analysis of the challenges and user experiences in that case closely match my own. I didn't notice any significant errors, which is hopefully a good sign for the rest of the book. As one might expect from a short book about a complex field aimed mostly at starting a conversation, there isn't much here that's earth-shattering, nor are there simple extractable principles that will make your experience designs better. As always, the takeaway boils down to "invest time and resources into this and try to think about it systematically," which of course is true of every possible axis of improvement for any product. (The challenge is usually where to spend those limited resources.) I will also note in passing that Lombardi assumes an entirely market-driven metric for success, and all of the case studies are exclusively commercial not unexpected, since that's where most of the money and a lot of the resources are, but not that helpful for bespoke work where the nature of the problem is subtlely different. But, despite the expected shortcomings and the inherent weakness of the case study approach to analysis, which tries to pluralize anecdote to get data I enjoyed this book. I also got at least one useful trick out of it: the premortem, to look for potential failure points in the experience before rolling out, or even designing, the product. It's a fairly light-weight book, but I think it's moderately inspirational, and I wholeheartedly concur with Lombardi on the merits of failure analysis as an engineering approach. Rating: 7 out of 10

24 October 2013

Daniel Pocock: Final report on GSoC 2013 projects

Google Summer of Code finished recently. This is the first year that I have participated as a mentor for the Debian Project. Its a big responsibility to be part of the Debian team and to be one of the Debian team members representing Debian at the GSoC Mentor Summit. Birthdays all round This has been a particularly important year for the Debian Project, as the project celebrated our 20th birthday recently, on 16 August 2013, one of the final days of DebConf13 in Switzerland. GSoC celebrates its 10th year in 2014, with a generous 10% boost in the student stipend to mark the occasion. Google: don't be evil Google's "Don't be evil" approach to business has always been an interesting point for discussion. In my view, there are few cases of absolute good or absolute evil that we can universally classify and agree on. At a more pragmatic level, various people have commented that GSoC is a recruiting program for Google: some have even cited this as a reason not to participate. This is a more interesting point for discussion. The results of the program are not exclusive to the headhunters at Google. Anybody can browse through the Debian GSoC weekly student reports from each student to find out exactly what the students were up to and try to recruit them. Mentors and the projects they belong to have not been forced to sign any wide-ranging non-disclosure agreements or non-compete agreements with Google. In one recent example, the xWiki open source project even went as far as setting up a new office in Romania and employing some former GSoC students on a permanent basis.
Assorted images from Iasi, Romania, where xWiki set up an office employing former GSoC students How does Google benefit then? Well, there appear to be several possibilities:
  • Generating a huge amount of goodwill and recognition for the value that they place on the development of the next generation of software engineers
  • Stimulating the expansion of high quality free software projects, many of which they use directly or indirectly for their internal projects
  • Access to private evaluations prepared by the mentors. These evaluations don't take more than an hour for the mentors to complete but they do serve to give Google's headhunters a slight headstart over anybody else who is scouring the web for the names of graduates who completed GSoC
Overall, it appears to fit the definition of a "win-win" scenario: yes, Google gets stuff out of it, but the benefit is not exclusive to Google and projects like Debian are winners too. My initial approach I started by reviewing some of these materials: One particular concept that I took note of was the need to give students some opportunity to be innovative and original in their project proposals. In other words, it has been suggested that students should not be given a precise specification: rather, they should be given some very general concepts or goals and asked to suggest some funky, innovative new idea. The wisdom of this approach varies. If your free software project has some very specific gap that you need to fill, you may only be interested in taking a student who can fill that gap and you may not want to waste the time of other applicants. On the other hand, if you do precisely document this gap you want filled, you may get a bunch of very similar proposals from students and it may be more difficult to distinguish which of them is the most desirable candidate. Furthermore, if your expectations are too rigid, you may not benefit from a top-gun coming in and contributing some really exciting piece of work that you hadn't even thought of. In the end, I opted for providing more generic project briefs and looking at how students responded. The briefs that I published are available here. Coding tasks during the selection process There is no doubt about it, coding tasks are an important part of ensuring students are capable of development work before they are selected. They are also very important for us as mentors. It is not uncommon for some of us to be completely out of touch with the capabilities of other developers. The coding tasks completed by the students during the selection phase allow us to get a feel for their capabilities and set reasonable expectations for how much they can achieve during the course of the project. To simplify the management of coding tasks and engage the students in the Debian community at large, I decided to create tasks as wishlist items in the Debian bug tracking system, such as this dynalogin bug report. The prospective GSoC students were asked to put their name in the bug tracker to take ownership of the task they would complete. Student project proposals For the real-time communications project, I felt all the students slightly underestimated the complexity of this field and would have to be extremely lucky to complete everything they hoped to. After all, this is a field that the free software movement has been wrestling with for years without gaining the upper hand. For somebody with good knowledge of the projects in this space, it is possible to guide the students towards meaningful and achievable subprojects. Nonetheless, the proposals were useful for me in understanding which part of the topics were most attractive to the students. For the other project areas, the student proposals were slightly more specific. Fabian's appeared to be the most specific and well considered proposal for the one-time-password project, in fact, it appeared very much like a project that he could work through from start to finish. Debian teamwork Anybody looking at the GSoC web site will notice that there is a certain amount of overhead in joining the program, promotion, payment administration and optional participation in the GSoC Mentor Summit. As a large organisation, Debian established a dedicated SoC administration team who looked after the GSoC and Outreach Program for Women administrivia. As a developer and mentor, I found this arrangement was highly effective and allowed me to focus over 99% of my efforts on the front-line work, selecting students and supporting them through their projects. Project results One of the more controversial issues during the Debian 7 (wheezy) release cycle was the inclusion of the Mumble voice conferencing software. Although the software has some serious issues, it was eventually escalated to the technical committee and allowed to remain in Debian, partly due to lack of any alternative. One of the first results from Catalin's project was the creation of an alternative, the new reConServer project, based on the librecon conversation manager API from the reSIProcate SIP stack. reConServer is a significantly more generic solution than Mumble, as it allows any SIP peer to participate in an audio conference. It supports TURN for NAT traversal too. Catalin then went on to make the first working implementation of a scheme for passing context information from a web site to SIP WebRTC call as described in the IETF draft. All work has been integrated into release tarballs and packaging. Fabian worked through the latest standards for one-time passwords, extending the oath-toolkit and dynalogin projects to implement mutual two-factor authentication with just about any arbitrary crypto suite using one-time passwords. This work is yet to be merged into an official release of dynalogin as it requires co-ordination with the oath-toolkit release and package updates. However, there is a compelling demonstration in his video from DebConf13 and the source is available under Fabian's github account. In the post-Snowden world, the work from both of these student projects will be hugely valuable to people wanting to tighten up their computer security and communication security practices. The development process Deciding to mentor more than one project turned out to be a worthwhile decision. At first, this might seem like a big risk but it is manageable with support from co-mentors. The upside is that different students work at different speeds, they have different code styles, they even work at different times of the day or week and mentoring more than one student/project allows the mentor to gain a better appreciation of how the students differ than if mentoring only a single project. For Catalin's project, it became obvious at an early stage that he would benefit from having a dedicated server to run the VoIP applications on public IP addresses and low-latency networks while testing them. I spun up a virtual machine with IPv4 and IPv6 in my Xen Cloud Platform and this was extremely helpful for both of us. Throughout the project, I took a hands-off approach and often left the students to their own devices. I gave some suggestions to Catalin about the object-oriented design and this was enough for him to fill in the gaps and write all the code by himself. Fabian's project had fewer ambiguities and he was able to use existing code as a model more frequently than Catalin. It is possible that the students may have produced more code if I had thought through the designs myself and given them definite blue-prints. However, I feel that this would have made it harder for me to appreciate their own abilities and test the limits of their design skills. DebConf13 participation One of the highlights for the students was their participation in DebConf13. Both students presented a session at the conference showcasing some of their work. The DebConf video team produces high quality videos of all sessions at the conference and this in turn provides some great evidence of the students' capabilities and what GSoC adds to Debian and the wider free software universe. I would encourage other mentors to actively contemplate ways to involve their students in conferences during or shortly after the completion of their project work. Looking ahead Google has recently confirmed that Google Summer of Code will be repeated in 2014. It is the 10th anniversary of the program and to celebrate, students will get 10% extra pay. Thank you There are many people to thank for the success of these projects and the wider success of the Debian GSoC team:
  • The Debian GSoC and OPW organisation admin team
  • Google and the Google Open Source Programs Office
  • All the co-mentors who assisted on these projects with me: Simon Josefsson, Luke Faraone, Sylvain Berfini, Eloy Coto and Jes s P rez Rubio
  • The students themselves, C t lin Constantin U urelu and Fabian Gr nbichler
  • All the other very capable and motivated students who applied, submitted code samples but were not selected to participate: many of these students could have also completed a successful project and turning them away is one of the most difficult tasks for mentors in a volunteer organisation like Debian

Russ Allbery: Review: Applied Cryptography

Review: Applied Cryptography, by Bruce Schneier
Publisher: John Wiley & Sons
Copyright: 1996
ISBN: 0-471-11709-9
Format: Trade paperback
Pages: 621
This is the next entry in the series of Russ reading books that he bought years ago and never got around to reading. Thankfully, this time, the book has aged somewhat better. This review is for the second edition of Applied Cryptography, published in 1996. Given how important computer security has become, and how central cryptography is to computer security, one might think that the passage of 17 years would make a book effectively obsolete. This turns out not to be the case. Yes, Rijndael (the current AES standard and the most widely-used block cipher), Camellia (the up-and-comer in the block cipher world), and the SHA-2 hash postdate this book and aren't discussed. Yes, there have been some further developments in elliptic-curve public-key cryptography. And yes, much of the political information in this book, as well as the patent situation for public-key cryptosystems, is now mostly of historical interest. But a surprising amount of this book still applies directly. Partly that's because much of Applied Cryptography is focused on general principles, classes of algorithms, and cryptographic protocols, and those do not change quickly. A rather amazing number of techniques and protocols still in widespread use today originated in the 1970s. Block ciphers, stream ciphers, cipher modes, public-key systems, signature systems, hash functions, key exchange, secret splitting, key management, and other, similar topics have not changed substantially. And even in the area of specific algorithms, DES is still in use (unfortunately) and its analysis is valuable for understanding any block cipher. RC4, Triple DES, CAST, RSA, MD4, MD5, and SHA-1 are still part of the cryptography landscape, and Schneier was already warning against using MD5 in 1996. The source code included in this book has, thankfully, been made obsolete by widely-available, high-quality free implementations of all common ciphers, available for any modern operating system. But the math, the explanations, and much of the cryptanalysis is still quite relevant. While it contains a comprehensive introduction to cryptographic concepts, Applied Cryptography is structured more like a reference manual than a tutorial. The first two chapters provide some foundations. Then, a wide variety of protocols, from the common to the completely esoteric, are discussed across the subsequent four chapters. There are four chapters on the basics of ciphers, another chapter on the mathematics, and then the longest part of the book: twelve chapters that provide a tour of all major and several interesting minor protocols that existed in 1996. These are organized into block ciphers, stream ciphers (and pseudo-random number generators), hash functions, and public-key systems. An entire chapter is devoted to the history and analysis of DES, and I think that was my favorite chapter of the book. Not only is it worth understanding how DES works, but it also provides a comprehensive introduction to the complexities of block cipher design, the politics of interactions with the NSA, and a fascinating history of early computer cryptosystems. Finally, Applied Cryptography closes with chapters on real-world systems and on politics. The politics section is mostly a historical curiosity, as is much of the chapter on real-world systems. Schneier discusses some of the PKCS and X.509 protocols here but doesn't use SSL as one of his examples despite its specification predating this book (perhaps the most glaring omission of the book). But he does discuss Kerberos (which is of personal interest to me), and it was useful to see it analyzed in the broader context of this sort of book. Those who read Schneier's blog regularly, or who have read any of his other books, will know that he's concise, incisive, and very readable, even with difficult material. I think he does err on the side of compactness this is not a book that handholds the reader or explains something more than once but there's a lot of ground to cover, so I can't really blame him. Expect to have to read the more difficult parts several times, and (at least on a first read) expect to just skip past some of the most complex sections as probably not worth the effort. But I think Schneier does a great job structuring the book so that one comes away with a high-level impression and overview sufficient to make informed guesses about capabilities and relative difficulty even if one doesn't have the patience to work through the details. I suspect most readers will want to skim at least part of this book. Unless you're willing to do a lot of background reading to understand the math, or a lot of careful study to follow the detailed descriptions and flaws in often-obscure algorithms, the algorithm discussions start to blend together. I found myself skipping a lot of the math and focusing on the basic descriptions and the cryptanalysis, particularly for the obscure ciphers. Many of the algorithms are also highly opaque and of obscure benefit; I doubt I will ever care about blind signatures or oblivious transfer, and I struggled to wrap my mind around the details of bit commitment (although it's apparently important in zero knowledge proofs, which in turn are relevant to authentication). But this is not the sort of book where you have to read every word. It's very well-structured, provides clear resynchronization points for readers who have had enough of a particular topic, and marks the topics that are more obscure or of dubious general usefulness. The most useful parts of this book, in my opinion, are the basic conceptual introductions to each class of cryptographic algorithm or protocol, and those chapters are excellent. I've been working in applied computer security, at the application and deployment level, for years, and this is the first time that I've felt like I really understood the difference between a block cipher and a stream cipher, or the implications of block cipher mode selection. Applied Cryptography is also a fascinating exercise in adjusting one's intuition for where the complexity lies. It's a memorable experience to move from the chapters on block ciphers, full of S-boxes and complex mixing and magic numbers, into the far more straightforward mathematical analysis of stream ciphers. Or the mathematical simplicity of RSA (although quite a bit of complexity is lurking on the cryptanalysis side, much of which is only touched on here). Of more historical interest, but still quite impressive, is that Applied Cryptography doubles as a comprehensive literature review. Not only does it cover nearly every algorithm in use at the time, it discusses the cryptography literature on nearly every topic with brief summaries of results and lines of investigation. The references section is a stunning 66 pages of small print featuring 1,653 references, and those are mentioned and put in context throughout the book. I'm not personally interested in chasing those lines of research further, and of course 17 years means there are many new papers that are as important to read today, but it's obvious that this book would have been an amazing and invaluable map to the research territory when it was first published. There are now newer books on this topic that you should consider if you're purchasing a book today. Cryptography Engineering in particular is in my to-read pile, and I'm interested to see how much of this book it could replace, although I believe it's lighter on the mathematical analysis and details. But I think Applied Cryptography still has a place on the bookshelf of any computer security professional. Schneier is succinct, detailed, straightforward, and comprehensive, at least for 1996, and I know I'll be reaching for this book the next time I forget the details of CFB mode and then get hopelessly confused by the Wikipedia article on the topic. Rating: 8 out of 10

23 October 2013

Russell Coker: Thinkpad T420

I ve owned a Thinkpad T61 since February 2010 [1]. In most ways it s a great system and it still does most things that I require, even though it inspired my post about how modern laptops suck [2]. Problems with my T61 The biggest ongoing problem with my T61 was the heat production, I m not sure how much of it was due to the CPU producing heat and how much was due to the cooling system not removing it fast enough. But any serious computation for even a relatively small amount of time caused it to get close to thermal shutdown. But as I mostly use my laptop for reading email, a SSH client, and coding (for which the big compiles are done on servers) that didn t force me to replace it. The next problem was the battery life, it s expected that laptop batteries degrade over time so it wasn t a surprise that after 3 years my T61 battery only lasted for about 15 minutes. A final problem is the screen which didn t seem to be as bright as it used to be, it s annoying but doesn t compel me to buy a replacement. T61 Failure But in July my T61 stopped working, it appeared to be either the power supply or something internal related to power, it had been running but was suddenly powered down after being left alone so for some reason power wasn t getting from the wall to the laptop. I initially thought that it was the power supply at fault and investigated the price of a new PSU and a new battery as well. The Lenovo online store [3] charges $71.90 for a new PSU and $113 for a regular capacity battery or $156 for an extended capacity battery (50% more power). So based on the assumption that the PSU was faulty that meant a cost of $185 or $228 (maybe more if postage is included) to get the old Thinkpad going again. I could probably get the parts cheaper from somewhere else, but I m hesitant to buy batteries from sources that aren t reliable in case I get one that s been used. Buying at Auction I ended up buying a refurbished Thinkpad T420 (product ID 4236-J73) from Grays Online [4]. It was refurbished and cost me $306.35 including delivery. $306.35 for a new laptop including PSU was a much better deal than buying a new PSU and battery for $185 or more. It turned out that the PSU wasn t broken (a different PSU also didn t work with it) but then my Thinkpad T61 just started working again, presumably it has some intermittent fault related to power and needed to be replaced anyway (I use my laptop for work and can t have it fail randomly). One significant problem when buying a Thinkpad is that the model numbers aren t specific to the hardware specs. According to ThinkWiki the T420 model ranges from a 2.1GHz i3 to a 2.8GHz I7 CPU, from 160G to 500G hard drive, and has either a 1366*768 or a 1600*900 display [5]. Auction sites almost always specify the size of a hard drive and usually the exact CPU speed doesn t matter much for an auction purchase (2.1GHz is fast enough for most things). But the display resolution is a big deal, in this case Grays had multiple Thinkpads on offer with the same description and the same price so bidding on one with high resolution was quite important. Lenovo has a web site for discovering Thinkpad specs, this is the current link for it (it changes periodically) [6]. At that page you can specify the TYPE AKA PRODUCT ID that is printed on the back of a Thinkpad (and usually included in an auction listing) in the search field that s currently described as QUICK PATH and get all the specifications. Lenovo really do a great job of providing all the details for their products (including ones that were obsolete years ago). But it s unfortunate that their web site sucks, there should be a single URL for such things that s easy to find and they shouldn t use cookies to track which model you are looking at because it makes it really difficult to research two different models. Comparing T61 and T420 I upgraded my new Thinkpad to 8G of RAM because RAM is really cheap. I bought it with 4G of RAM which didn t seem to be quite enough as the hard drive is slow for paging (my desktop with 3G of RAM and a SSD performed well for similar tasks). Now it s running really well, my new Thinkpad is a lot cooler than the old one (not being broken is a good thing). My T420 has a screen resolution of 1600*900 which was a little disappointing initially when going from 1680*1050 (18% fewer pixels and 2% fewer than the T41p I used previously). But having a smaller screen means that the Thinkpad is a lot smaller and lighter. My T61 didn t fit in most backpacks and laptop bags and was unreasonably heavy, it s the type of laptop that looks good on a spec sheet but doesn t seem so good when you carry it around for a few hours. Not only is the T420 a lot smaller and lighter than the T61 but the power supply that shipped with it is a lot smaller and lighter too. I might have spent $72 a few years ago to buy a lighter PSU if I knew that was an option. Cost of Ownership Thinkpads are getting so cheap at auction that I m tempted to buy myself an X series as well. When a $300 item can last several years (my T41p was from some time before 2006, my T61 was from 2010, and my latest is from 2013) that brings the cost of ownership down to something like $0.25 per day. If I bought myself a Thinkpad X series (ultra light) as well at auction then I would be looking at maybe $0.50 per day for my laptop use which would give me the option of taking a light laptop to a conference and a bigger laptop for spending a day at a client site.

Russell Coker: LUV Hardware Library after 20 Months

20 months ago I started the LUV Hardware Library [1]. The aim of the project is to provide a repository of free spare parts for computers for the use of club members. People who have parts that are good but which they can t use can donate them and others who need such parts can take them. Some people have criticised my choice of the name Hardware Library because the word is associated with borrowing while with my Hardware Library it is expected that noone will return the item that they take. The Wikipedia page about libraries is worth reading, my interpretation of that is that the essential aspect of a library is that it is a public collection of items that are useful for study and that borrowing is just one thing that can be done. A book library could consist of a service of printing free books on demand (anyone could do this with access to The Gutenberg Project [2] and a printer) or of just making them available to download. Many libraries don t allow books to be borrowed, they just allow them to be studied and copied in the library. Also every general public library has reference items that can t be borrowed, it s typical for a library to have a full encyclopedia which is not available to be borrowed. Also with the Hardware Library people feel obliged to give something if they take something (as happens with a geocache), so there is an issue of returning something. My main aims with the Hardware Library were to save people money on parts and to help the environment by reducing the need to buy new computers when old ones can be upgraded and remain in service. My next aim was to help people learn about hardware by providing free parts, when a mistake has no financial cost people are more willing to experiment and will learn more. I believe that those aims have been achieved. More Successful Than Expected One thing that surprised me is the social aspect that developed. I had expected that most people would just find some parts that they need and not look at it again for some months. I had also anticipated that some people would poll the Hardware Library every month in the hope that a part they needed might appear. I didn t expect that people would look through it every month because they just like looking at old hardware. I also didn t expect groups of people to hang out by the Hardware Library to discuss various issues related to PC hardware and Linux. During the breaks in the main meeting the location of the Hardware Library often becomes a focus for discussions of various issues related to Linux and hardware. I think that this is really advancing the aims of LUV [3] and I think that members of other LUGs should experiment with similar projects. Starting this didn t require any special skill or authority. I just started bringing a briefcase full of parts to meetings and offering them to whoever was interested. Any member of any LUG can do the same. To start something like this you wouldn t even need a collection of parts, you could just bring a box and ask for donations.

21 October 2013

Petter Reinholdtsen: A Raspberry Pi based batman-adv Mesh network node

The last few days I have been experimenting with the batman-adv mesh technology. I want to gain some experience to see if it will fit the Freedombox project, and together with my neighbors try to build a mesh network around the park where I live. Batman-adv is a layer 2 mesh system ("ethernet" in other words), where the mesh network appear as if all the mesh clients are connected to the same switch. My hardware of choice was the Linksys WRT54GL routers I had lying around, but I've been unable to get them working with batman-adv. So instead, I started playing with a Raspberry Pi, and tried to get it working as a mesh node. My idea is to use it to create a mesh node which function as a switch port, where everything connected to the Raspberry Pi ethernet plug is connected (bridged) to the mesh network. This allow me to hook a wifi base station like the Linksys WRT54GL to the mesh by plugging it into a Raspberry Pi, and allow non-mesh clients to hook up to the mesh. This in turn is useful for Android phones using the Serval Project voip client, allowing every one around the playground to phone and message each other for free. The reason is that Android phones do not see ad-hoc wifi networks (they are filtered away from the GUI view), and can not join the mesh without being rooted. But if they are connected using a normal wifi base station, they can talk to every client on the local network. To get this working, I've created a debian package meshfx-node and a script build-rpi-mesh-node to create the Raspberry Pi boot image. I'm using Debian Jessie (and not Raspbian), to get more control over the packages available. Unfortunately a huge binary blob need to be inserted into the boot image to get it booting, but I'll ignore that for now. Also, as Debian lack support for the CPU features available in the Raspberry Pi, the system do not use the hardware floating point unit. I hope the routing performance isn't affected by the lack of hardware FPU support. To create an image, run the following with a sudo enabled user after inserting the target SD card into the build machine:
% wget -O build-rpi-mesh-node \
    https://raw.github.com/petterreinholdtsen/meshfx-node/master/build-rpi-mesh-node
% sudo bash -x ./build-rpi-mesh-node > build.log 2>&1
% dd if=/root/rpi/rpi_basic_jessie_$(date +%Y%m%d).img of=/dev/mmcblk0 bs=1M
%
Booting with the resulting SD card on a Raspberry PI with a USB wifi card inserted should give you a mesh node. At least it does for me with a the wifi card I am using. The default mesh settings are the ones used by the Oslo mesh project at Hackeriet, as I mentioned in an earlier blog post about this mesh testing. The mesh node was not horribly expensive either. I bought everything over the counter in shops nearby. If I had ordered online from the lowest bidder, the price should be significantly lower:
SupplierModelNOK
TeknikkmagasinetRaspberry Pi model B349.90
TeknikkmagasinetRaspberry Pi type B case99.90
LefdalJensen Air:Link 25150295.-
Clas OhlsonKingston 16 GB SD card199.-
Total cost943.80
Now my mesh network at home consist of one laptop in the basement connected to my production network, one Raspberry Pi node on the 1th floor that can be seen by my neighbor across the park, and one play-node I use to develop the image building script. And some times I hook up my work horse laptop to the mesh to test it. I look forward to figuring out what kind of latency the batman-adv setup will give, and how much packet loss we will experience around the park. :)

20 October 2013

Ricardo Mones: Forced to 3.11

No, not to this 3.11, but to Linux kernel 3.11.

I was aware of the #718533 bug, which happens when you have a software RAID with anything higher than 3.2.0 (mine is RAID 1 with 2 disks). At least that has been my case since I tried to upgrade, hence I was delaying upgrades again and again.

Unfortunately today things went worse when I tried to plug my USB 3.0 device on the system:
Oct 20 17:52:51 busgosu kernel: [20799.672127] xhci_hcd 0000:02:00.0: Timeout while waiting for address device command
Oct 20 17:52:51 busgosu kernel: [20799.876136] xhci_hcd 0000:02:00.0: ERROR no room on ep ring
Oct 20 17:52:51 busgosu kernel: [20799.876148] xhci_hcd 0000:02:00.0: ERR: No room for command on command ring
Oct 20 17:52:51 busgosu kernel: [20800.080148] usb 2-2: device not accepting address 2, error -12
Oct 20 17:52:51 busgosu kernel: [20800.080202] xhci_hcd 0000:02:00.0: ERROR no room on ep ring
Oct 20 17:52:51 busgosu kernel: [20800.080209] xhci_hcd 0000:02:00.0: ERR: No room for command on command ring
Oct 20 17:52:51 busgosu kernel: [20800.080221] xhci_hcd 0000:02:00.0: ERROR no room on ep ring
Oct 20 17:52:51 busgosu kernel: [20800.080227] xhci_hcd 0000:02:00.0: ERR: No room for command on command ring
Oct 20 17:52:51 busgosu kernel: [20800.080235] hub 2-0:1.0: couldn't allocate port 2 usb_device
Oct 20 17:52:53 busgosu kernel: [20801.568169] xhci_hcd 0000:02:00.0: ERROR no room on ep ring
Oct 20 17:52:53 busgosu kernel: [20801.568181] xhci_hcd 0000:02:00.0: ERR: No room for command on command ring
Oct 20 17:52:53 busgosu kernel: [20801.568190] hub 2-0:1.0: couldn't allocate port 2 usb_device


And of course the device didn't show up. As there's not much relevant stuff about this issue on the googlesphere, thought it may have been solved. And turned out that I was right: upgrading fixes this, and now the device works again.

But, hit by the above bug now I have to add a rootdelay=1 to my kernel boot parameters (started testing with 5 but finally seems one second is enough). Fortunately the Ubuntu folks have detailed how to do it ;-)

15 October 2013

Francois Marier: The Perils of RAID and Full Disk Encryption on Ubuntu 12.04

I've been using disk encryption (via LUKS and cryptsetup) on Debian and Ubuntu for quite some time and it has worked well for me. However, while setting up full disk encryption for a new computer on a RAID1 partition, I discovered that there are a few major problems with RAID on Ubuntu.

My Setup: RAID and LUKS Since I was setting up a new machine on Ubuntu 12.04 LTS (Precise Pangolin), I used the alternate CD (I burned ubuntu-12.04.3-alternate-amd64+mac.iso to a blank DVD) to get access to the full disk encryption options. First, I created a RAID1 array to mirror the data on the two hard disks. Then, I used the partition manager built into the installer to setup an unencrypted boot partition (/dev/md0 mounted as /boot) and an encrypted root partition (/dev/md1 mounted as /) on the RAID1 array. While I had done full disk encryption and mirrored drives before, I had never done them at the same time on Ubuntu or Debian.

The problem: cannot boot an encrypted degraded RAID After setting up the RAID, I decided to test it by booting from each drive with the other one unplugged. The first step was to ensure that the system is configured (via dpkg-reconfigure mdadm) to boot in "degraded mode". When I rebooted with a single disk though, I received a evms_activate is not available error message instead of the usual cryptsetup password prompt. The exact problem I ran into is best described in this comment (see this bug for context). It turns out that booting degraded RAID arrays has been plagued with several problems.

My solution: an extra initramfs boot script to start the RAID array The underlying problem is that the RAID1 array is not started automatically when it's missing a disk and so cryptsetup cannot find the UUID of the drive to decrypt (as configured in /etc/crypttab). My fix, based on a script I was lucky enough to stumble on, lives in /etc/initramfs-tools/scripts/local-top/cryptraid:
#!/bin/sh
PREREQ="mdadm"
prereqs()
 
     echo "$PREREQ"
 
case $1 in
prereqs)
     prereqs
     exit 0
     ;;
esac
cat /proc/mdstat
mdadm --run /dev/md1
cat /proc/mdstat
After creating that file, remember to:
  1. make the script executable (using chmod a+x) and
  2. regenerate the initramfs (using dpkg-reconfigure linux-image-KERNELVERSION).
To make sure that the script is doing the right thing:
  1. press "Shift" while booting to bring up the Grub menu
  2. then press "e" to edit the default boot line
  3. remove the "quiet" and "splash" options from the kernel arguments
  4. press F10 to boot with maximum console output
You should see the RAID array stopped (look for the output of the first cat /proc/mdstat call) and then you should see output from a running degraded RAID array.

Backing up the old initramfs If you want to be extra safe while testing this new initramfs, make sure you only reconfigure one kernel at a time (no update-initramfs -u -k all) and make a copy of the initramfs before you reconfigure the kernel:
cp /boot/initrd.img-KERNELVERSION-generic /boot/initrd.img-KERNELVERSION-generic.original
Then if you run into problems, you can go into the Grub menu, edit the default boot option and make it load the .original initramfs.

Daniel Pocock: Debian Outreach Program for Women 2013

Debian's Outreach Program for Women (OPW) is underway. This is a huge thing and not just something that female developers need to be concerned with. Untapped potential Many computer science schools see about twenty percent of places occupied by female students. In the Debian community, however, about one percent of developers are female. As there are about one thousand male developers, this suggests there are another one hundred potential female developers and contributors out there who are not aware of the fact that they could be part of Debian. Finding these people and helping them fulfil their potential makes the project better for everybody. Women are heavy lifters People should not assume that these women are going to need their hands held. When the Jitsi project recently moved to Github, the Github repository reports made the surprise revelation that Yana is the top contributor - by a fifty percent margin. Will women save the world this week? It is not just in software engineering that women have significant potential. As the men running the US bumble around with their high-stakes game of chicken, it is notable that last week the US Federal Reserve appointed their first female chairman, Janet Yellen. It is unlikely that her first meeting with female IMF boss Christine Lagarde would have satisfied stereotypes about casual gossip or shopping; more likely, they would be contemplating how to save the world economy if rogue congressmen push the US into default - a possibility that is no longer just an outlier. Integrating financial software in Debian With that in mind, one of the projects I've offered to mentor under OPW involves creating further integration between free software for finance and accounting on Debian. Several applicants have already contact me about this. Fundraising to support OPW 2013 Debian is currently raising funds to support this program. The project administrators are hopefully going to provide more details soon about how funding will be allocated and how many projects will proceed.

14 October 2013

Jurij Smakov: Broken envelope-from considered harmful

Recently I went through the process of getting my new key (C99E03CC is dead, long live 43C30A7D!) signed to replace the old one in the Debian keyring. Some people used caff to send out their signatures and in 3 different cases I did not receive the signature for my @debian.org uid, leaving me somewhat dumbfounded as signatures for other uids went through just fine, as did various test emails to my @debian.org address. After pestering people on IRC and discussing the issue with one of the signers, we concluded that Debian's mail servers are configured to reject any mail with invalid envelope-From header - and chances that caff-sent email is going to have an invalid one are pretty high. As far as I can tell, a valid configuration is such that echo $ USER @$(cat /etc/mailname) returns a valid email address. So, if you are a caff user, please make sure that your system is configured correctly before sending out signatures with it, namely that the emails sent using something like echo 'test' mail $ YOU @debian.org are getting through successfully.

Clint Adams: The Windy City is full of meat

As you know, I am not big on reviews, so you should disregard the remainder of this entry. I recently found myself in what is called a theatre complex , watching an adaptation of Moli re's Les Femmes savantes by Freyda Thomas, who is apparently famous for playing Alenis Grem on Deep Space Nine. Called The Learned Ladies, this translation to English manages to approximate some of the rhyme of the original, thereby making it unquestionably better than DS9. Also noteworthy is the all-female cast, cobbled together from two all-female theater groups. Elizabeth Neptune plays Chrysale, occasionally channeling the spirit of Jackie Gleason or bringing adorable ardor to such epic lines as Tea! I won't say anything about her eyes, but I will say something about her slippers. Sara Montgomery, as B lise, is delightfully crazy in her singing, dancing, costume changes, and other antics, which serve to transform this otherwise-completely-serious play into a comedy. I definitely won't say anything about her shoes. Madeleine Maby begins playing Philaminte well before the show starts. Spoiler alert: she sits on the stage, pretending to look through a telescope and make notes from before the house opens until right before the start of the first scene. I still feel exhausted by the thought of having to do that myself. L' pine is portrayed by Alyssa Lott, who also plays three minor roles. Her mastery of physical comedy is not wasted on this production. Marta Kuersten plays Clitandre opposite Sarah Brill's Henriette. While Marta's performance was quite good, she looks much better as a woman. I will not be saying this about everyone. Katie Honaker delivers visceral smarm and sleaze as Trissotin. Even her hairstyle is somehow evocative of contempt. Susan Finch plays Vadius and Le notaire. Susan was definitely most convincing as a man. Despite mutterings to the contrary, some suspension of disbelief was necessary for the other male roles, but not for Vadius, oh no. Finishing out the list we have Janna Emig as Martine, Francesca Day as Armande, and Kathryn Alexander as Ariste, with good performances, particularly in the second half. Even though it didn't have Coppertop from Strangers With Candy and a boy-band song-and-dance cover of To Be with You by Mr. Big, I recommend this play.

Brett Parker: Just in case you missed it...

So, I've changed jobs, I now work for the incredibly awesome Mythic Beasts, So far it's been great, we've hit a few problems, we've made sane plans, and we're moving forwards and making things easier to manage long term. I've mostly been involved with debugging mac-mini boot problems, and getting them working with (as far as possible) stock kernels, rather than our previous set of custom compiled kernels, so that it's easier to upgrade later, and so that we're not having to maintain a whole set of patches that we shouldn't need to! We're also starting to package our own software that we use internally so that actually deploying new servers is becoming a lot easier, and configuration of our previous packages is now (mostly) handled by debconf, meaning that actually setting up backups is becoming much easier. We've also changed out main backup strategy from using a (slightly flaky) openvpn connection with loopback mounted ext3 filesystems to using rsync with the --fake-super option - the only thing that we've found slightly wrong with this so far is that --fake-super can't reconcile symlinks (it uses user level xattr to store the origional permissions, and with symlinks this doesn't work, because, apparently, symlinks should store user xattr attrbutes!). We also offer ipv6 for all our dedicated and vps customers, as per the mythic blog - and our 2 authoritative name servers are both v6 enabled. We're working towards making all of our core services available over both ipv4 and ipv6, and we should be there soon. It's fantastic to work for a company that has the technical knowledge and no-shit stance that Mythic Beasts has, we will hold our hands up if we do something wrong, and we'll tell you exactly what happened, why, and what we're doing to stop it from happening again. So, 1 month in, and I'm absolutely loving working for them, and I've been a customer of theirs since black cat networks sold their domain name side to them, and shortly afterwards bluelinux sold their virtual servers service to them. Our new VDS lite service is reasonably priced, and well spec'd. I thoroughly recommend our services, and obviously, we actually use our own vds service to provide some of our services - so it's as important to us that it keeps working as it is for our customers. Wow, so that was a very salesy post. Erm, next time, back to whinging about authors not having written the books I'm waiting for yet! :)

12 October 2013

Michael Vogt: apt 0.9.12

The recently released apt 0.9.12 contains a bunch of good stuff, bugfixes and cleanups. But there are two new feature I particularly like. The first is the new parameter with-new-pkgs for the upgrade
command:
# apt-get upgrade --with-new-pkgs
that will install new dependencies on the upgrade but never remove
packages. A typical use-case is a stable system that gets a kernel
with a new kernel ABI package. The second is show-progress for
install/remove/upgrade/dist-upgrade which will show inline progress
when dpkg is running to indicate the global progress.
# apt-get install --show-progress tea
...
Selecting previously unselected package tea-data.
(Reading database ... 380116 files and directories currently installed.)
Unpacking tea-data (from .../tea-data_33.1.0-1_all.deb) ...
Progress: [ 10%]
Progress: [ 20%]
Progress: [ 30%]
Selecting previously unselected package tea.
Unpacking tea (from .../tea_33.1.0-1_amd64.deb) ...
Progress: [ 40%]
Progress: [ 50%]
Progress: [ 60%]
Processing triggers for doc-base ...
Processing 2 added doc-base files...
Registering documents with scrollkeeper...
...
Processing triggers for man-db ...
Setting up tea-data (33.1.0-1) ...
Progress: [ 70%]
Progress: [ 80%]
Setting up tea (33.1.0-1) ...
Progress: [ 90%]
Progress: [100%]
For the install progress, there is also a new experimental option
Dpkg::Progress-Fancy . It will display a persistent progress status bar in the last terminal line. This works like this:
# apt-get -o Dpkg::Progress-Fancy=true install tea
apt-install-fancy-progress This kind of information is obviously most useful on complex operations like big installs or (release) upgrades.

11 October 2013

Russ Allbery: krb5-strength 2.1

This is a quick bug-fix release, since of course there was a significant bug in the recent 2.0 release. In this case, it was a problem with the build: if you configured the package without CDB support, it didn't build. Apparently I didn't retest that after doing some refactoring. I have good test suite techniques for reasonable code coverage, but not for testing various variant configurations at the Autoconf level. This is what a continuous build infrastructure would be good for, I know. We even have one sitting around; someday, I should invest in hooking my projects up to it. Anyway, also in this release is the start of an Autoconf fix so that --with-tinycdb without an argument works correctly, but I have more Autoconf work to do (also affecting rra-c-util). I also tweaked the error messages returned by the non-CrackLib portions of krb5-strength so that they would hopefully be more comprehensible to users while still being technically accurate. You can get the latest release from the krb5-strength distribution page.

9 October 2013

John Goerzen: Two Kittens

Almost every time he got off the bus for the past month and a half, Jacob started his afternoon in the same way. Before toys, before his trains and his toy bus, before anything indoors, he went for our cats. Here he is, cradling his favorite, Tigger: Laura and I both grew up around cats. We had been talking about kittens, and shortly after we got engaged, one of my relatives offered us some free kittens. We went to his place one evening and selected two of them one calico and one tiger-colored. Since what is now my place will soon be our place, they came to live with me. Our cats were one of the first things we did to prepare for our lives together. Oliver wanted to name them some rather impractical sentence-long names ( The Cat Who Always Likes To Run ), so Laura and I suggested some names from one of their favorite books: Tigger and Roo. They both liked the names, but Oliver thought they should be called Tigger the Digger and Roo the Runner . Never mind that they were just 6 weeks old at the time, and not really old enough to either dig or run. Here s Oliver with Roo, the day after the kittens arrived here. I have always had outside cats, both because I m allergic to cats so I need them to be outside, and because they sometimes literally quiver with joy of being outdoors. Tigger and Roo often chased insects, wrestled with each other, ran up (and slowly came back down) trees, and just loved the outside. Sometimes, I have taken my laptop and wireless headset and work from the back porch. The kittens climb up my jeans, inspect the laptop, and once Roo even fell asleep on my lap at one of those times. Jacob has been particularly attached to Tigger, calling him my very best friend. When Jacob picks him up after school, Tigger often purrs while cradled in Jacob s arms, and Jacob comments that Tigger loves me. Oh dad, he knows I am his friend! The kittens have been growing, and becoming more and more comfortable with their home in the country. Whenever I go outside, it isn t long before there are two energetic kittens near my feet, running back and forth, sometimes being very difficult to avoid stepping on. I call and I see little heads looking at me, from up in a tree, or peeking out from the grain elevator door, or from under the grill. They stare for just a second, and then start running, sometimes comically crashing into something in their haste. Yesterday when I went to give them food, I called and no cats came. I was concerned, and walked around the yard, but at some point either they come or they don t. Yesterday afternoon, just after the bus dropped off Jacob, I discovered Tigger on the ground, motionless. Once Jacob was in the house, I went to investigate, and found Tigger was dead. As I was moving his body, I saw Roo was dead, too. Both apparently from some sort of sudden physical injury a bit mysterious, because neither of them were at a place where they had ever gone before. While all this was happening, I had to also think about how I was going to tell the boys about this. I tried to minimize what he could see, Jacob had caught an unavoidable glimpse of Tigger as we were walking back from the bus, but didn t know exactly what had happened. He waited in the house, and when I came back, asked me if Tigger was dead. I said he was. Jacob started crying, saying, Oh Dad, I am so sad , and reached up for a hug. I picked him up and held him, then sat down on the couch and let him curl up on my lap. I could quite honestly let him know he wasn t alone, telling him I am sad, too. Oliver arrived not long after, and he too was sad, though not as much as Jacob. Both boys pretty soon wanted to see them. I decided this was important for them for closure, and to understand, so while they waited in the house, I went back out to arrange the kittens to hide their faces, the part that looks most unnatural after they die. The boys and I walked out to where I put them, then I carried both of them the last few feet. We stood a little ways back close enough to see who was there, far enough to not get too much detail and they were both sniffling. I tried to put voice to the occasion, saying, Goodbye, Tigger and Roo. We love you. Oliver asked if they could hear us. I said No, but I told them what I felt like anyway. Jacob, through tears, said, Dad, maybe they are in heaven now. We went back inside. Jacob said, Oh dad, I am so sad. This is the saddest day of my life. My heart is breaking. Hearing a 7-year-old say that isn t exactly easy for a dad. Pretty soon he was thinking of sort of comfort activities to do, saying I think I would feel better if we did So they decided to watch a favorite TV program. Jacob asked if Laura knew yet, and when I said no, he got his take-charge voice and said, Dad, you will start the TV show for us. While we are watching, you will send Laura an email to tell her about Tigger and Roo. OK? What could I say, it wasn t a bad idea. Pretty soon both boys were talking and laughing. It was Big Truck Night last night, at a town about half an hour away. It s an annual event we were already planning to attend, where all sorts of Big Trucks firetrucks, school bus, combine, bucket truck, cement truck, etc show up and are open for kids to climb in and explore. It s always a highlight for them. They played and sang happily as we drove, excitedly opened and closed the big door on the school bus and yelled All Aboard! from the top of the combine. We ate dinner, and drove back home. When we got home, Jacob mentioned the cats again, in a sort of matter-of-fact way, and also wanted to make sure he knew Laura had got the message. A person never wakes up expecting to have to dump a bowl of un-eaten cat food, or to give an impromptu cat funeral for little boys. As it was happening, I wished they hadn t been around right then. But in retrospect, I am glad they were. They had been part of life for those kittens, and it is only right that they could be included in being part of death. They got visual closure this way, and will never wonder if the cats are coming back someday. They had a chance to say goodbye. Here is how I remember the kittens.

Raphael Geissert: A bashism a week: maths

You've probably already done some basic maths in shell scripts, but do you know what else you can actually do?

Pick at least 4 operations that you can do in bashisms-free shell scripts:

$((n+1))
$((n>8))
$((n^4))
$((--n))
$((n*=5))
$((n++))
$((n==1?2:3))

The POSIX:2001 standard defines the arithmetic expansion requirements, which leads us to selecting all of the above operations except two:

$((--n))
$((n++))

"--" and "++" are not required to be implemented, and in some cases they may lead to unexpected results, such as the following:


$ bash -c 'n=1; echo $((++n))'
2
$ dash -c 'n=1; echo $((++n))'
1


Remember, if you rely on any non-standard behaviour or feature make sure you document it and, if feasible, check for it at run-time.

8 October 2013

Daniel Kahn Gillmor: Unaccountable surveillance is wrong

As I mentioned earlier, the information in the documents released by Edward Snowden show a clear pattern of corporate and government abuse of the information networks that are now deeply intertwined with the lives of many people all over the world. Surveillance is a power dynamic where the party doing the spying has power over the party being surveilled. The surveillance state that results when one party has "Global Cryptologic Dominance" is a seriously bad outcome. The old saw goes "power corrupts, and absolute power corrupts absolutely". In this case, the stated goal of my government appears to be absolute power in this domain, with no constraint on the inevitable corruption. If you are a supporter of any sort of a just social contract (e.g. International Principles on the Application of Human Rights to Communications Surveillance), the situation should be deeply disturbing. One of the major sub-threads in this discussion is how the NSA and their allies have actively tampered with and weakened the cryptographic infrastructure that everyone relies on for authenticated and confidential communications on the 'net. This kind of malicious work puts everyone's communication at risk, not only those people who the NSA counts among their "targets" (and the NSA's "target" selection methods are themselves fraught with serious problems). The US government is supposed to take pride in the checks and balances that keep absolute power out of any one particular branch. One of the latest attempts to simulate "checks and balances" was the President's creation of a "Review Group" to oversee the current malefactors. The review group then asked for public comment. A group of technologists (including myself) submitted a comment demanding that the review group provide concrete technical details to independent technologists. Without knowing the specifics of how the various surveillance mechanisms operate, the public in general can't make informed assessments about what they should consider to be personally safe. And lack of detailed technical knowledge also makes it much harder to mount an effective political or legal opposition to the global surveillance state (e.g. consider the terrible Clapper v. Amnesty International decision, where plaintiffs were denied standing to sue the Director of National Intelligence because they could not demonstrate that they were being surveilled). It's also worth noting that the advocates for global surveillance do not themselves want to be surveilled, and that (for example) the NSA has tried to obscure as much of their operations as possible, by over-classifying documents, and making spurious claims of "national security". This is where the surveillance power dynamic is most baldly in play, and many parts of the US government intelligence and military apparatus has a long history of acting in bad faith to obscure its activities. The people who have been operating these surveillance systems should be ashamed of their work, and those who have been overseeing the operation of these systems should be ashamed of themselves. We need to better understand the scope of the damage done to our global infrastructure so we can repair it if we have any hope of avoiding a complete surveillance state in the future. Getting the technical details of these compromises in the hands of the public is one step on the path toward a healthier society. PostscriptLest I be accused of optimism, let me make clear that fixing the technical harms is necessary, but not sufficient; even if our technical infrastructure had not been deliberately damaged, or if we manage to repair it and stop people from damaging it again, far too many people still regularly accept ubiquitous private (corporate) surveillance. Private surveillance organizations (like Facebook and Google) are too often in a position where their business interests are at odds with their users' interests, and powerful adversaries can use a surveillance organization as a lever against weaker parties. But helping people to improve their own data sovereignty and to avoid subjecting their friends and allies to private surveillance is a discussion for a separate post, i think.Tags: cryptography, nsa

Russ Allbery: Review: Grimspace

Review: Grimspace, by Ann Aguirre
Series: Sirantha Jax #1
Publisher: Ace
Copyright: March 2008
ISBN: 0-441-01599-9
Format: Mass market
Pages: 312
Sirantha Jax is a jumper: a person with the rare genetic ability to jump spaceships through the shortcut dimension of grimspace. It's a science fiction idea with a long pedigree. It creates a separate in-group for the characters to belong to, a society with its own rules, and sets up tension with the rest of the institutions of the world. In Aguirre's version, jumpers can provide the transition but direction in grimspace has to be done by a pilot, and the jumper and the pilot develop a deep psychic bond. Jax had been jumping with her husband piloting, but on their last trip their ship crashed, killing everyone on board except her. As Grimspace opens, Jax is in a treatment facility that's much more like a prison. In theory, they're trying to figure out whether she's still able to (and safe to allow to) jump. In practice, something quite a bit more sinister is going on, a fact that the reader senses early but only learns more about after Jax is helped to escape. Scarred, deeply depressed, and nearly suicidal, she's pulled into the subversive plans of a small ship of renegades who are trying to break open the Corp monopoly on grimspace travel and their tight hold over every jumper. But she's not sure whether she trusts them, or whether she cares enough about their crusade to truly join in. Grimspace follows well-trod SF paths of special cadres of pilots and navigators, lawless corners of space with local warlords, and rebellion against smothering centralization, but its first-person protagonist and point of view have more in common with urban fantasy. It's written in first-person and, at times, nearly stream of consciousness from Jax's perspective, and Jax displays plenty of profanity, acidic commentary, and emotional angst. If her special ability were shapeshifting or magic instead of jumping spaceships, one could easily see her as the typical burned-out urban fantasy detective. I liked that. It's a fun point of view when it's written well, and it felt fresh when applied to a science fiction background instead of the more typical fantasy. That said, Grimspace has a rather rough start. Jax isn't sure what's going on at first and also isn't sure she cares, and I thought that carried over to the reader's experience. The first section of the book is rough and jagged, with staccato bursts of character introduction, world-building that doesn't quite cohere, and an extended stop on a very odd outback planet that felt to me like a repurposed stage from a western. Part of the early problem is that Jax and the reader are being intentionally kept in the dark about the real goal of this group, but part of the problem is also that none of the characters start off as very likable. That includes Jax, who is a complete mess and who is both scared and despairing to the point of being almost nihilistic. The world-building unfortunately does not carry the reader through that part of the story, and at about eighty pages in I wasn't sure I was going to like this book. It does, however, get much better. For one, Jax calms down and starts making emotional connections with the rest of the crew, and that lets her demonstrate skills as a fearless problem solver. For another, while the goal of the group of people she's fallen in with isn't exactly deep, it does make sense and it does slowly become a cause the reader (and Jax) can believe in. The frenetic pace of introduction and discovery also slows down, the cast stabilizes, and the surroundings get a bit less weird (and a bit more conventional for a science fiction novel). I didn't care for the alien baby subplot I rarely do but the rest of the story slowly pulled me in. One thing Aguirre did extremely well was surprise me. There are several points later in the book where Jax gets put in a fairly typical high-stress position and does something very atypical in reaction to it, twisting the story into a shape quite a bit unlike what I had been expecting. That made Jax feel like a true free agent, establishing her independence and her desire to control her own life, and that appealed to me. Aguirre also palms one card exceptionally well, setting up an ending that I thought was the best set of scenes in the whole book, and that had me thoroughly engrossed. One can see the bones of the urban fantasy heroine inside Jax's character, but they're fresh and interesting in an SF world, and they work better than I would have expected. There is a romance, in fitting with the urban fantasy inspiration, and it didn't quite work for me, but Aguirre also builds in a reason why it might not make sense and makes it spiky and fragile without being too cliched. By the end of the book, I was, if not entirely persuaded, at least willing to go along for the ride. And that's the best summary of Grimspace, I think. Parts of it don't make a great deal of sense, and parts of it are quite choppy. But I liked Jax once she starts getting a handle on her trauma, the other characters grew on me, and the plot surprised me in some interesting ways. It's not the smoothest or most polished SF novel I've read, but it has a lot of energy and an unusual genre mix. I think I'll stick along for the ride. Followed by Wanderlust. Rating: 7 out of 10

Russ Allbery: krb5-strength 2.0

This is a rather huge release of my password strength checking package for Heimdal and MIT Kerberos KDCs, incorporating quite a bit of new work as well as some substantial restructuring. The largest change is that MIT Kerberos is now fully supported, not just with provided patches, thanks to work by Greg Hudson and MIT. The package can now build plugins for either MIT or Heimdal, as well as an external password quality program for Heimdal (the preferred method for that implementation). Alongside that change, the plugin installation path has changed to fit the layout of MIT plugins (as well as I understand it). This version also now supports password dictionaries other than CrackLib. You can generate a CDB dictionary from a wordlist using a utility included in the package and use it instead of or as a supplement to CrackLib. This dictionary lookup uses a much simpler set of permutations (the password as given plus removing some leading and trailing characters), providing a simpler approach suitable for much larger dictionaries. (CrackLib does a lot of transformations before dictionary lookup that are dubious, such as ignoring case and punctuation.) Also in this release are new configuration options to control additional checks: minimum password length (independent of whatever length CrackLib requires), requiring at least one non-alphabetic character, and rejecting non-ASCII or non-printable characters. The latter isn't to make the password stronger, but to prevent user frustration since those characters often can't be reliably entered in different situations and can result in an unreproducible password, particularly since Kerberos doesn't define a password normalization. In support of these changes, and to make testing easier, the plugin can be configured without a dictionary of any kind, or with any combination of CDB and CrackLib dictionaries. The checks for passwords based on principals are now more comprehensive, checking not only the local part but also each component of the principal with leading or trailing digits. Since many sites put their institution name in the Kerberos realm, this will also check for passwords based on the institution name. There are also some fixes to the internal CrackLib implementation, in case it is used instead of the system CrackLib, to better handle long passwords by scaling the test for simplistic passwords. You can get the latest release from the krb5-strength distribution page.

7 October 2013

Lucas Nussbaum: talk at Open World Forum

I attended Open World Forum last week (thanks to Inria for funding my travel). It was a fantastic opportunity to meet many people, and to watch great talks. If I had to single out just one talk, it would clearly be John Sullivan s What do you mean you can t Skype?!. On Saturday, I delivered a talk presenting the Debian project. It was my first DPL-ish talk to the general public, so it still needs some tuning, but I think it went quite well (slides available). Next opportunity to talk about Debian: LORIA, Nancy, France, 2013-10-17 13:30 (iPAC seminar).

Next.

Previous.