Applications: PasswordSafe

See Time For a Change for the first in this series, or check out the index to see all the posts dealing with Arch Linux. Today I will set up PasswordSafe, an open source password manager. But first some information about this excellent program.

There are a number of password managers out there with various features that they hope will differentiate them from the others. PasswordSafe is one of the oldest and simplest ones available. All good password management programs should have a few key features:

• Really strong, proven crypto - all your sensitive passwords are going in this thing; if you can't trust it to keep them safe, don't use it.
• Offline database storage - I don't trust another company to store my passwords; I want to know that the file is encrypted well, and I want it on my hard drive. My hard drives are backed up, and they won't get bought up by Oracle or go out of business with my data.
• Configurable random password generation - with a good password manager, you should only need to remember one more password for the rest of your life. That means the rest of them can be completely random, which is way stronger than "Tr0ub4dor&3".
• Copy/paste password use - you shouldn't have to type passwords stored in the database; just copy/paste them into the password entry field. This is more convenient and more secure, since it defeats a keylogger.
• Paranoid clipboard management - the system-wide clipboard is accessible by any program running, including malware. A good password manager will give you options on how aggressively it will clear the clipboard of your sensitive password.

There are many other nice-to-have features, like the ability to run on a USB key, good organization capabilities so you can find things quickly, username/password auto-type, and a software keyboard for accessing the database in case you fear a keylogger might be installed.

PasswordSafe, as you might expect from my preferred application, has all these features and more. Being open-source, it has verifiably strong crypto: anyone can peruse the code and do their best to crack it. It's OK if you're not skilled in crypto-cracking... it's enough to know that other very talented individuals have leveled their weapons at it for many years and its strength is proven. It stores everything in a single data file (encrypted, obviously), which you can put anywhere you want. It treats it like a document, so you can have multiple password databases if you want. Being a simple file, you can back it up, copy it around, synchronize it with Dropbox, whatever your desire and comfort level dictates. Double-click entries to copy the password into your clipboard, which is cleared a configurable time later.

Password generation can be configured application-wide or by individual entry, in case a particular site has unusual requirements; or you can type in an existing password, too. One little trick I like to do is to put my credit card numbers in as passwords and include the expiration date in the username, which is displayed in the list. This lets me copy/paste my credit card # into an online store checkout page without fat-fingering it.

Important note: the PasswordSafe I know and trust is at http://passwordsafe.sourceforge.net/ - there is also a "passwordsafe.com" website that purports to have a password manager called "HyperPassword". I have no idea if this is a good program or not. If you want to use what I know and trust, use the SourceForge link. It's not that I mistrust this other one, per se, but PasswordSafe is well-proven, has an excellent pedigree, and doesn't go off and buy a domain name that might sow confusion. That's a tactic used by malware (PDF, see page 6).

For the longest time, PasswordSafe was developed only for Windows. Being open-source, eventually some Linux developers got involved and ported it to WxWidgets, a cross-platform GUI library. Open-source projects like this typically provide binaries for Windows, since Windows doesn't come with build tools. Then if it supports Linux, there is always a source-based distribution so that users can build it for their Linux distro of choice. Eventually, there may also be binary distributions for various popular distros, Ubuntu usually being the first. PasswordSafe has just barely reached this final stage. Linux support has been marked "beta", probably forever, and the only binaries for Linux are for 32-bit Ubuntu/Debian.

Now, I could just run PasswordSafe's Windows version under Wine on any Linux distro I choose. Doing so is easy: just download the Windows installer and run it - Wine takes over and goes through all the installer steps. But that's cheating! This application is open-source, and it runs fine on 32-bit Ubuntu. Making it run on 64-bit Arch might be a challenge, but it's possible.

Full disclosure: A few months ago I managed to make it work on 32-bit Arch for other reasons. I had to change code to do it, which I posted to the PasswordSafe bug-tracking forum; they responded and told me my changes had been incorporated into the next release, which is now out. But whether that will translate into an easier 64-bit experience is anyone's guess. There is no package for PasswordSafe in the AUR, either, so I'm really on my own for this one.

I will be skipping some the mundane steps in this install, since I expect a more complicated journey. After downloading and extracting the source archive, I perused the Linux installation instructions, which only provide instructions for installing the Ubuntu/Debian binaries, and the Linux Development ReadMe, which was last updated in November 2010. Yeah, on my own here. Most Linux source archives follow the "configure ; make" paradigm, but that didn't work in this case because no one built a configure script. So I tried just "make release", based on experiences with the 32-bit installation, first installing the Xerces-C XML parsing library and the wxWidgets GTK library as per the year-old ReadMe. Wonder of wonders, it built the first time! They must have gotten my changes applied successfully.

