Unknown and partly hidden

Trough the year I wrote a few applets that I use in combination with media/extra keys on my keyboard. Reading the Arch Linux BBS yesterday I found an interesting script called the "ThinkPad Presentation Manager" that offers a quick selection for enabling external displays. Ideal for binding with the Presentation key found on many laptops, and on my TravelMate. Until now I used a bunch of shell aliases to enable some commonly used setups, like "tvon" for watching movies or "vgawine" for playing Syberia.

I liked the idea and find it to be a nicer solution than shell aliases, so I wrote my own with Python and pygtk. Pypres is a small utility for enabling external displays based on presets, intended to be used with the "Presentation" media button found on many laptops. Double-click on a preset or selecting one and pressing the OK button will invoke xrandr and exit. The code could also serve me as a good skeleton for quickly creating new small ListView/TreeView utilities in the future.

I've been using awesome for over a year now, and version 3 for the last 7 months. I had a lot of widgets in my awesome2 setup and porting them to Lua was very important to me. From a few different approaches I choose Wicked. It's a big module for awesome that provides a few default widget types and allows registering custom functions to create new widgets easily. Wicked is great because it takes care of everything for you; registering widgets with awesome, setting timers, unregistering... It's also the only module (for now) that allows easy access to suspend and resume functions, so you can easily suspend your widgets when running on battery. Speaking of which, another killer feature is widget caching, you can have multiple widgets that use the same function and it gets executed only once. Good example is the volume widget, I have a textbox and a progressbar both showing the volume level.

I've been using Wicked for the past 7 months, and I wrote a lot of custom widget functions for it. My rc.lua was growing huge, close to the 1000 LOC mark. It bothered me for some time and my first take on it was to remove all the widget types I don't use from Wicked, and integrate my own widgets with it. That worked for a while, but then another problem arose. Often when bored or feeling creative I wanted to write a new widget, a good example is the wireless information widget. I would need it only when I'm outside or traveling, in the mean time it would just sit there in memory. When my local Wicked copy started growing past the 1000 LOC mark it was time for another solution.

Widgets need to be modular, you plug-in widgets that you need and ignore the rest. The Obvious project provides exactly that, a modular widget library. However it didn't sit well with me (in its current state), their design is that a widget module should not only crunch data, but set up everything. From output formatting to registering button bindings and timers.

What I had in mind for a widget module is that it should be a small, 10 lines, module with a worker function that crunches some data and spits out numbers/results. How that data will be formatted, should it be red or blue I want to define somewhere else, in the rc.lua most likely. If you need a new widget or maybe you are just motivated or feeling creative... you write a quick function that does the work, that's all you need to focus on. When you need it, you plug it in.

Pondering on it for a while I decided to do it my self, otherwise I would never be satisfied. Since I was already familiar with Wicked, and it has suspend/resume/caching... I split it and modularized the code. The new widget library I called Vicious, it has some of the old Wicked widget types, a few of them rewritten, and a good number of new widgets. Small summary of changes so far:

* Original code modularized
* Widgets ported from Wicked:
  - CPU, MEM, FS, NET, Date, Uptime, MPD
* Widgets written for Vicious:
  - Thermal, Battery, Mbox, OrgMode, Volume, Entropy, Disk I/O,
    System Load, Wireless, Pacman
* MEM widget rewritten, uses pattern matching
  - Swap widget merged with MEM widget type
* MPD widget rewritten, a bit more versatile
* NET widget rewritten, uses pattern matching
* CPU widget rewritten, uses pattern matching
* FS widget rewritten, uses pattern matching
  - Also fixed padding in the process
* Removed deprecated helper functions

I guess at least one user will share my views on widgets, and could be interested in the code. Since my rc.lua is by far the most requested file on this web server there will be a few more people interested in Vicious. For that reason I decided to share it.

In my previous article on Alpine I mentioned the Pine Privacy Guard as one solution for adding GPG support to Alpine. Well the problem with that and other filters is that they all do inline signing and encryption of messages. Due to a limitation in Alpine you can't work with MIME RFC2015/3156 multipart/signed and multipart/encrypted messages. The rest of the MUA world is keeping up with the standards, and many mailers won't even validate your messages with inline signatures. At the same time you are unable to validate their own.

