Inspirated

 
 

June 19, 2014

cl-ecc: A prototype implementation of ECC in Common Lisp

Filed under: Blog — krkhan @ 11:20 pm

Recently I’ve been reading through these excellent books in my spare time:

To ramp-up on both subjects with one shot I wrote an implementation of Elliptic Curve Crypto in Lisp. So far, it does EC versions of Diffie-Hellman, ElGamal and DSA. Some rudimentary testing was performed using the NIST-P192 curve and its corresponding ECDSA test vectors.

The package is available at GitHub in the krkhan/cl-ecc repository. Here’s a quick snippet of what the code looks like:

(defconstant *p17-curve*
  (make-instance
    'Curve
    :a 2
    :b 2
    :p 17
    :g (make-instance
         'Point
         :x 5
         :y 1)
    :n 19))

And an ECDSA with this curve:

(def-positive-test test-ecdsa ()
  (let* ((c *p17-curve*)
         (bob-priv 3)
         (bob-pub (ecdh-gen-pub c bob-priv))
         (msghash 8)
         (k 7)
         (sig (ecdsa-gen-sig c msghash bob-priv k)))
    (assert (sig-equalp sig (make-instance 'ECDSASig :r 0 :s 12)))
    (ecdsa-verify-sig c msghash sig bob-pub)))

As a disclaimer — even though I know no one would be stupid enough to do so — please do not use this code in a production environment. It was written for recreational purposes by a hobbyist who is bad with cryptography and even worse with Lisp. On the other hand, if you have any suggestions/patches, feel free to create an issue/pull-request on GitHub.

Tags: , , , , , , , ,

July 1, 2013

Blocking traffic flows selectively with a timeout from Bro IDS

Filed under: Blog — krkhan @ 2:55 am

I needed to block some flows on OpenWRT from the Bro IDS. One option was to install the recent module for expiring iptables rules which sounded like an overkill. After some tinkering around I landed on using bash and at to expire the firewall rules after timeouts (luckily the at daemon was available on OpenWRT which made my job easier).

There are three parts to the process:

The bash script

First, a script which:

  1. Constructs and adds the iptables rule to the FORWARD chain.
  2. Constructs the corresponding deletion rule.
  3. Creates a temporary bash script, writes the rule to it, makes the new script self-deleting.
  4. Schedules a launch of the temporary script with at command.

Here’s the script:

#!/bin/sh
 
if [ $# -le 5 ] ; then
  echo "usage: $0 proto src sport dst dport timeout"
  exit 1
fi
 
proto=$1
src=$2
sport=$3
dest=$4
dport=$5
timeout=$6
 
echo "  proto: $1"
echo "    src: $2"
echo "  sport: $3"
echo "   dest: $4"
echo "  dport: $5"
echo "timeout: $6"
 
rule=""
 
if [ "$proto" != "any" ]; then
  rule="$rule --protocol $proto"
fi
 
if [ "$src" != "0.0.0.0" ]; then
  rule="$rule --source $src"
fi
 
if [ "$sport" != "0" ]; then
  rule="$rule --sport $sport"
fi
 
if [ "$dest" != "0.0.0.0" ]; then
  rule="$rule --destination $dest"
fi
 
if [ "$dport" != "0" ]; then
  rule="$rule --dport $dport"
fi
 
rule="$rule -j DROP"
 
echo "rule: $rule"
 
addcmd="iptables -I FORWARD $rule"
delcmd="iptables -D FORWARD $rule"
 
delscript=`mktemp`
echo "delscript: $delscript"
 
echo "#!/bin/sh" >>$delscript
echo $delcmd >>$delscript
echo "rm \"${delscript}\"" >>$delscript
chmod 755 $delscript
 
echo "adding iptable rule:"
echo $addcmd
`$addcmd`
 
atcmd="at -M -f $delscript now + $timeout min"
echo "creating at job for deletion:"
echo $atcmd
`$atcmd`

Given below is an example run. First, let’s print the default FORWARD chain:

# iptables -nL FORWARD
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             10.42.0.0/24         state RELATED,ESTABLISHED
ACCEPT     all  --  10.42.0.0/24         anywhere            
ACCEPT     all  --  anywhere             anywhere            
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable
REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited

Block a flow for 2 minutes:

# sh blockflow.sh tcp 50.50.50.50 50 60.60.60.60 60 2
  proto: tcp
    src: 50.50.50.50
  sport: 50
   dest: 60.60.60.60
  dport: 60
timeout: 2
rule:  --protocol tcp --source 50.50.50.50 --sport 50 --destination 60.60.60.60 --dport 60 -j DROP
delscript: /tmp/tmp.SAREJvtsK0
adding iptable rule:
iptables -I FORWARD --protocol tcp --source 50.50.50.50 --sport 50 --destination 60.60.60.60 --dport 60 -j DROP
creating at job for deletion:
at -M -f /tmp/tmp.SAREJvtsK0 now + 2 min
job 79 at Sun Jun 30 14:37:00 2013

Let’s check if the new rule was added:

# iptables -nL FORWARD
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
DROP       tcp  --  50.50.50.50          60.60.60.60          tcp spt:50 dpt:60
ACCEPT     all  --  anywhere             10.42.0.0/24         state RELATED,ESTABLISHED
ACCEPT     all  --  10.42.0.0/24         anywhere            
ACCEPT     all  --  anywhere             anywhere            
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable
REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited

After 2 minutes, the temporary bash script shall remove the rule and then delete itself. To confirm:

# iptables -nL FORWARD
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             10.42.0.0/24         state RELATED,ESTABLISHED
ACCEPT     all  --  10.42.0.0/24         anywhere            
ACCEPT     all  --  anywhere             anywhere            
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable
REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited

The Bro module

A simple module which export one function, i.e., BlockFlow::block which takes a conn_id and a count and calls the bash script with appropriate parameters:

module BlockFlow;
 
export {
  global block: function(id: conn_id, t: count);
}
 
function block(id: conn_id, t: count)
{
  print fmt("blocking %s:%d -> %s:%d for %d minutes", id$orig_h, id$orig_p, id$resp_h, id$resp_p, t);
 
  local protocol = get_port_transport_proto(id$resp_p);
  print fmt("protocol is: %s", protocol);
 
  local cmd: string = fmt("sh blockflow.sh %s %s %d %s %d %d", protocol
                                                             , id$orig_h, id$orig_p
                                                             , id$resp_h, id$resp_p, t);
  print fmt("executing: %s", cmd);
  system(cmd);
}

Bro module usage

And finally, using the module from a Bro script:

@load ./blockflow
 
event bro_init()
  {
    local id: conn_id;
    id$orig_h = 10.10.10.10;
    id$orig_p = 10/tcp;
    id$resp_h = 20.20.20.20;
    id$resp_p = 20/tcp;
    BlockFlow::block(id, 2);
  }

And the flow will be blocked for 2 minutes. Unfortunately, due to the way at command works the granularity of timeouts is limited to minutes. If you really want to block flows for only a few seconds a quick solution would be to use sleep in place of at before expiring the rule.

Tags: , , , , , , ,

December 10, 2012

Bro IDS on OpenWRT

Filed under: Blog — krkhan @ 12:59 pm

While I was at SysNet, we had been working on a project we called “Shrimp” — Software-defined Home Router Intelligent Monitoring Point. The goal of the project was to provide a framework for easy programmatic access to network monitoring on low-cost, commodity, home router devices. One of the requirements was to have an IDS on the home routers for which we chose Bro — the leading framework for semantic analysis of network traffic.

The OpenWRT OS was chosen as the target platform. Its SDK contained a cross-compile toolchain for CMake projects. However, during the compilation Bro tried to run the binpac and bifcl executables for processing intermediate files. The executables refused to run on the build platform if the target platform architecture was different (mostly the case, e.g., we were building on x86-64 and target was arm).

The (not-so-pretty ™) workaround we used was to build Bro twice. Once for the host, and once for the target. The CMake files were then patched to first generate binpac and bifcl binaries if they weren’t provided and then use the provided binaries if they were defined at make time. The first compile generated the binaries on x86-64 and the second compile (for arm) used the earlier binaries to process the bif files.

The Makefile and patches are available in this tarball: openwrt-bro.tar.gz, while the compiled ipk package is also available for installation. Here is a test execution of Bro on OpenWRT:

# bro –v
bro version 2.0
# cat test.bro
event bro_init()
{
	print "Hello World!";
}

event new_connection(c: connection)
{
	print "New connection created";
}
# bro test.bro
Hello World!
# bro -i br-lan test.bro
Hello World!
New connection created
New connection created
# ls
conn.log           notice_policy.log  reporter.log       weird.log
dns.log            packet_filter.log  test.bro

A heap of thanks to Zaafar for dealing with my messy code and providing the links to hosted files :) !

Tags: , , , , , , , ,

March 18, 2012

slicehosts: Extract host-based traffic out of pcap dumps

Filed under: Blog — krkhan @ 2:56 pm

During the course of my work on botnet security we have had to deal with mammoth traffic traces captured at a local ISP. While analyzing the traffic we needed to extract traffic for some certain hosts out of large pcap files. An obvious solution would be to run tshark once for each host, filtering the traffic for that particular IP and writing it to a separate pcap file. However with the number of hosts approaching thousands and the pcap traces approaching terabytes in size tshark didn’t really fit the bill.

Initially I thought of writing a splitter in Python but my colleague’s aversion for using Python on large network traces coupled with lack of maintenance of libpcap bindings resulted in me going for C/libpcap directly. The new C-based slicer is available at our GitHub respository. It needs glib to compile though, as I needed a hash table implementation for maintaining the list of hosts that need to be sliced. The Makefile in the repository should take care of compiling with the appropriate flags.

Onto the performance, the speed of slicing is only throttled by libpcap‘s own read/write throughput as most of the remaining work is done in constant time. It took only 71 minutes (or 1.1 hours) to slice 1019 hosts out of a 180 GB pcap file on 2.5 GHz CPU. In simpler words, it’s lightning fast.

Right now the script does its job well enough. If someone needs to package it I’ll prefer removing the glib dependency in favor of perhaps glibc‘s own hash table implementation (search.h). In any case, I hope it proves helpful for other people playing with large pcap files.

Tags: , , , , , , , , ,

October 4, 2011

Summing up Google Summer of Code 2011

Filed under: Blog — krkhan @ 12:32 pm

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:

Drop-down menus for arm
(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:

CLI bandwidth stats for arm

Down arrow

GUI bandwidth stats for arm
(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:

Graphs panel for garm 0.1
(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:

Connections panel for garm 0.1
(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:

General panel for garm 0.1
(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:

Configuration panel for garm
(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:

Exit node selector for garm
Exit node selector for arm
(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.

Tags: , , , , , , , , , ,

September 4, 2011

Summer of Code Progress: Exit node selection

Filed under: Blog — krkhan @ 1:49 pm
Summer of Code Archive Inspirated Code
Original Proposal Google Docs
PDF
Repository Tor Project Git
Mentor Blog arm Development Log

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:

Exit node selector for garm
(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:

Exit node selector for arm
(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.

Tags: , , , , , , , , ,

August 23, 2011

Tarball generator for Git commits

Filed under: Blog — krkhan @ 12:56 am

While working for GSoC last year I kept track of Bazaar patches I sent in for Arsenal. This year I was using Git and as the need arose to generate a submission tarball for my commits I wrote this small utility script: git-generate-tarball.py.

To invoke the script, change into your Git repository and provide an author name and a file as an argument:

[krkhan@orthanc tor]$ /home/krkhan/Downloads/git-generate-tarball.py "Kamran Riaz Khan <krkhan@inspirated.com>" /home/krkhan/Downloads/tor-gsoc-krkhan.tar.gz

generating tarball for commits between Mon May 23 00:00:00 2011 +0000 and Mon Aug 22 19:00:00 2011 +0000
generating patch for commit 5a801a8c8b71c9551a80913398135809cb10cecd

/home/krkhan/Downloads/tor-gsoc-krkhan.tar.gz created

The default starting and ending dates for the commits correspond to the schedule for GSoC 2011. You can specify a starting date for the commits you want to be packaged using the --since argument:

[krkhan@orthanc arm]$ /home/krkhan/Downloads/git-generate-tarball.py --since="August 1, 2011" "Kamran Riaz Khan <krkhan@inspirated.com>" /home/krkhan/Downloads/arm-gsoc-krkhan.tar.bz2

generating tarball for commits between August 1, 2011 and Mon Aug 22 19:00:00 2011 +0000
generating patch for commit 546ca73259d7863e3efe5e11e09c023c2790a2f6

/home/krkhan/Downloads/arm-gsoc-krkhan.tar.bz2 created

Same goes for the --before argument:

[krkhan@orthanc tor]$ /home/krkhan/Downloads/git-generate-tarball.py --before="August 14, 2011" "Kamran Riaz Khan <krkhan@inspirated.com>" /home/krkhan/Downloads/tor-gsoc-krkhan.tar.gz

generating tarball for commits between Mon May 23 00:00:00 2011 +0000 and August 14, 2011
generating patch for commit 5a801a8c8b71c9551a80913398135809cb10cecd

/home/krkhan/Downloads/tor-gsoc-krkhan.tar.gz created

Or a combination of both:

[krkhan@orthanc arm]$ /home/krkhan/Downloads/git-generate-tarball.py --since="August 1, 2011" --before="August 14, 2011" "Kamran Riaz Khan <krkhan@inspirated.com>" /home/krkhan/Downloads/arm-gsoc-krkhan.tar.gz

generating tarball for commits between August 1, 2011 and August 14, 2011
generating patch for commit 546ca73259d7863e3efe5e11e09c023c2790a2f6

/home/krkhan/Downloads/arm-gsoc-krkhan.tar.gz created

If you want to leave the dates undefined you can leave the arguments empty. For example, the following command shall process all commits before June 1, 2011:

[krkhan@orthanc arm]$ /home/krkhan/Downloads/git-generate-tarball.py --since= --before="June 1, 2011" "Kamran Riaz Khan <krkhan@inspirated.com>" /home/krkhan/Downloads/arm-gsoc-krkhan.tar.gz

generating tarball for commits before June 1, 2011
generating patch for commit 8b4dc162f75d5129e41f028c7253b7b265c8af76

/home/krkhan/Downloads/arm-gsoc-krkhan.tar.gz created

Hope this helps fellow GSoCers.

Tags: , , , , ,

August 12, 2011

Summer of Code Progress: Tor configuration

Filed under: Blog — krkhan @ 4:52 am
Summer of Code Archive Inspirated Code
Original Proposal Google Docs
PDF
Repository Tor Project Git
Mentor Blog arm Development Log

“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:

Configuration panel for garm
(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.

Tags: , , , , , , , , , ,

July 17, 2011

Summer of Code Progress: garm 0.1

Filed under: Blog — krkhan @ 5:16 pm
Summer of Code Archive Inspirated Code
Original Proposal Google Docs
PDF
Repository Tor Project Git
Mentor Blog arm Development Log

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:

Graphs panel for garm 0.1
(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:

Connections panel for garm 0.1
(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:

General panel for garm 0.1
(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.

Tags: , , , , , , , , ,

June 28, 2011

Summer of Code Progress: Graphs, logs and acid

Filed under: Blog — krkhan @ 7:06 pm
Summer of Code Archive Inspirated Code
Original Proposal Google Docs
PDF
Repository Tor Project Git
Mentor Blog arm Development Log

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:

CLI bandwidth stats for arm

Down arrow

GUI bandwidth stats for arm
(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.

Log panel for arm
(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.

Tags: , , , , , , , , ,
Next Page »