Unlike more polished Makefiles, this one leaves the binary buried under the src/ui/wxWidgets/GCCUnicodeRelease subdirectory. I went ahead and ran pwsafe from this directory, and after an error message about help not being available, the application started right up and waited for me to use it. This is a success already, but I would prefer not to see an error message on every startup.

Not being an installer, "make" doesn't put the in-application help repository anywhere helpful. The expected location for that file is hard-coded to be /usr/share/doc/passwordsafe/help/help.zip. But there didn't appear to be a help.zip file anywhere in the source tree after building. Looking through the Makefile.linux file at the top level, it looked like there was no build action for "help", unlike with Windows. So I did it by hand based on what I found in the Makefile.windows by typing "make -C ./help", which built help.zip, as well as several other languages (helpES.zip, helpFR.zip, etc). Then as root I copied help.zip to its expected location and tried again to run pwsafe. Sure enough, no error message, and clicking the Help button brought up the help window.

I don't really use the on-screen keyboard, because I don't fear a keylogger on my home system. But for completeness I gave it a try, and saw an error message in my console window: execvp(xvkbd) failed. It turns out that xvkbd is a package that wasn't listed in the Linux Developer ReadMe, so I installed that via pacman and tried again. Success!

Now that all the pre-authentication stuff is working, it's time to move on to the meat of the application. Unwilling to potentially corrupt my password database, I opted to create a new one. That way I can also put in fake credentials and be unafraid of posting screenshots. I went ahead and added several groups and passwords without incident, using both generated and hand-entered passwords.

Double-clicking an entry did successfully load the password into the paste buffer. However, when I tried the Auto-Type feature, which is supposed to take the selected username and password and paste them into the active window, separated by a TAB, I got some interesting results. I performed Auto-Type into a text editor so I could view the results directly. The screenshot below is the fully-exposed details for my "Tenth-Sixth Checking" account (click to zoom in).

When I use Auto-Type, however, I get: "Ipa.gif;>gpd" (tab) "hs,l<gkjHadhoa". Now, Auto-Type is not a feature I really use, so this is really just an amusing bug, but the interesting thing is that this apparent nonsense string of characters is exactly what I would get if I was typing in QWERTY on my Dvorak keyboard. That must mean that: (a) PasswordSafe is sending fake keypresses, not letters, when it does an Auto-Type; and (b) it pays no attention to the keyboard layout settings, even though I set them at both the operating system and XWindows levels. Sure enough, I found a bug report from a German keyboard user with a similar issue, and the devs had already responded saying it was probably a bug having to do with hard-coded keyboard layouts. I added my own experience to the comment tree in case it helped them figure it out. Since I don't really use Auto-Type, as I noted above, this doesn't slow me down.

One last issue that I won't try to solve because it doesn't really matter is the system tray icon. PasswordSafe tries to give some visual feedback so the user knows whether the safe is "open" (accessible) or "closed" (requires a password to access). In Windows, these two icons look fine, but on my Arch/KDE system, they look like they have some erasing issues. The slightly magnified compound picture below from left to right is Windows Open, Windows Closed, Linux Open, Linux Closed. Again, not a show-stopper, just a little strange. By the way, my Linux taskbar is a little bigger than on my Windows machine, so the size difference is to be expected.

Even the Windows icons, seen magnified, look pretty bad. Seems like a nice vector image in the form of an SVG would be a good idea... but I suspect that wouldn't work on Windows.

The final acid test was to open my real database (after backing it up of course), make some changes, and then attempt to use it again from my host machine. No problems whatsoever! 

Overall, this went far more smoothly than I expected. Having dealt with the compile issues previously and waited long enough for the devs to get the updated release out there definitely helped.

The only thing left is Bacula for backups. I have been putting that off because it is such a pain to set up, and because I will need to redo the VirtualBox networking in order to test it completely.

Next: Bacula
Or check out the index.

Yaourt and NixNote

See Time For a Change for the first in this series, or check out the index to see all the posts dealing with Arch Linux. Today I will set up yaourt, which makes working with the Arch User Repository (AUR) much easier, and then use it to get NixNote installed.