Fortunately there is a filter for Alpine which adds MIME support. Topal requires some modification of the Alpine code in order to send and receive multipart e-mail, but it's well worth it. The setup however is not easy and I decided to note a few things.

To start with topal, if it's not packaged for your distribution you can download the sources and build it your self (you will need the gcc-gnat Ada compiler). In Arch Linux the topal package is in AUR. Next you should rebuild your Alpine package applying both patches provided by topal.

When both are installed, generate the topal config file first:

$ topal -default > ~/.topal/config

Then edit "~/.pinerc" and enable topal support, relevant parts shown here:

 
# List of features; see Pine's Setup/options menu for the current set.
# e.g. feature-list= select-without-confirm, signature-at-bottom
# Default condition for all of the features is no-.
feature-list=
#	...,
#	...,
	enable-topal-hack

# This variable takes a list of programs that message text is piped into
# after MIME decoding, prior to display.
display-filters=_BEGINNING("-----BEGIN PGP ")_ /usr/bin/topal -display _TMPFILE_ _RESULTFILE_

# This defines a program that message text is piped into before MIME
# encoding, prior to sending
sending-filters=/usr/bin/topal -send _TMPFILE_ _RESULTFILE_ _RECIPIENTS_,
	/usr/bin/topal -sendmime _TMPFILE_ _RESULTFILE_ _MIMETYPE_ _RECIPIENTS_

Edit "~/.mailcap" next:

# cat (default) should not be used, e-mail text would just scroll by
text/plain; less '%s'; copiousoutput
# Topal GPG integration for Alpine
multipart/signed; topal -mime '%s' '%t'; needsterminal
multipart/encrypted; topal -mime '%s' '%t'; needsterminal
application/pgp; topal -mimeapgp '%s' '%t'; needsterminal

You will need several extra utilities (check your config file). Some like metamail are available in just about any distribution but there are a few that were not easy to track down. To start with MIME-tool, a modified copy is distributed along with topal. You will also need dos2unix from the unixdos-tools, but the hd2u implementation could work as well. In case you need run-mailcap and mime-construct, grab those from Debian mime-support and mime-construct packages.

This covers the setup, how to actually use topal from within Alpine is well explained in "Topal Usage" section of the README. If you are interested in some tips from my own practical experience with topal read my notes on alpine and topal.

Now that some are using GnuPG for the first time (at least I like to think you are) you noticed that almost any action requires your passphrase. I'd like to introduce you to the GnuPG Agent which is used for key management. Using an agent you can, among other things, enter your passphrase only once, the first time it is needed. On all subsequent actions the agent will take care of it. It's similar to what the ssh-agent does with SSH keys.

GPG should use the agent when ever possible. Added to "~/.gnupg/gpg.conf":

# Passphrase agent
use-agent

Since you are editing config files you should prepare the agent one now, "~/.gnupg/gpg-agent.conf":

# Environment file
write-env-file /home/user/.gnupg/gpg-agent.info
# Cache settings
default-cache-ttl 3600
default-cache-ttl-ssh 3600
# PIN entry program
#pinentry-program /usr/bin/pinentry-curses
pinentry-program /usr/bin/pinentry-gtk-2
# SmartCard daemon
#scdaemon-program /usr/bin/scdaemon
disable-scdaemon

Agent makes use of the pinentry package, which provides a collection of simple PIN and passphrase entry dialogs. You can choose between the ncurses, gtk and qt versions.

You can start the agent from your "~/.xinitrc" file.

# Start the GnuPG agent and enable OpenSSH agent emulation
gnupginf="${HOME}/.gnupg/gpg-agent.info"

if ( pgrep -u "${USER}" gpg-agent ); then
    eval `cat $gnupginf`
    eval `cut -d= -f1 $gnupginf | xargs echo export`
else
    eval `gpg-agent --enable-ssh-support --daemon`
fi

That is all. You enter your passphrase once, first time it is needed, and for the rest of the session (see the cache section in the manual page) you can work transparently. However you will notice that I enabled the SSH support. The previously mentioned ssh-agent does a similar thing for your SSH keys, but you can avoid running both since the GPG agent has SSH emulation. If you are not using the SSH agent it's a good time to start.

