Thoughts on technology and mathematics

Taming the Trackpoint on the Toshiba Portege Z30t

The Accu Point on my Toshiba Z30t is utterly terrible. When the laptop is not resting on a completely flat surface (for example on my lap) the cursor keeps “drifting” across the screen. Apparently when the case is slightly bent, it invalidates the calibration and the driver can’t keep up with the changes. This is no Linux-only problem, I’m seeing it on Windows as well.

The problem

My first impulse was to simply disable the trackpoint. However, the mouse buttons next to the touchpad are also part of the trackpoint, so

xinput --disable 'AlpsPS/2 ALPS DualPoint Stick'

also disables the buttons.

The solution

While searching for a solution, I initially found:

xinput --set-prop 'AlpsPS/2 ALPS DualPoint Stick' 'Device Accel Constant Deceleration' '9999999999999999999'

By slowing down the mouse movements from the stick by a very larger factor, it effectively prevents the cursor from moving due to the trackpoint. This seems to work at first, but after a while I noticed, that two-finger-scrolling was broken. Every time the trackpoint changed the direction of its drift, the scrolling stopped. While it was not moving the cursor at all, it was still generating some kind of event. This was driving me crazy.

A few days ago I finally found the solution:

STICK='AlpsPS/2 ALPS DualPoint Stick'
xinput --set-prop "$STICK" 'Device Accel Constant Deceleration' "$LOTS"
xinput --set-prop "$STICK" 'Evdev Wheel Emulation' 1
xinput --set-prop "$STICK" 'Evdev Wheel Emulation Button' 0
xinput --set-prop "$STICK" 'Evdev Wheel Emulation Inertia' "$LOTS"

The addition lines tell the X server to convert all mouse movement from the trackpoint to scroll events, but only after the cursor has moved a lot of pixels. Which never happens, because we slowed down the movements so much.

I can finally use the touchpad without a constant desire to punch my laptop into submission. The Accu Point is of course effectively disabled, but it’s easy to toggle this using a hotkey if you really want to and you often use your device on a super-flat surface in order for that terrible peripheral to be actually usable at all.

Comments →

Running GitLab 8.0 Using Apache and Passenger

Update (7.10.2015) gitlab-git-http-server has switched from sending a custom User-Agent to sending a special header in version 0.9.14. User-Agent is now forwarded from the client request. I’ve updated the last section accordingly.

With the advent of GitLab 8.0 and gitlab-git-http-server, it became slightly more difficult to run it using Passenger. These are my notes on the caveats.

Install GitLab from Source

Just follow the official installation instructions, but skip installing the init script /etc/init.d/gitlab and the chapter about nginx.

Start sidekiq and gitlab-git-http-server

Because we are not using the official init scripts, we will have to make sure the services not provided by Passenger are running. If you use a systemd-based distro such as Debian jessie, you can find service files for both sidekiq and gitlab-git-http-server in the GitLab Recipes repository. Because Apache’s mod_proxy has some problems with unix domain sockets, you will have to modify the arguments for gitlab-git-http-server so it listens on a port (I will use 8181 in this guide). We will also use your main GitLab domain as authBackend, because GitLab is running inside Passenger and we don’t have a separate port to connect to (and we’ll make sure routing still works in the Apache config).

Here is my systemd service file for the gitlab-git-http-server:

Description=GitLab git-http-server

ExecStart=/home/git/gitlab-git-http-server/gitlab-git-http-server -listenAddr -authBackend /home/git/repositories


After you copied both service files to /etc/systemd/system, just enable and start them as usual:

$ systemctl enable gitlab-sidekiq.service
$ systemctl enable gitlab-githttpserver.service
$ systemctl start gitlab-sidekiq.service
$ systemctl start gitlab-githttpserver.service

Configure proxying for Apache

I’ll assume you already have Apache and Passenger running. In your usual vhost config, just set DocumentRoot "/home/git/gitlab/public/" and then add the following:

# Ensure that encoded slashes don't result in a 404 but are passed encoded
# to the app.
AllowEncodedSlashes NoDecode

# Don't rewrite the Host header. Needed to not confuse gitlab-git-http-server
# Also without this SNI will break, because gitlab-git-http-server reflects the
# Host header it receives back at us
ProxyPreserveHost on

# Allow reverse-proxying to gitlab-git-http-server
<Location />

# Forward access to git repos, but only from users, because
# gitlab-git-http-server queries gitlab for auth info like this
RewriteEngine on
RewriteCond "%{REQUEST_URI}" "^[-/\w\.]+\.git/"
RewriteCond "%{HTTP:GitLab-Git-HTTP-Server}" =""
RewriteRule .{REQUEST_URI} [P,QSA]