Yaourt stands for "Yet AnOther User Repository Tool", which is a terrible name, but it is very effective at its job. It makes the AUR significantly easier to work with, by giving a pacman-like interface that does everything pacman does, but adds the AUR as a source. This makes installing packages from the AUR as simple as installing packages from the core repository... usually.

Having fought with and failed to get NixNote installed by hand, I turned in frustration to yaourt, and was pleasantly surprised at how easy it was to use. I still don't trust it entirely, because I can't find much in the way of documentation about it, and there seems to be some contradictory information about whether it is safe to use it for non-AUR packages or not. But I suspect like any labor-saving tool, my comfort with it will come long before my understanding.

I installed yaourt in a very similar manner to my installation of libgcal and akonadi-googledata before. It relies on the package-query package in AUR, which therefore needs to be installed first. The following steps can also be found at yaourt's website:

$ cd ~/abs
$ wget http://aur.archlinux.org/packages/package-query/package-query.tar.gz
$ wget http://aur.archlinux.org/packages/yaourt/yaourt.tar.gz
$ tar xf package-query.tar.gz
$ tar xf yaourt.tar.gz
$ cd package-query
$ makepkg -si
$ cd ../yaourt
$ makepkg -si

Next is to install NixNote. In theory, all I should need to do is:

$ yaourt nixnote

And in theory, there is no difference between theory and practice. But in practice, there is (Yogi, or Al, or Jan). And so it is in this case. After a bunch of package downloading, configuring, and compiling -- all done by yaourt -- I finally get this error:

/usr/bin/ld: /caviar/usr/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.2/../../../../lib/libm.a(k_standard.o): relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC

/caviar/usr/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.2/../../../../lib/libm.a: could not read symbols: Bad value

collect2: ld returned 1 exit status
make[1]: *** [libpng12.la] Error 1
make[1]: Leaving directory `/tmp/yaourt-tmp-mark/aur-libpng12/src/libpng-1.2.46'
make: *** [all] Error 2

Let's break this down, shall we?

• /usr/bin/ld - this is the linker reporting the error, which means that all the code has compiled just fine, and now the build system is trying to assemble it into an executable binary file.
• .../lib/libm.a(k_standard.o) - the failure occurred while linking the static library "libm.a" into the executable, specifically some reference inside the program module k_standard.c, it doesn't really matter what.
• relocation R_X86_64_32s against `.rodata' can't be used when making a shared object - I'm not really sure what is going on here, but I suspect it has something to do with some of the weirdnesses of working with 64-bit addressing within libraries that were written assuming a 32-bit world. This sort of thing happens far more often than it should.
• recompile with -fPIC - advice from the linker on how to solve this issue, I love it.
• .../lib/libm.a: could not read symbols: Bad value - probably caused by the previous error. Once something goes wrong in a build process, its effect usually cascades forward a ways before the build system stops.
• make...libpng12.la - we weren't even working on building NixNote, here, but libpng12, one of its dependencies. libpng is a library for manipulating PNG graphics, and the repository version of this library is at 1.4. NixNote is woefully out of date, though, and won't work with anything newer than the old 1.2 version of libpng, and this is that outdated library.

The -fPIC flag to the linker is a new one to me. Here's a man page reference, taken from man ld:

-f name  :  When creating an ELF shared object, set the internal DT_AUXILIARY field to the specified name.  This tells the dynamic linker that the symbol table of the shared object should be used as an auxiliary filter on the symbol table of the shared object name.

This doesn't really clear it up much. Some more searching led me to some related content that implied that the "recompile with -fPIC" advice was actually suggesting that I recompile the math library libm, which is an integral part of the operating system (pun intended). This is probably not a great idea, so instead I'll try to disable the use of shared libraries and PIC (Position Independent Code). By the way, if you want more information about all these issues, read this and then explain it to me. ;-) Anyway, I want to adjust the build process of libpng12, which all starts with the same command:

$ yaourt nixnote

Except this time, I'll answer "yes" when it comes to the libpng12 PKGBUILD question. Within this file, I see a section called "build" contains the line:

./configure --prefix=/usr

This is a very standard way to get a Linux source package ready for building and installation, and the best place to make my change. Specifically, I'll change it to:

./configure --prefix=/usr --disable-shared --without-pic

And this time, it sailed right through, building and installing libpng12, and then building and installing NixNote successfully, even adding it to my KDE menu for me and everything. But when I try to run it:

$ nixnote

...

java.lang.UnsatisfiedLinkError: /tmp/QtJambi_mark_amd64_4.5.2_01_gcc-20090628-2055/lib/libQtGui.so.4: libpng12.so.0: cannot open shared object file: No such file or directory

This isn't a big surprise, since I did disable the building of the shared library libpng with that first additional flag. For some reason, it occurred to me to do a file search on my hard drive for libpng12, and lo and behold, there was a libpng12.so.0 sitting in the Dropbox application directory! Yoink...

$ sudo ln -s ~mark/.dropbox-dist/libpng12.so.0 /lib/libpng12.so.0

$ nixnote

Finally, I can enter my Evernote account details, synchronize my notes from their server, and I'm off to the races. It's kind of sad that I had to jump through so many hoops to get this installed when the right answer would be to update NixNote to use the latest (and fully supported) version of libpng. Maybe someday I'll look at how feasible doing that would be, but today I just want my software to work.

Almost there!

PasswordSafe for secure password management

Moneydance for personal finance DONE!

ThinkOrSwim for option trading DONE!

Minecraft DONE!

Dropbox for cloud storage DONE!

Kontact for e-mail, contacts, and calendar DONE!

Choqok for micro-blogging (following and posting to Twitter) DONE!

NixNote for notes/personal organization DONE!

Okteta hex editor DONE!

Bacula for automated backups

Applications: Kontact

See Time For a Change for the first in this series, or check out the index for all the posts on Arch Linux. Today I'll finish getting email, calendar, and contacts working, which I started last time by working with the Arch User Repository.

Kontact, and Some Light Ranting
Kontact is the Personal Information Manager (PIM) that comes with KDE. If you've ever used the full version of Microsoft Outlook before, you've used a PIM. Kontact is actually one of the reasons I wanted to give KDE a try, because from everything I've read, it is as well-integrated with the operating system as Outlook is in Windows, and has better extensions for synchronizing with information sources like Google. As an Android user, Google integration is a key feature for me - I find it frustrating that keeping contacts and appointments synchronized seems to be so difficult for the big boys (Microsoft and Apple) to handle correctly. I realize this is by design, of course. Outlook has no revenue value to Microsoft without a big Exchange Server license, and Apple wants your eyes on iTunes, not Google services. Too bad. This is my computer, and I'll make it do what I want. And that goes double for my phone.

Installing Kontact isn't necessary, since it comes with KDE. But getting it to integrate with Google information services takes a little more work. I installed those extra things last time, and now it's time to get them configured.

Even before I get started, I can hear you thinking, "geez, this is a lot of work, why don't you just use Microsoft Outlook?" And yes, it's a bit of work. But it's worth it to me to have all my contacts, email, and appointments synchronized across my phone and computer without having to run a big wasteful server in my house. Besides, the Exchange Server at your office that provides all these services is just as hard to set up and maintain (maybe harder), and it doesn't even integrate with anything other than Microsoft Exchange! Try this little experiment: call your IT department and tell them that you want all your Google contacts to show up in your address book in Outlook, and insist that you want to be able to edit them within Outlook or on your phone, and have the changes automatically show up in the opposite location. Now, while you deal with a very annoyed IT department, I'll go ahead and set this all up for myself with no dedicated hardware and no capital expense... in a couple of evenings.

Configuring EMail
KMail is the email component of Kontact, and configuring it is just like configuring any other IMAP client. I added accounts for each of my main email boxes, setting my login and password for each. I set up an outgoing persona and hooked it up to my primary email box with authentication so that my email provider would forward my mail out to the world for me. And then I selected the inboxes from each of my email accounts as "Favorites" so I wouldn't have to search through all my folders to see what spam I had. KMail is not as easy to use and customize as Thunderbird, but I can get used to it.

Here's a screen shot, in case you've never seen an email client set up before.

Configuring Akonadi - Contacts
Akonadi is the KDE information service, providing contact, calendar, and general file-indexing services to all KDE applications via a unified API. If this sounds complicated and error-prone, then you are very perceptive. I want to set up Akonadi to use my Google contacts and calendar, and I have two calendars I want to access: my personal calendar, and the shared calendar that my wife and I use to track our joint plans. In my previous post, I installed the pieces necessary to make this happen. Now I need to configure them.