SSH public key authentication can be used by a client to access remote systems without the need for the login password. It makes remote access easier and allows for all kinds of automation. Additionally if password logins are forbidden it drastically enhances your security. Because now you have two-factor authentication, something you have (your key) and something you know (your passphrase). An attacker can not guess your password or try to brute-force it, but even if he knew your key passphrase it would be useless without the key.

You can generate a key pair with:

$ ssh-keygen -t rsa -b 4096

I don't need to tell you that you should pick a decent passphrase when prompted and never choose the easy way and leave it empty. Now you have two new files in your "~/.ssh" directory: "id_rsa" with your private and "id_rsa.pub" with your public key. You should copy your public key to a remote server with >scp or ssh-copy-id (note that many servers are configured too look for the keys in files named: "authorized_keys" or "authorized_keys2", you can rename your "id_rsa.pub" file, create a symlink or append its contents to an existing keys file). When your key is on the server you can try to login. As with GPG you are asked for your passphrase every time. This is where the agent comes in, if you use one you are asked for your passphrase only the first time, while all other logins are completely transparent.

If your gpg-agent is running by now, with SSH emulation, you should add your key to the agent. The list of allowed keys is stored in the "~/.gnupg/sshcontrol" file. As with the ssh-agent you need to use the ssh-add utility. It's as simple as:

$ ssh-add

...and your key is approved. Your agent is now taking care of both GPG and SSH keys, making your life much easier.

Last tip. To make use of the agent in a cronjob you need to export SSH_AUTH_SOCK, since it changes with every session you can do something like:

* * * * * SSH_AUTH_SOCK=`find /tmp/gpg-* -name S.gpg-agent.ssh` ssh ... ...

...or read the needed data from the agent information file (see the above xinitrc example).

I have problems with my left hand for a while now. Years of bad habits, and lack of vision. Today I control my environment exclusively with the left hand. Emacs with the pinky (Control on Caps Lock) and my window manager with the thumb (Win/Super_L). This works wonders for my productivity but it puts too much stress on the hand. It started to show in the recent months. Before making some drastic changes (such as switching to Dvorak) I did a lot of small changes and tried a few different things.

Quite a few people recommend to switch Alt_L with Ctrl_L. That works for me too, and it's not bad being that thumb is the strongest finger while pinky the weakest. However I choose to control awesome with Super_L and that puts too much stress on the thumb it self (and then there is also the fear of Carpal). Next step was to move Super_L to AltGr. It that situation I control my whole environment with both thumbs... I tried quite a few of these variations, going full circle and returning to the original setup. This time around I read a lot on the subject of RSI and found some good documents. Wrists by JWZ is a good start and provides many references. I decided to start with the very basics.

There's no point in using Dvorak if I'm sitting at my desk like a hunchback 10 hours a day. This is where the real problem lies. I need to maintain proper posture, good working conditions, and the reason for this article; regular wrist breaks. This is where Xwrits comes in, it's a great utility that will remind you (and even force you) to take wrist breaks - which also suggests real breaks; a stroll around the garden, having a snack, or doing some stretches.

One of the tricks Xwrits uses is window flashes, different colors should annoy you and maybe force you to take a break when you decide to ignore it. However that only made me kill the window ASAP. There is also the fact that the bitmaps used are old and ugly as hell. Fortunately you can define your own images. I wanted something calmer, and obviously better looking. I managed to find a nice set of hand gesture cliparts over on "Lord of Design" and used them to create a set for Xwrits. Additional signs suit me well, and I placed them in the bottom right corner as the (break)clock is by default in the upper left. I start it from "~/.xinitrc" with:

# Xwrits reminds you to take wrist breaks and avoid RSI
/usr/bin/xwrits typetime=40 clock breakclock top \
ready-picture=$HOME/.xwrits/ready.gif rest-picture=$HOME/.xwrits/rest.gif warning-picture=$HOME/.xwrits/warning.gif &

I wrote about those nice OSD notifications on volume changes, some are in hardware, but GNOME apparently also has its own. Both for volume and brightness changes. Since I wrote pvol I wanted to do something about brightness too, and when I saw some GNOME screenshots yesterday I took a few minutes to do it.