Make sure you are using version 0.2.14 of gitlab-git-http-server or newer for this to work. You can choose another port if 8181 is already taken, just remember to replace it in the systemd service file as well.

Security warning: When you run your GitLab installation like this, your upload folder is not routed through GitLab like it is with the default Nginx config. While all uploads still are still protected by the checksum of their content, anyone with the link can download the file, regardless of permissions. This also results in a risk of XSS (see this issue), but that assumes you have untrusted users on your installation.

Comments →

A New OpenPGP Key

It’s been more than 10 years since Wednesday, March 26, 2003 - the day my current OpenPGP key was created. Many things have happened since then, 1024bit DSA losing a lot of its trust margin being one of them. I am now retiring it in favor of a 4096 bit RSA key in the hope that 10 years from now it will still be considered secure.

Please see my formal transition statement for the details. It is signed by both of my keys and I would appreciate if you could sign the new key if you trusted the old key to ease the process.

Both keys are available through public key servers or you can download them here if you prefer.

Have a wonderful 2014 everyone!

Comments →

Secure Your Services Using Sane Cipher Ordering

For a while I’ve been enforcing encrypted connections for my servers wherever possible. However, I trusted the client software to make somewhat smart decisions about what ciphers they use. This is - as it turns out - at least currently not a good idea.

OpenSSL especially seems to have had a very weird default ordering for ciphers in older versions and a lot of software depends on this library, so often you end up using RC4 (a cipher whose biases have been known for a decade and whose use is discouraged) without ephemeral key exchange when both client and server could do a lot better.

One example for this is my mobile mail client, K9 Mail (using both the most current client and OS version available, K9 Mail 4.801, Android 4.4 KitKat): With the default postfix configuration it uses 128bit RC4-MD5 for sending mail, which is a terrible choice.

What cipher ordering is all about

In an SSL/TLS handshake both the client and the server will have a list of cipher suites they are willing to use. Normally, the server selects the first cipher from the client’s list it finds acceptable.

If you make an informed choice about which cipher suites you prefer however, it is probably more appropriate to use the first cipher from your list that the client also supports. This allows you to support weaker ciphers for broken client if needed, but use the best available cipher for everyone else.

Getting a cipher list you are comfortable with

You can find out about the ciphers your OpenSSL library supports by typing openssl ciphers -v ALL on the terminal. This will return a list like this:

ECDHE-RSA-AES256-SHA384       TLSv1.2 Kx=ECDH Au=RSA   Enc=AES(256)    Mac=SHA384

For each cipher suite this will tell you:

  • Which SSL/TLS version it applies to
  • the key exchange algorithm used
  • the authentication algorithm used
  • the encryption algorithm used and
  • the mac algorithms used.

Instead of ALL you can use any string that is valid as a cipher order spec in OpenSSL. This includes special classes of suites that are grouped together by the library itself, such as HIGH or EXPORT (for a full list, see man 1 ciphers). You should prefer using those classes over specifying the ciphers individually unless you are prepared to update your list whenever the library is updated to reflect the current state-of-the-art in cryptography research.

A good idea is to look at the default of the server software you are using and then add or remove (classes of) cipher suites until you’re comfortable with the resulting output of openssl ciphers. Always explicitly forbid anonymous cipher suites (ones that don’t use certificates and are therefore susceptible to man-in-the-middle attacks) using !aNULL and consider adding @STRENGTH at the end of your list, which will ask OpenSSL to sort the ciphers by key length.

Using your cipher order with server software


To use the server’s cipher preference order, set tls_preempt_cipherlist = yes.

Postfix has five internal lists of ciphers that the authors suggest should not be changed. Which of the lists is used, is determined by the configuration settings smtpd_tls_ciphers and smtpd_tls_mandatory_ciphers. The latter applies only when the encryption was mandatory for this connection, whereas the former will be used for opportunistic encryption. You have a choice between (from most to least secure) high, medium, low, export and null. Check the output of postconf -d for the parameters tls_high_cipherlist, tls_medium_cipherlist and so on to see which ciphers are in which list.

The default configuration uses medium, which allows RC4 among others, for mandatory encrypted connections and export, which includes ciphers that can only be considered scrambling such as 40bit DES. I decided to require strong ciphers for mandatory encryption and reasonable ciphers for everything else, so I ended up with the following:

tls_preempt_cipherlist      = yes
smtpd_tls_mandatory_ciphers = high
smtpd_tls_ciphers           = medium