I start by going into the Contacts section of Kontact (anyone else see the naming oddity here?), and deleting the empty local-storage contacts list that Kontact provides by default. Having that will just lead to confusion later. Next, I right-click in the same pane that the contacts list was in, and select "Add Contact List". At this point I'm offered a choice of what kind of contact list to add. Since the installation of akonadi-googledata went smoothly, the first one on the list is "Akonadi Google Contacts Resource".

Clicking on this asks for my Google email and password, and after supplying that, all my GMail contacts download into the contact manager, as simple as that. Since my Android also uses my Google contacts, any changes I make in Kontact will show up on my phone automatically.

Configuring Akonadi - Calendars

Contacts were the easy part - now for the calendars. As with contacts, I start by switching over to the Calendar (not Kalendar, that would be silly) section of Kontact and delete the local calendar defaulted for me. Then I right-click in that now-empty pane and select "Add Calendar", which greets me with a similar Add window as before.

But this time, instead of selecting the Google Calendar Resource, we want the choice labelled "DAV groupware resource." This is a standards-based interface, and actually works better with Google Calendars than the other, more intuitive choice. But the setup isn't intuitive at all: the next dialog that pops up is a Logon Credentials window, which I have to Cancel to proceed. Yes.

Next is the configuration window for this new DAV groupware resource, which I'll show after I populate it with some stuff. The initial tasks are to choose a name (I chose "Google" because I'm very creative), and to click the Add button under Server configuration. Each Google calendar I want to see in Kontact is a line under the Server configuration section. I'll start with my personal one:

The Google instructions for DAV integration say to use the URL "https://www.google.com/calendar/dav/XXXX/events/", where XXXX is replaced by:

• your gmail address if this is your primary personal calendar, or
• a special identifier on the calendar settings page if this is a shared calendar

Once I put in this URL, and my gmail account and password again, I clicked Fetch and the stuff in the bottom list populated. I repeated this process for the shared McHouse calendar, and that resulted in this nice fully-populated DAV configuration window:

Click OK, and all my appointments download into the Calendar. It's a pretty light week, thankfully.

There's still a ton of look-and-feel setup to do, but the important part is that it all works and it's all integrated. The little customizations and tweaks can be done as I use the software.

Just three left!

PasswordSafe for secure password management

Moneydance for personal finance DONE!

ThinkOrSwim for option trading DONE!

Minecraft DONE!

Dropbox for cloud storage DONE!

Kontact for e-mail, contacts, and calendar DONE!

Choqok for micro-blogging (following and posting to Twitter) DONE!

NixNote for notes/personal organization

Okteta hex editor DONE!

Bacula for automated backups

Happy 1984

It's 1984 in the Year-a-Month project, and after trimming off the Ted Nugent and Deep Purple albums originally planned for this month, I'm left with the following:

Anthrax: Fistful of Metal - this is Anthrax's debut album, and has a different line-up than the rest of Anthrax's career, with Neil Turbin on vocals. I actually like Turbin's voice better than Joey Belladonna, his eventual long-term replacement. Most of this album sounds like a clone of Metallica's Kill 'Em All, except for an incongruous and IMHO terrible cover of Alice Cooper's "Eighteen".

Dio: The Last In Line - A year and a half ago I bought Holy Diver, and I've been waiting patiently for Year-a-Month to catch up with Dio's solo career. The time has finally come, and this album has more of the same power-metal stuff as in Holy Diver. It's nice to hear The Master's voice again.

Iron Maiden: Powerslave - I saw the album cover for this one, with its departure from the prominent Crypt Keeper-style depiction of Eddie The Head, and I was worried the music might have succumbed to the same Asia-style nonsense as the cover. It didn't. This album rocks along with the same galloping style that I've come to expect from Iron Maiden. And Eddie is actually there as the center pharaoh, if you look closely.

Judas Priest: Defenders of the Faith - The song Eat Me Alive on this album got Tipper Gore all hot and bothered, and she ranked it #3 on her "Filthy Fifteen". Oh Tipper, you're so cute. This is the only album that Amazon is charging me more to download than to have delivered, so I won't get to hear it for a few days.

Pantera: Projects in the Jungle - Sadly, this second album suffers from the same problems as last month's Metal Magic. It costs about twice what the other albums do, and it has a reputation of being more glam rock than metal. I didn't pick this one up.

Arch User Repository

See Time For a Change for the first in this series, or check out the index for all the posts on Arch Linux. Today I'll get the Arch User Repository working, which will let me configure my email, calendar, and contact integration.