A lot of things happen when you press a brightness hotkey. Hardware generates an ACPI event which gets picked up by acpid. Acpid will run a handler script if you specified one. On some modern distributions quite a few other steps take place. Handler could generate a key-press to be picked up by the GNOME Power Manager which would eventually display the notification. But it could also pass it on to HAL and rely on it to do the "right thing". For purposes of plight I checked respective shell scripts in "/usr/lib/hal/scripts/linux" but they were useless. On top of all that there is also the fact that on most newer laptops, including my Acer, the brightness is changed in hardware. There is no need for any userspace action. Thinking about the approach I decided to make use of acpid and I did a cheap hack on pvol. Renamed it to plight.py, and I call it from an acpid handler with options: "-s -a" to just show the current brightness level (retrieved from ACPI) when I press a hotkey. Let's see the other options:

$ plight -h

Usage: plight [-s] [-c PERCENT] [-a] [-q]

Options:
  -h, --help            show this help message and exit
  -s, --status          display current brightness level
  -c PERCENT, --change=PERCENT
                        increase or decrease brightness to given percentage
  -a, --acpi            make use of ACPI (default is xbacklight)
  -q, --quiet           adjust brightness without the progressbar

Following the previous article on the GNU Privacy Guard you can (and should) read all about public-key cryptography and the web of trust on Wikipedia. In the context of this article it is important to know what is your public and what private key and how they are used. If you generated your keys following the previous article you now have two keys; one is called a public key and it will be used for encryption, while the other is a private key and it will be used for decryption. You can share your public key freely with anyone you wish, and they can use it to send you encrypted e-mail. E-mail which only you can decrypt and read being that you posses the private key - which should never be shared and stay private at all times. In a similar manner, if you wish to send secure e-mail to an associate you will need his public key and use it to encrypt your message. If you read the Wikipedia articles you know by this point that in a secure public-key cipher scheme, the private key should not be deducible from the public key. So rest at ease, by sharing your public key you are not placing the integrity of your private key in danger.

Besides encrypting your e-mails you can also just sign them. In which case they will not be encrypted, but they will guarantee the integrity of your message (that it was not tampered with on the way) and it will provide message authentication (guarantee that the e-mail really came from you). This is where the web of trust comes in. How does the recipient really know that it was you who sent the message, and that the key used for signing is really yours? A given public key can be digitally signed by a third party (i.e. a friend and his key) to attest to the association between you and the key.

Now, let's actually do something with our keys. First things first, if you want to receive secure e-mail you need to share your public key. You can export it either to a file, or directly to a Public Key Server (PKS) for other people to find and use:

$ gpg --armor --output user.asc --export user@host.tld

You can share the resulting file with your friends. Or you could publish it to a PKS right away, where everyone can find it. Servers mostly share keys between them and keep them in sync, so you don't need to publish your key to multiple servers:

$ gpg --keyserver keys.gnupg.net --send-key user@host.tld

In the same manner you can add public keys to your public keyring with the "--import" option:

$ gpg --import friend.asc

If you had enough of typing cryptic commands to your terminal emulator, it's a good time to mention that there are good graphical interfaces to GnuPG. With KDE you get Kgpg and with GNOME comes Seahorse. You can manage your keys and key rings, encrypt files, import/export keys and more...

Applying GnuPG to e-mail is easy these days. For Thunderbird there is Enigmail. For Gmail and other web-mail services there is FireGPG. Both Kmail and Knode (Usenet client) have built-in support. Text-based e-mail clients are also covered, mutt has native support while Pine (now Alpine) can easily be linked to GPG, but there are also wrappers such as PinePG that make things easier. Please note that some communities (i.e. some Usenet groups) are bothered by the "GPG trash" (as they call it) in messages. If for any reason you decide against signing your e-mail in certain cases, you could at least publish your GPG information in the headers of messages, but it's not a bad idea in any case. You can introduce two custom headers to your e-mail:

X-GPG-PUBLIC-KEY: http://some.host.tld/~user/user.asc
X-GPG-FINGERPRINT: XXXX YYYY ...

As I mentioned in the previous article, GPG doesn't limit you to e-mail only. Some IM clients (Gajim, Kopete and Pidgin are very popular) will allow you to use GPG for protecting all your instant messages. You can also protect personal and sensitive data or backups. I often use these two shell aliases for fast encryption and decryption of documents:

gpge='gpg -r "user <user@host.tld>" -e '
gpgd='gpg --decrypt'

To make things even easier and automatic you can use EasyPG for GNU Emacs and I'm sure a similar extension exists for Vim.

You don't necessarily need to use your key for encryption. You can also create simple passphrase protected archives:

Encrypt a file with a passphrase
$ gpg -c bank-account.txt

Decrypt with
$ gpg -d bank-account.txt.gpg

Last tip. One, easy, way to protect your backups would be to send your data trough GPG prior to compressing it:

Encrypt
$ tar -vcz dir1 dir2 file1 | gpg -er user@host.tld -o backup.tar.gz.gpg

Decrypt
$ gpg -o backup.tar.gz -d backup.tar.gz.gpg

Stir in the OpenPGP community, a new attack on SHA-1 appears to break it a bit worse than before. US government agencies were instructed to cease all reliance on SHA-1. Deprecated. So now people are also massively generating new GPG keys to move away from SHA-1. GPG (open source alternative to PGP) default up until this point were DSA 1024-bit keys limited to a 160-bit hash (traditionally SHA-1). Meaning that probably more than 70% of primary keys in certain circles are indeed 1024-bit DSA keys. We can expect a lot of revoked keys in the following months. In the mean time GnuPG developers are considering a switch to RSA 2048-bit keys as the default.

I overreacted a bit in my previous PGP article. Some communities do use GPG heavily and rely on it, and I am just hanging with the wrong crowd. The fact that Arch Linux still doesn't have signed packages is not helping the situation. If you don't use GPG it's a good time to start, I will go trough some basics of key management and I hope you will follow. It will not only allow you to protect your e-mail and IM communication but also to protect your personal and sensitive data, encrypt your backups and more. I also want to do my part in helping the situation described in the previous article.

The SHA-1 problem should be dealt with first. Our signatures should use stronger digests, with SHA-2 and we should indicate that we prefer stronger digests in incoming messages. These preferences will also be published together with our public key, once we export it and place it on a "Public Key server" (PKS) or share it with our friends. I added to my "~/.gnupg/gpg.conf":

# Algorithm preferences
# - key signing algorithm
cert-digest-algo SHA512
# - encryption algorithms
personal-cipher-preferences TWOFISH AES256 AES192 AES BLOWFISH CAST5 3DES
# - signing algorithms
personal-digest-preferences SHA512 SHA384 SHA256 SHA224 SHA1 RIPEMD160 MD5
# - compression algorithms
personal-compress-preferences BZIP2 ZLIB ZIP Uncompressed
# - new keys algorithms
default-preference-list SHA512 SHA384 SHA256 SHA224 TWOFISH AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed

Now I need a new key. This time at least a 2048-bit key, using RSA:

$ gpg --gen-key

  Please select what kind of key you want:
     (1) DSA and Elgamal (default)
     (2) DSA (sign only)
     (5) RSA (sign only)

  Your selection? 5

  RSA keys may be between 1024 and 4096 bits long.
  What keysize do you want? (2048) 4096
  Requested keysize is 4096 bits

After this comes a series of questions. The first is how long the key should be valid. You should set an expiration date, somewhere between 1 and 5 years would be reasonable. Your name, your e-mail and a comment (a common practice is to set your nickname) come next. The e-mail address being most important, it's the reason you are doing this remember. If you have multiple addresses and you want to use this key for all (or some) of them you can add additional identities later (we will come to that). The last question is to enter a passphrase used to protect this key. I don't need to tell you that it should be a decent pass-word.

When it's done you will get a notice similar to this:

pub 1024R/8865ED17 2009-05-09 [expires: 2009-05-10]
uid Test User (tuser) [tuser@host.tld]

Note that this key cannot be used for encryption. You may want to use
the command "--edit-key" to generate a subkey for this purpose.

This "8865ED17" bit is the key ID, it's important you know to recognize your own for any later key management. Now observe the notice at the end, the key you generated can be used for signing, you need another key, a subkey, for encryption. Remember, the first option was "DSA and Elgamal" in which case both keys would be generated at once. Let's generate the RSA subkey (for encryption only). Important are the commands I issue at the "Command>" prompt and I will skip some blocks of text, indicated with "...":