smtp_tls_mandatory_ciphers  = $smtpd_tls_mandatory_ciphers
smtp_tls_ciphers            = $smtpd_tls_ciphers
lmtp_tls_mandatory_ciphers  = $smtpd_tls_mandatory_ciphers
lmtp_tls_ciphers            = $smtpd_tls_ciphers


Using the server’s cipher preference is a really recent addition to Dovecot. You will need at least version 2.2.6 (released on 2013-09-25) to use the option: ssl_prefer_server_ciphers = yes.

Using a restrictive list of ciphers is probably a good idea until this version has landed in your distribution. The default again allows the ciphers from the MEDIUM suite, including RC4. Unless one of your users insists on using ancient mail clients, this should be a good setting:

ssl_cipher_list = HIGH:!SSLv2:!aNULL@STRENGTH
# only enable on dovecot 2.2.6 and later:
#ssl_prefer_server_ciphers = yes


To force server preference, use SSLHonorCipherOrder on, the list of allowed ciphers is specified using SSLCipherSuite. Both settings can be found on Debian systems in /etc/apache2/mods-enabled/ssl.conf.

A possible configuration would look like this:

SSLHonorCipherOrder on

Please note that even though openssl ciphers may list ciphers using elliptic curve key exchange (ECDHE_*) these cannot be used with any Apache version prior to Apache 2.4. Also, even though RC4 is considered insecure and even Microsoft says you should disable it there might still be a small number of users who depend on it. If you want your website to be as compatible as possible, include the MEDIUM class ciphers in your list.


For prosody, you have to edit the ssl section of your configuration file. The server side ordering of ciphers is hidden in the options key. Note, that you have to include the defaults ("no_sslv2", "no_ticket", "no_compression" as of 0.9.1) or you will implicitly disable them.

A modified configuration could then include:

ssl = {
    options = { "no_sslv2", "no_ticket", "no_compression", "cipher_server_preference" };
    ciphers = "HIGH:!SSLv2:!aNULL@STRENGTH";

Update, 10.01.2014: Since version 0.9.2, prosody uses the server’s cipher preference and disables RC4 by default. So if you have prosody 0.9.2 or newer, please remove the custom ssl options and ciphers from your configuration. Hopefully, other software vendors will follow this example soon.

Comments →

Sympa and Proper Postfix Integration Howto

When we were moving from mailman to sympa to be able to have true multi-domain support, I was shocked how difficult (and poorly documented) it is to get sympa properly integrated with postfix. I wanted a system where:

  • mails to unknown recipients are rejected
  • lists can be created and deleted by users (no manual editing of aliases)
  • no patches to sympa or postfix are necessary.

For mailman, Debian ships with a setup that just works. For sympa, read on.

The problem

When you follow the sympa docs on postfix integration, you end up with a system that will accept all mails on the domain(s) sympa is expecting mails to arrive on. This makes it very difficult to have lists on the same domain as regular mailboxes, is a terrible practice because it leads to a lot of bounce-spam and may bring your server down if a spammer is guessing random emails from your domain.

The sympa FAQ contains an entry about this very problem, but the page is a mess and mostly outdated so it’s unfortunately not helpful. The following will rougly follow the howto from Folly Consulting, which you should read if you’re interested in an in-depth explanation of the problem and how postfix transports work. The code they use is not up-to-date however, redunant (they call postmap even though it’s unneccessary) and they patch files from sympa, which I wanted to avoid to make upgrades less painful.


My servers run Debian, so if you use sympa on a system that is not Debian-based you may have to change some paths. The following was confirmed to work on Debian 6 (squeeze) and Debian 7 (wheezy) and should work without modification for recent versions of Ubuntu and Mint (at least).

The setup

We will setup virtual transports for each of the six commands sympa uses and let them handle mail for corresponding virtual domains (sympalist, symparequest and so on). A modified is provided that is able to create a regexp-type alias file for postfix which maps incoming mail to those virtual domains. This setup means we do not need to call a binary after changes (such as the suid-root aliaswrapper provided by sympa or even postmap) as regexp files are re-read everytime smtpd starts. See the notes at the end for what this means for low-traffic mailservers.

Let’s get started!

The alias manager

Get the modified version of from Github and make it executable. Download list_aliases.ttf and place it in /etc/sympa. Or simply run:

cd /opt
git clone
cd sympa-postfix-virtual && sh
cd /etc/sympa && ln -s /opt/sympa-postfix-virtual/templates/list_aliases.tt2 .

The version of my version is based on is from sympa 6.12 and was last updated in svn revision 7542 on 07/30/2012. I tested it with both sympa versions 6.0 and 6.1. If you use a different version and encounter problems, it’s easy to review my changes.


Add the following options to your sympa.conf:

# use modified alias_manager with support for virtual aliases
alias_manager /opt/sympa-postfix-virtual/scripts/
# name of the alias file MUST end in "virtual"
sendmail_aliases /etc/sympa/sympa-alias.virtual

And create the alias file with the correct permissions:

umask 077
touch /etc/sympa/sympa-alias.virtual
chown sympa:sympa !!$

Finally, open sympa-alias.virtual in your favorite editor and add the following, replacing my.domain.tld and my\.domain\.tld with your domain name and the escaped version of your domain name, respectively.

# add a line like this for all domains sympa should receive mails on
# the right-hand content ("xxx") is ignored but necessary
/^my\.domain\.tld$/  xxx
# default contact emails
/^(postmaster|sympa-request|sympa-owner)\@.*$/  listmaster@my.domain.tld.
# sympa user interaction and VERP management
/^(sympa|listmaster)\@my\.domain\.tld$/         $1+my.domain.tld@sympalist.
/^(bounce\+.*|abuse-feedback-report)\@my\.domain\.tld$/ sympa+my.domain.tld@sympabounce.

Pay attention to the dots at the end of the lines, marking the destination domains fully-qualified.


For the postfix configuration, first create the virtual transports by adding this to

sympalist        unix  -       n       n       -       -       pipe
  flags=RF user=sympa argv=/usr/lib/sympa/bin/queue ${user}@${extension}
symparequest     unix  -       n       n       -       -       pipe
  flags=RF user=sympa argv=/usr/lib/sympa/bin/queue ${user}-request@${extension}
sympaeditor      unix  -       n       n       -       -       pipe
  flags=RF user=sympa argv=/usr/lib/sympa/bin/queue ${user}-editor@${extension}
sympasubscribe   unix  -       n       n       -       -       pipe
  flags=RF user=sympa argv=/usr/lib/sympa/bin/queue ${user}-subscribe@${extension}
sympaunsubscribe unix  -       n       n       -       -       pipe
  flags=RF user=sympa argv=/usr/lib/sympa/bin/queue ${user}-unsubscribe@${extension}
sympabounce      unix  -       n       n       -       -       pipe
  flags=RF user=sympa argv=/usr/lib/sympa/bin/bouncequeue ${user}@${extension}

Now, create transport_regexp with the following contents:

/^.*\@sympalist$/         sympalist:
/^.*\@symparequest$/      symparequest:
/^.*\@sympaeditor$/       sympaeditor:
/^.*\@sympasubscribe$/    sympasubscribe:
/^.*\@sympaunsubscribe$/  sympaunsubscribe:
/^.*\@sympaowner$/        sympabounce:

This file will tell postfix to actually use the transports for mail that is aliased to our virtual domains. Lastly, modify and declare the two files we have created:

virtual_alias_maps = regexp:/etc/sympa/sympa-alias.virtual
transport_maps     = regexp:/etc/postfix/transport_regexp
sympalist_destination_recipient_limit        = 1
symparequest_destination_recipient_limit     = 1
sympaeditor_destination_recipient_limit      = 1
sympasubscribe_destination_recipient_limit   = 1
sympaunsubscribe_destination_recipient_limit = 1
sympabounce_destination_recipient_limit      = 1

If you already have virtual_alias_maps or transport_maps in your config, you can list several values seperated by commas. Pay attention to the order of the maps though: First match wins.

Now, restart your services.

/etc/init.d/sympa reload
/etc/init.d/postfix reload

To test if everything worked, create a mailing list and then run /usr/sbin/sendmail -bv mylist@my.domain.tld. This will send a delivery report to the user account running the command (but not generate any real mail to the list). Ideally you should see something like this:

<mylist+my.domain.tld@sympalist> (expanded from
    <mylist@my.domain.tld>): delivery via sympalist: delivers to
    command: /usr/lib/sympa/bin/queue

Additional tweaking

A drawback of regexp-type maps is that they will be kept in memory for the lifetime of an smtpd process, so changes won’t be picked up immediately. If your mailserver is not very busy, it may take close to 3 hours (100*100s in the default configuration) before postfix notices a new list. So if you run a server that is idle a lot, you could consider adding some options to the smtp process in

smtp      inet  n       -       -       -       -       smtpd
   -o max_idle=30s
   -o max_use=20

With those values it will take at most 10 minutes before your maps are re-read.

Comments →