Setting Up the Arch Build System
I briefly mentioned the Arch User Repository (AUR) during the Moneydance installation, and during that rollercoaster ride I actually used it in a failed attempt to get Moneydance working. Since it didn't pan out, I didn't include that as part of the post. But in order for Kontact to integrate with Google Calendar and Contacts, I will definitely need the AUR.

The Arch Way stipulates that everything should be kept as simple as possible - not for the user/administrator, but from a software dependency perspective - so only truly globally-useful software should make its way into the supported package repositories. That means that a great deal of very valuable software either doesn't have a wide enough target audience, or is too encumbered by pervasive library dependencies, or simply doesn't have the bullet-proof cross-platform support necessary to let it graduate into the big leagues. There is still a wide market for these packages, however, so the Arch team developed the Arch User Repository to hold the grab bag of all these fringe applications. This may sound a little Wild West - and it is - but consider the alternative that Windows users deal with every day. If you want something for Windows, you go find it online, download it, install it, and hope it works. It is a slightly different process for every application on your computer, which means that all the version management, update management, dependency checking, and distribution is multiplied by the number of applications on your hard drive. What a waste! By providing a central repository for stuff like this, Arch gives us a single place to look to see if anyone else has configured a given application and made it available.

To use the AUR, I needed to install and configure the Arch Build System. If you're trying to do this yourself, pay close attention to whether I'm giving root (#) or user ($) commands from here on. There are very good reasons not to use root unless absolutely necessary when working with the AUR.

# pacman -S abs
# abs
# abs

I ran abs twice because the first time after installation it sets up its own internal indexes but fails to download any updates. The second and every subsequent time it updates everything from the Arch Mothership. This is a lengthy process, so I went and made some coffee while I waited.

Using the AUR
Now that the ABS is set up, I can use it to get, build, and install the two Google-integration packages I will need in the next post. First, we have libgcal: this is a Google Calendar library that other applications can use to access Calendars. Second, we have akonadi-googledata, which gives Akonadi the ability to communicate with Google Information Servers. Akonadi is the KDE-wide framework that gives access to personal information like email, calendars, and contacts to applications written to use it. Tying everything together, akonadi-googledata uses libgcal to interact with Google Calendars. If this seems complicated and error-prone, then it's because you are a very perceptive reader. Most of my swearing and hair-pulling with KDE is caused by Akonadi.

There is an easier way to install packages from the AUR than manually using ABS, as I do below. This easier method, called yaourt (which stands for Yet AnOther User Repository Tool), itself must be set up via the ABS. Since the two packages I need for this step are so simple to do manually, there really isn't any reason to install yaourt to get this job done.

To get started, I made an abs subdirectory under my home directory, and downloaded libgcal and akonadi-googledata from the AUR into that subdirectory, extracting them there as well. The URLs below aren't magic; I just went to the AUR and searched for the packages, and then ran their URLs through bit.ly so they would fit on one line.

$ mkdir ~/abs ; cd ~/abs 
$ wget http://bit.ly/sJXtXi # libgcal
$ wget http://bit.ly/tZyrQz # akonadi-googledata
$ tar xf libgcal.tar.gz
$ tar xf akonadi-googledata.tar.gz

At this point, both packages are ready for building in ABS. Since akonadi-googledata depends on libgcal, I did libgcal first and akonadi-googledata second.

$ cd libgcal ; makepkg -si libgcal
$ cd ../akonadi-googledata ; makepkg -si akonadi-googledata

Makepkg is part of the ABS, and will read all the meta-files in the AUR tarball, downloading, compiling, and installing as necessary. With the -i flag, it creates a package that can be installed with pacman. With the -s flag, it goes ahead and automatically installs with pacman, asking for my password so it can sudo that operation. You should only use the -s flag if you know and trust the package. AUR packages are scripts and software, provided by other users, that you are using super-user privileges to install onto your system. In the unlikely event that there is malware in a package, you are giving it carte blanche on your computer. So be careful!

The commands above both output a tremendous amount of stuff, most of it very scary to non-developers. But they do their jobs, limiting their interaction with me to "what's your password" and "please confirm you want to do this", and a quick verify afterward yields good results:

# pacman -Q libgcal akonadi-googledata
libgcal 0.9.6-1
akonadi-googledata 1.2.0-1

Next: Configuring Kontact
Or check out the Index.