Inspirated

Due to a number of commitments which I had pinned back during the summer for GSoC I was unable to attend much to the Internet over the past few weeks. Now that I’m back a summary of this year’s coding festival is in order:

The Program

This year I was working with Electronic Frontier Foundation/The Tor Project for improving the Anonymizing Relay Monitor (arm). The original proposal can be downloaded from this link are accessed via a browser at Google Docs. However, do note that not all of the goals from the proposal were met. Some were modified, some were removed altogether while some new ones were added — the details of which I’ll be explaining in the following sections.

Overall the program has been an extraordinarily enjoyable and learning experience for me. My involvement with Ubuntu last year had already taught me how invaluable it is to merge with your mentoring organizing’s developer community. This year most of my collaboration took place in #tor-dev on OFTC. Many times when I was stuck or heading towards an improper direction with my code the core Tor developers helped me and provided advice for design decisions as well as general guidance about the way things work in Tor. It wasn’t only a privilege to be helped by such rockstars, but was also vital as I can see in hindsight how disastrous it would have been if I had attempted to work through the program entirely on my own.

A huge thanks goes to my mentor Damian. Most of the credit for making this program an enjoyable and stimulating experience for me goes directly to him. He has one of the best combinations of code-people skills among people I’ve known. I would’ve loved meeting him and the Tor community in PETS ’11 but couldn’t travel due to some paperwork fiasco which was entirely a result of my slothful attitude towards anything involving government offices. Nevertheless, I do hope to meet the guys next year in PETS ’12.

The Code

In order to not sound repetitious, I’ll provide a quick summary of the milestones while linking to the posts which explain them in detail:

Menus for arm CLI

My first task was to add dropdown menus for the curses interface to arm. Even though the menus were replaced by Damian’s rewrite, they went a long way in helping me assimilate myself with the arm codebase:

(Click on the thumbnail for larger version.)

Graphs and logs for arm GUI

GTK+ was chosen as the toolkit for developing the arm GUI prototype. While GTK+ has its own disadvantages when compared to Qt (platform portability — or the lack thereof — being the foremost), it fared well in light-weight Unix environment such as Live CDs (e.g., Tails). Bandwidth graphs and logs for various arm events were added to the prototype:

(Click on the thumbnails for larger version.)

Connections and general stats for arm GUI

Moving on with the GUI, next up was to improve its conformity with the rest of the user’s desktop:

(Click on the thumbnail for larger version.)

And then re-use arm’s CLI connection resolvers in order to display stats about Tor circuits and control connections:

(Click on the thumbnail for larger version.)

A small addition was migration of the “sticky” panel from CLI which was moved under a “General” tab and provided miscellaneous info about Tor and arm:

(Click on the thumbnail for larger version.)

Configuration panel for GUI

Another important panel in the arm CLI was its configuration interface which provided a nice and documented approach to altering Tor’s settings. It was migrated to GUI with nice dialogs for validating user input:

(Click on the thumbnail for larger version.)

Along with the configuration panel a few patches to Tor and Vidalia were developed which would allow arm to be notified of changes made by an external program via a CONF_CHANGED event. The support for CONF_CHANGED still isn’t solid in all Tor controllers yet which I plan on addressing in coming months.

Exit node selector for arm CLI & GUI

A popular feature request among Tor users was to be able to select the country for their exit nodes. While I initially planned on providing them more fine-grained control over their circuits (such as path length), Tor developers advised against it and hence the selection was limited to the exit-node’s locale:

(Click on the thumbnails for larger version.)

The Nutshell

“It goes on forever — and — oh my God — it’s full of stars!”

It’s just that awesome, seriously. Stars from the FLOSS strata gather around and help inexperienced and aspiring developers all over the globe for two months in order to bring more code and — more importantly — more people to the open-source world. The experience with GSoC not only helps me in general open-source development, but also proves to be priceless at my workplace for my research in software defined networks. If you’re even remotely interested in open-source do keep an eye on the program’s website for future updates.

The final weeks of GSoC 2011 were spent by me working on exit node selection for Tor users. The GUI controller can now be used to define a list of countries, after which only those exit nodes shall be used which lie in one of the specified territories:

(Click on the thumbnail for larger version.)

For the CLI, Damian decided that the general use case for exit node selection is specification of a single country so pressing ‘E’ in the connections panel brings up a list from which one can be chosen:

(Click on the thumbnail for larger version.)

Please note that the exit node restriction works only for circuits built after the selection. Therefore it might be a good idea to send a NEWNYM to Tor after specifying the countries — which you’ll have to do manually for the time being until I add the feature to (g)arm controllers.

In my next post I’ll cover a summary of my involvement with GSoC this year, that is, after I finish with the regular chores of code submission etc.

“O Marvelous! what new configuration will come next? I am bewildered with multiplicity.” — William Carlos Williams

Up until now my GSoC development was dealing with the “monitoring” aspects of arm. In addition to being a monitor a Tor controller is also supposed to, well, control the Tor client. Tor offers a detailed specification which can be used to interact with a running client and control it in a myriad of ways. This specification is then used by controllers like arm and Vidalia to fetch and/or update the client configuration.

The CLI configuration panel for arm already understood the control specification quite well. The first step towards reusing those portions for the GUI was to rewrite the inheritance code so that underlying data structures of the CLI were automagically connected to the Gtk+ models. That made the actual implementation of GUI configuration panel a whole lot cleaner. As things are, the panel detects the data types of configuration options and opens pertinent dialogs for user input:

(Click on the thumbnail for larger version.)

Next item in to-do list was implementing a path selection panel in arm. After a thorough discussion on IRC with the core Tor developers it was decided that giving end-users complete access to the PathSupport component of TorCtl would ultimately hurt their anonymity with little (if any) pay-off. Letting them choose the country of their exit relay was still seen as a useful feature which is what I’m working on right now.

Meanwhile, while setting the configuration options needed to choose an exit country I figured that arm should be notified of any changes made by other controllers to the options in question. Damian pointed me to ticket #1692 which proposed an enhancement for this very purpose. He had already created a patch for the job but few quirks needed to be addressed before the patch was ready for being merged. Thanks to help from Nick Mathewson and Robert Ransom I was able to fix the code and get it inside the tor and tor-spec repositories.

To make use of the new CONF_CHANGED event I also wrote patches for TorCtl and Vidalia. The TorCtl patch shall help me in making arm aware of configuration changes. While the Vidalia one is a proof-of-concept which created a signal and connected it to a debug function which for the time being just logs the options changed for the running Tor instance.

I hope to be done with exit node selection within a couple of days after which I’ll port the feature to CLI version of arm. It’ll be a good little exercise to start decoupling the arm interfaces from its backend so that future development is more streamlined and fun.

Damian and I have decided that the GUI prototype for arm should be released to the public for a feedback round. As always, the code is available from the Git repository.

So far, the graphs and logs now support a look more conforming with the rest of the GTK+ theme:

(Click on the thumbnail for larger version.)

The connections panel lists circuits and control ports in use. The resolvers in use are in fact, the same ones used by the CLI so the results are pretty consistent:

(Click on the thumbnail for larger version.)

The “sticky” or “header” panel which provided general Tor/arm info has been moved to the notebook for giving it more horizontal space:

(Click on the thumbnail for larger version.)

Owing to my lack of creativity the GUI was named “garm”. Which coincidentally turned out to be the name of a talking dog from one of Tolkein’s short stories. Proving once again that Tolkein/Middle Earth/Norse mythology are any geek’s safe fallback plan for being imaginative.

While the GUI is still in infancy, we’d love any feedback we can get. If you have a suggestion you can post a comment here, drop by at #tor-dev or (preferably) mail your thoughts to tor-talk. I’ll be grateful for any ideas that end up making garm more useful for relay operators.

The great thing about a command line application is being able to SSH into the thing from anywhere and with anything. Nevertheless, the general public appeal of GUIs has always remained undeniable. After all, over the decades one of the favorite pass times of Steve Jobs — the man who knows a thing or two about public appeal — has been suing and/or getting sued for patents related to GUI. It’s not to say that we are planning an iTorMonitor for App Store (you still have iSSH if you’d like), but a graphical interface shall hopefully go a long way for attracting newbie relay operators.

