Search Results: "Luke Faraone"

11 September 2016

Niels Thykier: Unseen changes to lintian.d.o

We have been making a lot of minor changes to lintian.d.o and the underlying report framework. Most of them were hardly noticeable to the naked. In fact, I probably would not have spotted any of them, if I had not been involved in writing them. Nonetheless, I felt like sharing them, so here goes. User visible changes: In case you were wondering, the section title is partly a pun as half of these changes were intended to assist visually impaired users. They were triggered by me running into Sam Hartmann at DebConf16, where I asked him about how easy Debian s websites were for blind people. Allegedly, we are generally doing quite good in his opinion (with one exception, for which Sam filed Bug#830213), which was a positive surprise for me. On a related note: Thanks Luke Faraone and Asheesh Laroia for getting helping me started on these changes. Reporting framework / Internal changes: With the last change + the no generate reports option, we were able to schedule lintian more frequently. Originally, lintian only ran once a day. With the no generate reports , we added a second run and with the last changes, we bumped it to 4 times a day. Unsurprisingly, it means that we are now reprocessing the archive a lot faster than previously. All of the above is basically the all the note-worthy changes on the Lintian reporting framework since the Partial rewrite of lintian s reporting setup (~1 years ago).
Filed under: Debian, Lintian

30 July 2016

Luke Faraone: Snappy Sprint Heidelberg

I recently attended Snappy Sprint Heidelberg, the first Snappy sprint focused on upstream and cross-distribution collaboration.

Snappy is a technology with an interesting history: initially started to provide App Store-like semantics (atomicity, declarative security) for the Ubuntu Phone project, it has since expanded to be a platform for desktop application deployment (e.g. VLC), as well as server applications and the IoT space.

There were a number of productive discussions with people working on Snappy itself, as well as folks from Fedora, elementary OS, KDE, and elsewhere.

At the start of the week, Snappy was technically usable in several different distributions, but only shipped fully-featured (in the main distribution repositories, with confinement, etc) in Ubuntu. Some great progress was made on AppArmor confinement in Arch Linux, and there is currently beta support for confinement via SELinux.

Providing a full-featured Snappy experience in Debian has its challenges, mostly relating to the lack of a default LSM. While AppArmor in Debian is supported and there's desire to have it be the default in "buster", Ubuntu carries a number of patches that add additional functionality not yet present upstream. I'm not sure whether pursuing getting those patches merged is more viable than waiting for SELinux support in snapd, however.

I've agreed to co-maintain the snapd package in Debian, and am excited to see intentions to support building snaps on a variety of distribution bases. While I do not expect Snappy (or Flatpak, or AppImage) to replace distribution-maintained software in the foreseeable future, nor do I feel that's a desirable outcome, I do think offering users freedom to choose to use software via these systems in a safe manner is critical.

2 January 2014

Luke Faraone: Unstandardized standards are the worst: sendmail

Implementing software to replace legacy systems is always a challenge, especially when you're dealing with a system with as much legacy as sendmail, which was first introduced as delivermail in 1979.ref

Each UNIX vendor, it seems, rewrote or heavily customized sendmail. This has lead to sometimes conflicting implementations.
Case in point: -tNormally, you invoke sendmail(8) with a series of arguments indicating the subject of a message, the recipients, etc. When invoked this way, the command expects a message on standard input, waits for EOF, and then sends your message along.

However, sometimes you don't want to have to fiddle with command-line parameters; you've already written a perfectly fine message with headers.

-t is generally passed to sendmail when you want to build a message envelope from an already-formatted message, with headers, etc. For example, if you had a file foo.txt with a body like this:
From: Luke Faraone 
To: John Smith 
Subject: Hello, world!

Hi there.

you could send the message with a simple invocation of cat foo.txt sendmail -t. The system would take care of ensuring a Message-id was appended if appropriate, and queue the message to be sent. However, it is when you do slightly more complex invocations of sendmail that things get ambiguous.

It turns out that implementations differ on what exactly it means when you use -t in combination with naming destination addresses after the arguments to sendmail. exim4's documentation describes the situation in greater detail:
extract_addresses_remove_ argumentsUse: mainType: booleanDefault: true
According to some Sendmail documentation (Sun, IRIX, HP-UX), if any addresses are present on the command line when the -t option is used to build an envelope from a message s To:, Cc: and Bcc: headers, the command line addresses are removed from the recipients list. This is also how Smail behaves. However, other Sendmail documentation (the O Reilly book) states that command line addresses are added to those obtained from the header lines. When extract_addresses_remove_arguments is true (the default), Exim subtracts argument headers. If it is set false, Exim adds rather than removes argument addresses.

Thus, there's basically no mechanism for a program to know which behaviour to expect. God forbid two programs are installed on a system that expect different behaviours!

It appears that the default behaviour of Ruby is the opposite of what exim4 (Debian's default mail client) expects. This has resulted in numerous bug reports. Some replies suggest changing exim4's defaults, while others advocate overriding ActionMailer and friends to use sendmail -i instead, without -t.

That said, its not really clear who's wrong here; at no point does there appear to have been a definitive specification for sendmail, and as such we can hope for defined behaviour by common custom at best, and a sea of incompatibility bugs at worst. Amusingly, POSIX standards have nothing to say on this subject of sendmail at all; it defines that a mailx command must exist, but says that its sending mode may be implementation-specific.

As Matthew Garrett writes, there's not enough gin in the world.

10 November 2013

Luke Faraone: Why I use my bank's mobile site on my desktop

(or, cutting out bloat by using a platform where bloat won't fly)

Let me start off by saying I'm generally a huge fan of my bank, USAA. Their offerings are free of hidden fees, their phone support excellent, and the perks they provide are competitive. They don't have the best savings interest rates, but you can always find a better deal online to park money not actively in your checking account.

However, USAA's website is a behemoth. My account page took about 8 seconds to fully load, downloading 1.4MiB of content.

The "My Accounts" page you're redirected to after logging in.
It is frequently buggy; whenever I log in via Google Chrome on Ubuntu 12.04 I land on a page with a URL beginning with "https://www.usaa.com/inet/gas_bank/AccountBannerAjax" and a bunch of GET parameters like "currentaccountkey" and "accnumber" with values like "encrypted12a1f4dd1[ ]". The server returns a 200 OK, promises a Content-Length of 20, but then actually returns zero bytes. After navigating to the homepage and clicking a button, I end up getting logged in, but I wonder what percentage of their userbase are experiencing this problem?

For some strange reason, I get a lot of checks. It appears that nobody else informed the banking system that it's 2013, and the easiest mechanism for people to send money without paying fees is still on paper. To its credit, USAA made remote deposit of checks available to all customers in 2006, when it was mostly an offering limited to businesses. However, it seems like they haven't updated their web workflow since then.


Using it on the web still requires using a signed Java applet (itself discouraged by CMU's CERT) that does the incredibly complex task of letting you select a file from your computer and upload it to their servers. At least, that's what I think it does, because any time I chose "Run", my browser complained a few minutes later that the tab had stopped responding. Regardless of functionality, you can accomplish almost anything their site could currently be doing with HTML5 and a third party service if they want to crop images locally.

Spinning after logging
in on Android
USAA's mobile app for Android has another host of problems; I haven't been able to log into it for 2 weeks, and when I chatted with someone today I was told they were "doing some maintenance this weekend", so I should try again in a few hours once that's finished.

I googled around a bit for some way to perhaps make the applet work in Ubuntu (which admittedly is not a supported platform), and came upon a Facebook thread where a rep suggested using the mobile web site.

A breath of fresh air
I loaded it in my browser, and was amazed at how well it functioned. Obviously designed for higher-end devices (It didn't even load in one WAP emulator I tried), the mobile web interface was a refreshing breath of fresh air. It scaled well to a full-screen device (see below), loaded quickly, and gave me all the information I would have wanted out of the normal web interface.

Most notably: remember the whole "upload a check" workflow that required a buggy Java applet on the main website? We get bog-standard HTML form fields, no additional magic. There goes any theories about the Java client doing some magic validation or prep of the image; here, all they're getting is the images and my session cookie.


I'm still shocked at whoever thought a My Yahoo!-style homepage was the best layout for a bank, but props to the web developers who managed to make a mobile interface that was both pretty and allowed me to work around broken functionality in their implementations on every other platform I had access to.

But why was the mobile web interface the least bloated? Easy. On the desktop, you generally have a nice pipe, or if not, the user knows it and won't be too upset if your site is just as slow as other sites similarly situated. On mobile, the user downloaded all the code already, so the only latency should be the API requests against the server, right?

On the mobile web users have come to expect relatively speedy mobile-optimised sites and there's less screen real estate to do fancy things that get in the way of content. For many sites, that's a huge improvement. Of course, it would be really nice if more banks supported open protocols for interactions (USAA has a read-only, limited-duration OFX feed), but I would settle for a better web interface.

So tl;dr: USAA, please make www.usaa.com redirect to m.usaa.com, kthxbai.

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

4 October 2013

Raphaël Hertzog: My Free Software Activities in September 2013

This is my monthly summary of my free software related activities. If you re among the people who made a donation to support my work (86.18 , thanks everybody!), then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. Package Tracking System^U Distro Tracker Marko Lalic implemented quite a few interesting features in the last weeks of the Google Summer of Code (support of teams most notably). Unfortunately he didn t deploy (yet) the latest changes on pts.debian.net. Given the good work he made over the summer, I marked him as successful in his GSOC. Hopefully he will stick around and continue to contribute, he promised to try to handle some mass renaming that we agreed upon. Effectively, after much bike-shedding, I decided that the software would be called Distro Tracker . Once those last-minute cleanups are done, I plan to request tracker.debian.org to Debian System Administrators. This means that it will be deployed in parallel to the current PTS at least until we re at feature parity in the new codebase. The new codebase should be much more easy to get started with, so I should do some promotion and invite people to contribute to it possibly by writing some short how to get started documentation. I started by creating a dedicated wiki page: http://wiki.debian.org/qa.debian.org/distro-tracker
 Misc packaging I got two REJECTs from ftpmasters this month (one for galette, one for dolibarr). I took care of fixing the various issues in galette and the package has been promptly accepted afterwards. For dolibarr, I mentored the upstream maintainer about the various problems and got him to fix it. It took a bit more time and the package is thus still in NEW. I packaged wordpress 3.6, and then wordpress 3.6.1 (security update). python-django also had multiple security updates this month, I took care of one or two uploads but Luke Faraone dealt with most of them (including backports to Squeeze!). I packaged Publican 3.6.1 and uploaded dh-linktree 0.4 to fix a FTBFS issue introduced with Perl 5.18. Of anecdotal importance, but I also filed bug #721849 after seeing how much energy was spent to ensure debian/rules didn t contain an improper copyright statement. Thanks See you next month for a new summary of my activities.

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

20 July 2013

Luke Faraone: Joining the Debian FTPTeam

I'm pleased to say that I have joined the Debian FTPTeam as of the Friday before last. See Joerg Jaspert's announcement on debian-devel-announce.

The FTPTeam is responsible for maintaining the Debian software archive, and ensures that new software in Debian is high-quality and compliant with our policies.

As an "ftpassistant", I (along with Paul, Scott, Gergely, and others) will be helping to process the NEW queue, which is currently at a whopping 297 packages. Here's hoping we'll be able to get that number down over the coming weeks!

3 April 2013

Luke Faraone: Teaching free/open source to high school students

A few weeks ago I taught a class on Open Source: Contributing to free culture (catalog entry) for Spark, a one-day program put on by the student-run MIT Educational Studies Program. I was fortunate to have two helpful co-teachers, Tyler Hallada and Jacob Hurwitz, who assisted with the lesson plan and the in class lecture.

We ended up teaching 3 sessions of the 1hr 50min class that Saturday, with about 10 students in each session.

I was pretty impressed by the quality of the students; a number of them had used GNU/Linux before, but even those who hadn't were able to gain something from the experience. The class was broken up into three segments:

  1. Lecture on a brief history of open source and the free software movement
  2. Small research project on an open source project
  3. Lab where students could work through OpenHatch's training missions
The point was to mix up what could otherwise be a very boring lecture.

I think we might have missed the mark on the last bit, as I get the feeling that we didn't end up giving the students good actionables. While the quality of OpenHatch is high and the organization's campus outreach programs are amazing, skills practice only goes so far without clear direction to apply said skills. I'll be following up with the class participants to see how they're progressing on their own open source contributor journey, and will post updates if I have any.

While not an OpenHatch event, if this sort of thing interests you, OpenHatch runs a series of events like this one and has a mailing list for discussing planning and sharing best practices. Subscribe and say hi!

The presentation is enclosed below, and of course is licensed under CreativeCommons Attribution-ShareAlike 3.0. [PDF]

<iframe allowfullscreen="true" frameborder="0" height="389" mozallowfullscreen="true" src="https://docs.google.com/presentation/d/14R1o_5rOfjCw19mFtxZj29HQOhlJWK0F53MNj5tL8iU/embed?start=false&amp;loop=false&amp;delayms=3000" webkitallowfullscreen="true" width="480"></iframe>

5 January 2013

Paul Tagliamonte: Updates to dput-ng since version 1.0

Big release notes since 1.0: We ve got a new list dput-ng-maint@lists.alioth.debian.org feel free to subscribe! 
1.3:
  * Avoid failing on upload if a pre/post upload hook is missing from the
    Filesystem.
  * Fix "dcut raises FtpUploadException" by correctly initializing the uploader
    classes from dcut (Closes: #696467)
1.2:
  * Add bash completions for dput-ng (Closes: #695412).
  * Add in a script to set the default profile depending on the building
    distro (Ubuntu support)
  * Fix a bug where meta-class info won't be loaded if the config file has the
    same name.
  * Add an Ubuntu upload target.
  * Added .udeb detection to the check debs hook.
  * Catch the correct exception falling out of bin/dcut
  * Fix the dput manpages to use --uid rather then the old --dm flag.
  * Fix the CLI flag registration by setting required=True
    in cancel and upload.
  * Move make_delayed_upload above the logging call for sanity's sake.
  * Fix "connects to the host even with -s" (Closes: #695347)
Thanks to everone who s contributed! 
     7  Bernhard R. Link
     4  Ansgar Burchardt
     3  Luca Falavigna
     2  Michael Gilbert
     2  Salvatore Bonaccorso
     1  Benjamin Drung
     1  Gergely Nagy
     1  Jakub Wilk
     1  Jimmy Kaplowitz
     1  Luke Faraone
     1  Sandro Tosi
This has been your every-once-in-a-while dput-ng update. We re looking for more code contributions (to make sure everyone s happy), doc updates (etc) or ideas.

8 October 2012

Luke Faraone: Where I've gone off to

For those of you back at my university, you may have noticed I'm not there this semester.

Google's 2012 FEP team

I spent this past summer at Google, Inc, developing internal tools for the AdSense team, specifically Google Programmable Ads. Being at Google was great; I loved my team and my intern cohort, the rest of the interns in the Freshman Engineering Practicum.

I'm not currently at Google; my internship ended at the beginning of August. Although it was a blast, all good things must come to an end.

I'm not at Mason, either. I was super excited to return to university, and was just about to buy my books and get ready to move in when I got an email from a former coworker at Ksplice, a startup Oracle acquired while I interned there last year. He was starting a new company which would focus on business communications. I'd be working with a bunch of my former coworkers, and based on what I had heard of the company's plans I was confident in their ability to make an awesome product.

Needless to say, when they decided to offer me a position working there full time, I jumped on it.

From an academic point of view, Mason didn't really have much of a mechanism to support this. Co-ops are uncommon there, and not really supported for more than one semester; a full year away had never been done, according to our career services. My department was fully supportive, however, so we managed to find a way to make it work. This involved filling out some oddly-named forms, such as Special Registration for Graduation Request, which the registrar asserted was the right form, trust us on this one.

Myself and Obey Arthur Liu
at a SIPB hackathon
But that's all neither here nor there. I'm now up in Cambridge, MA, working with awesome people (including but not limited to tabbott, wdaher, jesstess, and keegan), and exploring the city. I'm hanging out with MIT SIPB, helping with the maintenance of Sugar Labs' servers in E15 and spending more time working on various open source projects.

To my friends at Mason: I miss you all. I know regardless of how the next year+ turns out, it'll be one one hell of a ride.

28 July 2012

Luke Faraone: Simple two-factor authentication



Do you want to allow "Rebooting of Cluster 19" as Jane Doe, Foo Corp? Yes/NoI've been thinking a lot recently about information security and passwords. It's widely agreed that two-factor authentication, which combines something-you-know (a password) with something you have (eg. a smart card or some one-time-password) is superior to using a password by itself. Most solutions I've seen, short of client-side certificates, both require a trusted third party and provide little auditability.

I'm working on a project which attempts to address those problems. Basically, the idea is that you attempt to perform an action on a website, like logging in, moving some money between accounts, or restarting a cluster. Then, your mobile device ((iPhone used in the graphic to the right because a SVG was handy. Image adapted from work by Virgile Pypaert [CC-BY-SA-3.0], via Wikimedia Commons)) (Android, iPhone, or some custom hardware) starts buzzing, displaying the text of the action. When you approve or deny the action, your device uses a locally stored private key to sign the text of the approval and send it back to the server. The server checks that you approved the same transaction number and text, then allows the action. The server can store the approval notice to allow auditors later to determine that somebody in possession of the private key signed the action request.

So far, I've written a small Django server application, and a Python CLI device and client. They're not yet ready for a public release; I need to write up installation instructions and test it a bit more, but I'll publish them soon on Launchpad. On the usability side of things, I plan to conduct some trials in January comparing it to things like Google Authenticator.

This should be less susceptible to MITM attacks than one-time-passwords, since you can authenticate specific transactions, rather than entire sessions.

On the other hand, I'm no security researcher. Dear lazyweb, are there any problems with the above approach? Also, if I'm going to release this (as I plan to once I get something working), I need a name. Ideas?

Luke Faraone: Google Cr-48 first impressions

On a lark, I signed up for the pilot program of the Google Cr-48 about a week ago. To my surprise, I found the distinctive box on my doorstep a week later. After initially mistaking it for an overpacked, late-model OLPC XO-1 I would have to repair, I sort of did a double-take as I realized what I had received.
Using Chrome OS


Wow, they weren't kidding about the boot time. Chrome OS responds (to suspend / resume and boot / power-off) very quickly. Responsiveness elsewhere in the OS of course varies on system load and other factors. On the "terms" page, there is a "system security setting" which tells me I have a Trusted Platform Module, and that my TPM has a randomly generated password. The dialog could use some rewording; I'm pretty familiar with the idea of a TPM, but I'm still not sure what I'm to do with that information.

Cloud print is really a problem for me, right now. I use school printers for the majority of my work, which I was previously able to use by adding them by IP address. Unless there's some magic I'm missing here, I can't do that with Chrome OS, and such a feature will not be supported. (except by "connectors" on Windows and Mac computers)
General thoughts
I can't imagine using a system running Chrome OS as a primary computer. The biggest missing feature is PGP (or any sort of encryption) support for email. This is probably not terribly difficult to implement as an extension, but the idea of my cryptographic software being automatically updated is rather unsettling. I think I'll have to agree with Paul Buchheit that ChromeOS will have to merge with Android; there is a utility for local apps, even if they're becoming less and less critical.

14 December 2011

Luke Faraone: Making Message-ID useful in Thunderbird

In Thunderbird, if you read a message on a mailing list and want to reference a post in a blog or elsewhere, you may often want to access a copy of the mailing list posting on the web. While you can often accomplish this by searching for the subject or manually finding it in the specific archives of that list, if you re using full mail headers, there s a built-in way to find a message on the web.Each email or Usenet message has a unique Message-ID. These are indexed at various providers which archive mailing lists, with Gmane being the most notable in the Free Software community.If you right-click on the Message-ID of a message in Thunderbird, you can choose to Open Browser with Message-ID . By default this menu item opens sensible-browser with a Google Groups page, which, while indexing of Usenet, remains ignorant about most mailing lists. Most people reading this will probably find that Gmane carries their favourite mailing lists, while Google does not.This is configurable, but sadly you have to choose one or another. In Thunderbird, go to Edit Preferences Advanced Config Editor, and set the mailnews.messageid_browser.url property to http://mid.gmane.org/%mid. (default of http://groups.google.com/groups?selm=%mid&rnum=1)

2 September 2011

Asheesh Laroia: Debian bug squashing party at SIPB, MIT


(Photo credit: Obey Arthur Liu; originally on Picasa, license.) Three weekends ago, I participated in a Debian bug squashing party. It was more fun than I had guessed! The event worked: we squashed bugs. Geoffrey Thomas (geofft) organized it as an event for MIT's student computing group, SIPB. In this post, I'll review the good parts and the bad. I'll conclude with beaming photos of my two mentees and talk about the bugs they fixed. So, the good:

The event was a success, but as always, there are some things that could have gone more smoothly. Here's that list: Still, it turned out well! I did three NMUs, corresponding to three patches submitted for release-critical bugs by my two mentees. Those mentees were: Jessica enjoying herself Jessica McKellar is a software engineer at Ksplice Oracle and a recent graduate of MIT's EECS program. She solved three release-critical bugs. This was her first direct contribution to Debian. In particular: Jessica has since gotten involved in the Twisted project's personal package archive. Toward the end of the sprint, she explained, "I like fixing bugs. I will totally come to the next bug squashing party." Noah grinning Noah Swartz is a recent graduate of Case Western Reserve University where he studied Mathematics and played Magic. He is an intern at the MIT Media Lab where he contributes to DoppelLab in Joe Paradiso's Responsive Environments group. This was definitely his first direct contribution to Debian. It was also one of the most intense command-line experiences he has had so far. Noah wasn't originally planning to come, but we were having lunch together before the hackathon, and I convinced him to join us. Noah fixed #625177, a fails-to-build-from-source (FTBFS) bug in nslint. The problem was that "-Wl" was instead written in all lowercase in the debian/rules file, as "-wl". Noah fixed that, making sure the package properly built in pbuilder, and then spent some quality time with lintian figuring out the right way to write a debian/changelog. That's a wrap! We'll hopefully have one again in a few months, and before that, I hope to write up a guide so that we run things even more smoothly next time.

3 May 2011

Luke Faraone: Your release sucks.

I look forward to Ubuntu s semiannual release day, because it s the completion of 6ish months of work by Ubuntu (and by extension Debian) developers.I also loathe it, because every single time we get people saying This Ubuntu release is the worst release ever! .Ubuntu releases are always rocky around release time, because the first time Ubuntu gets widespread testing is on or after release day.We ship software to 12 Million Ubuntu Users with only 150 MOTUs who work directly on the platform. That s a little less than 1 developer with upload rights to the archive for every 60,000 users.1 Compared to Debian, which (at last estimate in 2010) had 1.5 million uniques on security.debian.org, yet has around 1000 Debian Developers.Debian has a strong testing culture; someone once estimated that around of Debian users are running unstable or testing. In Ubuntu, we don t have good metrics on how many people are using the development release that I m aware of (pointers welcome), but I d guess that it s a very very small percentage. A common thread in bug reports, if we get a response at all, goes on as follows:

Triager:2 Is this a problem in $devel?

User: I ll let you know when it hits final

Triager: It s too late then. Then we ll want you to test in the next release. We have to fix it BEFORE its final

User: Ok, I ll test at beta.

Triager: That s 2 weeks before release, which will be too late. Please test ASAP if you want us to have time to fix it Of course, there are really important bugs with hardware support which keep on cropping up. But if they re just getting reported on or around release day, there are limits to what can be done about them this cycle.We need to make it easier for people to run early development versions, and encourage more people to use them (as long as they re willing to deal with breakage). I m not sure whether unstable/testing is appropriate for Ubuntu, and I m fairly confident that we don t want to move to a rolling release (currently being discussed in Debian, summary). But we badly need more developers, and equally importantly, more testers to try it out earlier in the release process.To users: please, please try out the development versions. Download a LiveCD and run a smoketest, or check if bugs you reported are in fact fixed in the later versions. And do it early and often.

  1. This number, like all other usage data, is dated, and probably wasn t even accurate when it was first calculated
  2. Developer, bugcontrol member, etc. Somebody who is not experiencing the problem but wants to help.

4 January 2011

Luke Faraone: Google Cr-48 first impressions

On a lark, I signed up for the pilot program of the Google Cr-48 about a week ago. To my surprise, I found the distinctive box on my doorstep a week later. After initially mistaking it for an overpacked, late-model OLPC XO-1 I would have to repair, I sort of did a double-take as I realized what I had received. Using Chrome OS

My Cr-48 and a Kindle

Wow, they weren t kidding about the boot time. Chrome OS responds (to suspend / resume and boot / power-off) very quickly. Responsiveness elsewhere in the OS of course varies on system load and other factors. On the terms page, there is a system security setting which tells me I have a Trusted Platform Module, and that my TPM has a randomly generated password. The dialog could use some rewording; I m pretty familiar with the idea of a TPM, but I m still not sure what I m to do with that information. Cloud print is really a problem for me, right now. I use school printers for the majority of my work, which I was previously able to use by adding them by IP address. Unless there s some magic I m missing here, I can t do that with Chrome OS, and such a feature will not be supported. (except by connectors on Windows and Mac computers) General thoughts I can t imagine using a system running Chrome OS as a primary computer. The biggest missing feature is PGP (or any sort of encryption) support for email. This is probably not terribly difficult to implement as an extension, but the idea of my cryptographic software being automatically updated is rather unsettling. I think I ll have to agree with Paul Buchheit that ChromeOS will have to merge with Android; there is a utility for local apps, even if they re becoming less and less critical.

8 December 2010

Luke Faraone: Simple two-factor authentication

Do you want to allow "Rebooting of Cluster 19" as Jane Doe, Foo Corp? Yes/No

Mockup of mobile UI

I ve been thinking a lot recently about information security and passwords. It s widely agreed that two-factor authentication, which combines something-you-know (a password) with something you have (eg. a smart card or some one-time-password) is superior to using a password by itself. Most solutions I ve seen, short of client-side certificates, both require a trusted third party and provide little auditability. I m working on a project which attempts to address those problems. Basically, the idea is that you attempt to perform an action on a website, like logging in, moving some money between accounts, or restarting a cluster. Then, your mobile device1 (Android, iPhone, or some custom hardware) starts buzzing, displaying the text of the action. When you approve or deny the action, your device uses a locally stored private key to sign the text of the approval and send it back to the server. The server checks that you approved the same transaction number and text, then allows the action. The server can store the approval notice to allow auditors later to determine that somebody in possession of the private key signed the action request. So far, I ve written a small Django server application, and a Python CLI device and client. They re not yet ready for a public release; I need to write up installation instructions and test it a bit more, but I ll publish them soon on Launchpad. On the usability side of things, I plan to conduct some trials in January comparing it to things like Google Authenticator. This should be less susceptible to MITM attacks than one-time-passwords, since you can authenticate specific transactions, rather than entire sessions. On the other hand, I m no security researcher. Dear lazyweb, are there any problems with the above approach? Also, if I m going to release this (as I plan to once I get something working), I need a name. Ideas?
  1. iPhone used in the graphic to the right because a SVG was handy. Image adapted from work by Virgile Pypaert [CC-BY-SA-3.0], via Wikimedia Commons

11 October 2010

Luke Faraone: Key transition

As Christian mentioned, the Debian Keyring Maintainers did a promote this weekend of the new keyring. I figure it s an opportune time to perform a public key transition, since this had the effect of replacing my key on the keyring. For my new key, 0xF9FDD506, I decided to opt for a 4096-bit RSA, which is stronger than I should have to worry about for the foreseeable future. The key is much better connected than my previous one, 0x0AC70206. I also have a transition document, ripped almost word-for-word from Christian s. If you signed my previous key, you should sign the new one unless you re feeling extra paranoid today.

3 October 2010

Debian News: New Debian Developers (August and September 2010)

The following developers got their Debian accounts in the last 2 months: Congratulations!

31 August 2010

Luke Faraone: Generating manpages with help2man

To quote the ftp-masters REJECT-FAQ :

What may not be obvious to the recently REJECTed developer is actually how to use help2man. To try t0 explain the process a bit more verbosely, I took the liberty of writing a tutorial on the Debian wiki. Comments and corrections are welcome.

Of course, help2man-generated manpages are no substitute for real, hand-written manpages made of sweat, blood, and the Maintainer s tears, and it won t work for all packages. This is just a start, and is much better than no manpages at all.

There was a discussion on #debian-devel a couple of days ago when I brought up my creation of the above, and some wondered if it wouldn t be better to add hooks to man-db to allow package maintainers to enable manpage generation at runtime. I m not sure if that idea will ever make it into a proposal, but, if the details of the implementation were worked out, would be much better than the above, manually generated method.

Next.