$ gpg --edit-key 8865ED17
  ...
  Command> addkey
  ... 
  Please select what kind of key you want:
     (2) DSA (sign only)
     (4) Elgamal (encrypt only)
     (5) RSA (sign only)
     (6) RSA (encrypt only)

  Your selection? 6

  RSA keys may be between 1024 and 4096 bits long.
  What keysize do you want? (2048) 4096
  Requested keysize is 4096 bits
  ...
  Command> save

As I mentioned earlier you can tie multiple identities to your key-pair. You can edit your key and use the adduid command to add an additional identity and e-mail address. However you should be careful, it's not always wise to place all your eggs in one basket. You should not tie your on-line profile with your business address if you don't want people connecting the two. As you can add identities you can also remove them (deluid), but it's not possible to delete identities from keys already published on a PKS, they only keep stacking new identities on to your public key. Generating an additional key-pair would be a wiser choice if you are unsure.

Since you are dealing with gpg directly it's a good time to create a revocation certificate. In case you forget your passphrase in the future, or your key is compromised it will allow you to flag the key as invalid. You should store your revocation certificate in a safe place (i.e. print it on paper), and when time comes to revoke your key you need to import it to your keyring and publish the updated public key to a PKS:

$ gpg --gen-revoke 8865ED17

If you need to import it to your keyring:
$ gpg --import user.revoke.asc

Now you are ready to use your keys for all kinds of purposes. However this article is getting rather long and I will write about the basics of public-key cryptography and general application of the GNU Privacy Guard in the following article.

Opening articles concentrated on my favorite software, so both Awesome WM and Emacs org-mode were introduced. These days I worked on connecting the two, and I'm very happy with the results.

Org-mode article discussed connecting org with remember mode for quick notes taking. On my desktop Emacs always has a dedicated tag and often when I want to note something I'm on another tag. It happened that by the time I switch tags and initiate remember the idea is half gone. Other people thought about this one too, and I found an article on the emacs-fu website that proposed a nice solution. With a few custom functions and using Emacs server (or daemon with Emacs 23) I can spawn a nice little remember frame to grab my note. Especially good tip was that you can also grab the clipboard contents automatically. The results you can see on the screenshot above. It's amazing how well it fits into awesome. I also took this chance to sort out my .emacs as it was turning into a mess.

While you have the screenshot open, observe the widget directly above the remember frame, one with the calendar icon. That's my org-mode widget showing the number of pending items from the agenda, which will also spawn the org-agenda view on a mouse click. Idea for that widget came from the org-awesome module which also makes use of the notification system to actually show the pending items. I don't use notifications and I use wicked for my widgets so I had to do some modifications to fit those requirements. The code can be found in my rc.lua.

When I finish a (really) good book, I want to share it with someone. I want to say "this is really something, it blew my mind" or even "it changed my life" and I can only hope that it can change yours. I mentioned a few books before, and only in that context. I don't have a need to write reviews but I wish I wrote more about my thoughts on particular books or ideas and concepts presented in them. I just never got into the habit of writing this stuff down. That's why I re-read my favorite books often.

These days I was reading a nice little book, "The Book Thief" by Markus Zusak. Death narrates the story of a little girl growing up in Nazi Germany, and revolves around books. It reminded me of how I learned to read, my parents had the presence of mind to buy me a reading primer when I was 4. Unlike some other countries in the region we don't have dubbed TV shows, instead everything is subtitled. It didn't take me long to start pairing what I heard with subtitles displayed on the screen and I learned (or better to say understood) English by the age of 6. I'm very grateful for that as today I am able to enjoy most books in their original form and language, unspoiled by translators.

Unfortunately I don't know many people who read, and I even some that never read a single book. So maybe someone who will read this doesn't read books either, or just has a short attention span. If so, maybe I could interest you in some great short stories. I found "0wnz0red" just recently and didn't have the chance to finish it, parts of it that I did read were excellent. Author is Cory Doctorow and just this winter I read his book "Little Brother", released under a CC license so you can download a copy for free. Reading "0wnz0red" I was reminded of another short story, one by my favorite author. It's called "Jipi and the paranoid chip" and it's about a girl that has to disable car alarm systems, which have personalities of paranoid schizophrenics. It's set in the (not too distant)future and it's a great story.