The first items to be ported to GUI were the bandwidth graphs. After a thorough discussion on #tor-dev regarding how to achieve graphing with respect to feature sets, packaging issues and wheel reinvention; cagraph was chosen as the way to go (among Matplotlib and drawing directly to GDK surfaces). I took screenshots of both interfaces running side-by-side in order to judge how accurate the graphs were and the results look fine:

(Click on the thumbnails for larger version.)

Next up were the log messages dispatched by arm or Tor. While Damian would not be entirely happy with the fact that I’m not terribly innovative with the UI translation ;-) , I did stumble upon an interesting side-feature of using timestamp based sorting. The user can sort the entries in ascending order and he’ll always see the recent-most entry as it pops up in the view, or he can revert the order and see old entries at his leisure while the new entries populate elsewhere below.

(Click on the thumbnail for larger version.)

One other aspect I noticed while designing the UIs was that I have atrocious color selection skills. The color scheme of the entire application isn’t consistent and might even invite a backlash once it goes public. Therefore I plan on discarding all hardcoded colors in favor of theme colors from GTK+ itself — lest the GUI be packaged into a separate arm-trippy once it makes to major distros.

Smolt is a hardware profiler for Linux distributions which makes it easier for end-users to report back their machine configurations to a centralized database. Mike McGrath provides an excellent backend for developing Smolt GUIs which I have coupled with GTK+ for GSmolt:

(Click on the thumbnails for larger versions.)

The script can be found at the gsmolt repository on GitHub. Things on todo list include profile reporting in a separate thread and better error handling. I’ll provide RPM and Deb packages when the code is ready for a public release.

As a side note, this is the first project I have tracked using GitHub (as opposed to Launchpad + Bazaar). While Launchpad has its added advantage of PPAs which make it easier to push out public releases for Debian derivatives, I’m liking the Git experience so far. Hopefully some day Copr shall mature to a point where it can be the end-all, be-all Launchpad alternative for Fedora users.

GTK+ needs no introduction. LaTeX is the first thing that pops in anyone’s mind if mathematical equations’ typesetting is under consideration. Matplotlib — while not as well-known as the former two — is the super easy and elegant solution for scientific plotting on *nix platforms.

For an application demo, I required all three. Past experience has taught me that the most straightforward way of “gluing” things together is Python. GTK+ therefore = PyGTK. Next up was LaTeX, and a previous solution of mine for embedding LaTeX in PyGTK came to the rescue. The final requirement of Matplotlib was fulfilled without any hassle since the library was already written in Python.

The collective result was pretty:

radareq-0.1.tar.gz

(Click on the image for larger version.)

The linked tarball contains the Python scripts for the application. For everything to run smoothly, LaTeX and Matplotlib packages need to be installed on your system. If you encounter any issues running the code, feel free to flame your distribution for the apparent lack of sanity regarding package management.

Apple fans have Dashboard. KDE folks have Plasma. Gnome/Xfce people have, er.. tough choice.

Everyone likes desktop widgets. They’re pretty, and can prove to be really helpful with careful setup. Over the past few years, I have tried a few different widget frameworks and it’s kind of a strange phenomenon that all of them died the slow open-source death. adesklets, gDesklets and now Screenlets have bitten the dust. Screenlets, however, deserves special mention because of being the most recent among the deceased.

People behind Screenlets deserve credit for providing an easy-to-use framework for desktop widgets, which wasn’t the case with adesklets or gDesklets. Nevertheless, the compliment is in a way reserved for the basic framework and not the screenlets themselves. While it was fun and easy to write new widgets in Python, the existing ones were broken more often than not. There must be 100+ screenlets available online right now; pick any recent vanilla distribution and a considerably many will fail to work properly on it. Perhaps this is one of the reasons why the package never made it into Fedora repositories. The base product had significant potential, but the end-results built upon it were — in the greater picture — largely a disappointment. Before the situation improved however, Screenlets passed away quietly. Without even an obituary on Wikipedia or the project page itself. People like me who were waiting for a stable release kept finding out through Launchpad comments that development has split and moved to a new project called Universal Applets.

UA is still in early development stages, and does not offer even all the features present in Screenlets’ last version (such as widget zoom). But at least among all the remaining Gtk+ widget frameworks, it remains the only one with active development going on. While I wish its developers good luck for what appears to be a more promising framework than any of the ones mentioned above, I can only hope that it doesn’t disappear into obscurity like its ancestors — resulting in a Yet-Another-Widget-Framework. Meanwhile, I’m sticking with Screenlets’ last release since it works reasonable well once you’ve sorted individual widgets’ kinks out.

Sometimes, migrating to Qt doesn’t sound all that bad of an idea.

I had never really laid my hands on LaTeX until I required it in one of the helper applications for my graduation project. Unfortunately, the requirement wasn’t as simple as producing some documents as I had to embed mathematical expressions on the fly in my PyGTK apps. Googling around for the solution, I found GtkMathView which accomplished something similar to this albeit using MathML. However, my luck ran out on me again as the widget lacked Python bindings. The other solution was to generate transparent PNGs on the fly and include them as GtkImages. This worked rather well, as the final code allowed easy modifications to the generated expressions.

Requirements for the code were:

• LaTeX
• dvipng
• latexmath2png

Final results:

And the simple code behind it:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

#!/usr/bin/env python
"""An example demonstrating usage of latexmath2png module for embedding math
equations in PyGTK
 
Author: Kamran Riaz Khan <krkhan@inspirated.com>
"""
 
import gtk
import os
import latexmath2png
 
pre = 'gtktex_'
eqs = [
	r'$\alpha_i > \beta_i$',
	r'$\sum_{i=0}^\infty x_i$',
	r'$\left(\frac{5 - \frac{1}{x}}{4}\right)$',
	r'$s(t) = \mathcal{A}\sin(2 \omega t)$',
	r'$\sum_{n=1}^\infty\frac{-e^{i\pi}}{2^n}$'
	]
latexmath2png.math2png(eqs, os.getcwd(), prefix = pre)
 
def window_destroy(widget):
	for i in range(0, len(eqs)):
		os.unlink(os.path.join(os.getcwd(), '%s%d.png' % (pre, i + 1)))
	gtk.main_quit()
 
window = gtk.Window()
window.set_border_width(10)
window.set_title('LaTeX Equations in GTK')
window.connect('destroy', window_destroy)
vbox = gtk.VBox(spacing = 10)
window.add(vbox)
 
images = [None] * len(eqs)
for i in range(len(eqs)):
	images[i] = gtk.image_new_from_file('%s%d.png' % (pre, i + 1))
	vbox.pack_start(images[i])
 
window.show_all()
gtk.main()

Recently, I needed to create some visualizations in a drawing area for one of my PyGTK apps. The PyGTK tutorial had an excellent writeup complete with a working example for immediate help. Unfortunately, my requirements were of a “grid” view on which other objects would be drawn. Naturally, I hoped for some variable on the GtkDrawingArea which I would set to true and have the grid lines drawn automatically. But since I couldn’t find any such magic setting in the API, I had to draw the lines manually.

Consequently, I could use either of the following approaches:

• Loop horizontally and vertically while draw_line()ing.
• Draw a 10×10 box as a tile and repeat it over the background.

The first approach would’ve worked faster but involved writing more code. The second was uglier — especially for larger images — but resulted in me having to add only a few lines to the example:

72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91

        xpm_data = ["10 10 2 1",
            " 	c #EEEEEE",
            ".	c #FFFFFF",
            "          ",
            " ........ ",
            " ........ ",
            " ........ ",
            " ........ ",
            " ........ ",
            " ........ ",
            " ........ ",
            " ........ ",
            "          "]
        tile_pixmap, tile_mask = gtk.gdk.pixmap_create_from_xpm_d(
            area.window, None, xpm_data)
        tile_gc = area.window.new_gc(fill = gtk.gdk.TILED,
            tile = tile_pixmap)
        width = int(self.hruler.get_range()[3])
        height = int(self.vruler.get_range()[3])
        area.window.draw_rectangle(tile_gc, True, 0, 0, width, height)

Turning this:

Into this:

Note that the 10×10 tiles’ borders match prettily with the markers on top and left rulers. There will definitely be some more efficient method for achieving this but for the time being tiling serves my needs perfectly.