There are various presentations that state the goodness of PAV on Linux. Most revolve around using multipath-tools to assemble a volume if you don't have HyperPAV. But it turns out that the DASD device driver does multipathing for them internally in current kernels (which includes the squeeze kernel).

So all you need to do is setting those alias devices online. When you do that the kernel will log that it detected a new device, but you'll find that it won't create any dasd* device nodes for them, nor will it list partitions. lsdasd will only show you "alias" without mentioning the base volume, but you can fetch that information easily from the uid sysfs entry.

When George Papandreou announced its will to submit the European help program to the approbation of the Greek people, I don t know whether he wanted to scare people, but man, he really achieved something. From Wall Street to the Bundestag, through the lys e Palace, they are all in a state of advanced panic. There s a joke that s been circulating since: for next Hallowe en, disguise yourself as a referendum. Yes, these guys are afraid. Afraid of the people. They are afraid because it is now clear that their interests are not the same as the interests of the people. And what do you do when you are afraid? Well, you find yourself some way out, often by lying. And indeed, Mrs Merkel and Mr Sarkozy have been repeating over and over something that has been then repeated over and over by most so-called journalists: that Greeks can only choose between two endings:

1. they pay their debts to banks and rich people, and stay in the Euro zone;
2. they don t pay their debts to banks and rich people, and find themselves another currency.

That s it: Mrs Merkel and Mr Sarkozy are outrageous liars. There is another option for Greek people:

3. they don t pay their debts to banks and rich people, and they stay in the Euro zone.

It s as simple as that: nothing in European treaties can force a country to leave the Euro zone. And nothing in these treaties can force a country to honor their bonds. Greece is a sovereign state and, as such, can choose not to honor its sovereign debt. And choose to stay in the Euro zone: why would they want to go out? What does it have to do with the currency those bonds have been emitted in? If California were to cease payment of its public debt (something not likely to happen at all, hmm?), would it have to abandon the Dollar? But here is a thing that has been forbidden for a long time in European treaties: for a country to help financially another one to pay its debts. This rule was introduced by Jacques Delors (a man who knows what being European means) precisely in order to avoid the contagion we are facing currently because of stupid help plans all across Europe. Yes: the whole idea of Merkozy s grand plan to save Euro while helping Greece (a weird kind of help, starving people, really) is illegal. So in addition to being liars, Mrs Merkel and Mr Sarkozy are delinquents. So let Greece cease payment of its debt. A few banks will sink: so what? This will create less unemployment than letting our whole economy sink. European States will guarantee citizens savings up to 30 k , that s one of the other clever European rules (some countries guarantee more). Other people, rich people only, will lose their savings. Will that prevent you from sleeping? Not me. But that could prevent from sleeping a number of friends of Mrs Merkel s and Mr Sarkozy s. And wouldn t that be a good reason for lying and violating European treaties?

This story has been floating around for a week or so. The summary is that someone bought a system that has UEFI and is having trouble installing Linux on it. In itself, not a problem. But various people have either conflated this with the secure boot issue or suggested that UEFI is a fundamentally anti-Linux technology.

Right now there are no machines shipping to the public with secure boot enabled. None at all. If you're having problems installing Linux on a machine with UEFI then it's not because of secure boot. So what is actually causing the problem?

UEFI is a complicated specification, with 2.3.1A being 2214 pages long. It's a large body of code. There's a lot of subtleties. It's very easy for people to get things wrong. For example, we've seen issues where calling SetVirtualAddressMap() resulted in the firmware referencing boot services code, a clear violation of the spec on the firmware authors' part. We've also found machines that failed to boot because grub wasn't aligning its stack properly, a clear violation of the spec on our part.

Software is difficult. People make mistakes. When something mysteriously fails to work the immediate assumption should be that you've found a bug, not a conspiracy. Over time we'll find those bugs and fix them, but until then just treat UEFI boot failures like any other bug - annoying, but not malicious.

comments

See also parts 1, 2, and 3. I am a person that enjoys food that s different from what s at home, and Rhodes didn t disappoint. Terah and I used to live close to an excellent Greek restaurant in Indianapolis, so we were already familiar in some way with the food. But there isn t any Greek restaurant at all in the Wichita area, so we missed it. Our favorite restaurant on Rhodes was Kalypso of Lindos. Everything there was just excellent, starting with the saganaki, one of my favorite Greek appetizers. I had yogurt with honey there for dessert both times we visited, a surprisingly tasty desert. Like many restaurants in Lindos, Kalypso had the option of eating on the rooftop, or at ground level. We ate on the roof, which had a nice view of the Lindos Acropolis. Being outdoors, there were sometimes cats around. This kitten enjoyed playing games with my shoestrings for awhile. Kalypso is at a 17th century captain s house. Here s a view of it from the rooftop: We, of course, had the chance to eat at quite a few different places during our visit, and I d go on way too long if I mentioned them all. Terah particularly enjoyed the gelaterie.gr ice cream shop in the square in Rhodes. We liked our lunch at Maria s Taverna in Lindos and enjoyed chatting with the staff there. I recently talked about shopping in Mexico, and perhaps learned a thing or two from that. I won t say we never buy them, but in general we don t buy souvenirs like t-shirts, plastic things made in China, etc. We prefer to buy local. Those items tend to be higher quality, more interesting, and we like to support the local economy. We also don t have lots of room for things, so we try to choose carefully. So it was something of a surprise to Terah, and perhaps even to me, when I suggested we go shopping one day. Terah typically enjoys shopping a lot more than I do. Anyhow, off we went to Lindos. One of the first things that had caught our eye in Lindos was the shop selling glass. But it wasn t just any glass; it appeared to be made with some sort of layered process, and has a distinctly three-dimensional feel to it. As you move around, it looks like the background shifts. We wound up with this item, which was made in Athens: By the time we visited Lindos specifically for shopping, we had a good feel for when the busy times of day were, so we could avoid them. It gave us the opportunity to visit with people and when they weren t busy, many shopkeepers liked to chat. I enjoy hearing people s stories and we heard several. One ceramics shop the Musa Shop -caught Terah s eye. They had such incredible and beautiful pieces outside that we just had to go in. We wound up with two pieces from there, both in shades of blue: Both remind me of the Aegean Sea and the deep blue sky of Rhodes. And then, as we were walking along, I pointed inside a shop and said to Terah, Hey, those look different. We went in, and eventually wound up buying these: The appearance, and even feel, of them is unlike anything I d seen. Quite interesting. And seeing those particular items in the Lakis Place shop led to making some new friends I ll write about it in the next post.

In last weeks, I've finally managed to create my personal gallery, where I could present selection of my photographs. This task was outstanding on my todo list for pretty long time, the major obstacle being selecting photos which to present there. During my sickness few weeks ago, I finally went through most of my photos and chosen the ones which I think are worth presenting. Still I did not manage to go through photos from half year spent in Japan, so these will be added sometimes later. Also most of the pictures miss descriptions, though I'm (slowly) fixing this. From technical side, the gallery is being generated using lazygal with custom theme. You can check the gallery on photos.cihar.com, I hope you will like it :-).

Filed under: English Photography 1 comments Flattr this!

I thought it would have been easier to print a NUL-terminated string in awk (mawk as it's the default in Debian), but after some trial-and-fail I was able to come up with this kinda ugly solution:


$ echo -e "123\n456" awk 'BEGIN ORS="" print $0 ; printf("%c", "") ' xargs -n1 -0 echo
123
456

That:

• set the Output Records Separator (ORS) to the empty string (default is the \n, new line)
• print the input line (do your elaboration there, if you need)
• print the null character, as explained in the mawk manpage: "mawk cannot handle ascii NUL \0 in the source or data files. You can output NUL using printf with %c, and any other 8 bit character is acceptable input."
• show that it's actually emitting NUL-terminated strings

Just watched the whole Douglas Engelbart demo from 1968. Somehow I'd only heard of this as the first demo of the computer mouse, and only seen a brief clip on youtube. All three 30-minute reels of the film are available online, and well worth a watch in full. The mouse is the least of it, the demo includes an outlining text editor, model-view-controller, hypertext, wiki, domain specific programming languages, a precurser to email, bug tracking, version control(?), a chorded keyboard. (Ok, that last one didn't really take off.) Probably a dozen other things I've forgotten. All in a single interface, and all before I was born. Just like any tech demo, there are fumbles and mistakes, which is reassuring to anyone who has tried to give a tech demo. There's also the awesome crazy hack shown here. They could only afford these tiny, round CRTs, so they pointed a television camera at it, and the camera image was piped to their television console. (So add KVM switch to the list of firsts!) The demo was done in San Fransisco, with the computer system remote in Palo Alto, so in this image you see the text on the CRT overlaid with the video from the camera. Engelbart points out that the delay this added to the system acts as a short-term memory that filtered out flicker in the original display (and made the mouse have a mouse trail). To me it gives the whole demo a unique quality, as if it were underwater. Despite the piping around of audio and video signals, and the multiuser system, the glaring thing missing from the demo that we have these days is networking. Although there is this amusing bit at the end where they compile a regular expression and then apply it, in order to search for documents containing certain terms, and end up with a hyperlinked list of 10 results, ordered by relevance. Yes, think Google.

I care a lot about free network services. Recently, I have been given lots of reasons to be happy with the progress the free software community has made in developing services that live up to my standards. I have personally switched from a few proprietary network services to alternative systems that respect my autonomy and have been very happy both with the freedom I have gained and with the no-longer-rudimentary feature sets that the free tools offer. Although there is plenty left to do, here are four tools I'm using now instead of the proprietary tools that many people use, or that I used to use myself:

• StatusNet/identi.ca for microblogging (instead of Twitter): I have had my account since the almost the very beginning and am very happy with the improvements in the recent 1.0 rollout.
• Diaspora for social networking (instead of Facebook): Diaspora has made important strides forward recently and has become both quite usable and quite useful. Not having used Facebook, I've not managed to totally figure out where the system fits into my life, but I do periodically post updates that are more personal and less polished than the ones on my blog. I still have not set up my own pod but look forward to work that the Diaspora team is putting into making that process easier.
• NewsBlur for feed reading/sharing (instead of Google Reader): NewsBlur can be thought of as a replacement for Google Reader and is, in my opinion, much better even before one considers issues of autonomy. You can install the code yourself or pay the author a small amount to host it for you (he will do it for free if you are following under 64 feeds).
• Scuttle for social bookmarking (instead of Delicious): In the wake of Yahoo's sale and shutdown of Delicious, there is a renewed interest in free tools for social bookmarking. Scuttle, a rather mature project, seems to have been one of several beneficiaries. My Scuttle installation is at links.mako.cc.

In trying to switch away from proprietary services, I have found that there still a lack of good information comparing the different systems out there and giving folks advice on who might be able to help with things like setup or hosting. I really value hearing from other people about what they use and what they find useful but finding this information online still seems to be a struggle. The autonomo.us wiki seems like the natural place to host or summarize this discussion and to collect and share information useful for those of us slouching (or running) toward autonomy in our use of network services. I invite folks to get involved in improving that already useful resource. For example, this week, I spent a few hours researching free social bookmarking tools and produced a major update to the (already useful) social bookmarking page on the autonomo.us wiki. Of course, I can imagine lots of ways to improve that page and to collect similar information on other classes of network services. Please join me in that effort!

In August 2010, Sarah and I had a lovely (but short) week-long holiday in Rhodes, Greece. We thoroughly enjoyed it but I didn't document it here. When John Goerzen was looking for European holiday destinations earlier this year, I had no hesitation in recommending Rhodes. I am surprised and delighted that John took up my suggestion and loved it too! See John's holiday blogging for more on this beautiful place. This year we wanted to take a two-week holiday and have a similar experience again. We ended up choosing Kos, Greece. Kos was, perhaps not surprisingly, quite similar to Rhodes. We were based in "Hotel Oceanis" in Psalidi, on the north-east side, about ten minutes bus journey from Kos town. The hotel was very relaxing with plenty of space. It's based on the sea-side and has two public pools: the large main one and a smaller (but seemingly deeper) one adjacent to a snack bar. We were very lucky to find that the hotel had put is in a room with a private swimming pool! In total, we had four separate places to swim in the hotel. Kos town was similar to Rhodes town, but not quite as "historic" feeling. It was a bit larger/more spread-out. Some areas of the town are quite lively but we always managed to find pleasant and quiet places to eat and drink together. We had twice as much time and took advantage of that by hiring a car and visiting the rest of the island. In particular we loved the beach in Mastichari (middle-North), which had quite turbulent rolling waves. "Sunny beach" on the south coast was absolutely packed with holiday makers, but was none-the-less worth the look. All in all, my first two experiences of Greek islands were wonderful. One day, I'm sure we will return to (at least) Rhodes, but we may leave it for a while and see what the rest of the world has to offer in the mean time.

My son is being encouraged to lie. It's a fairly regular occurrence around here, and I'm sure you've seen it yourself. It's that checkbox on the website you're visiting where you say "Yes, I am over X years of age".

Whenever I want to login to a Debian porterbox to figure out some architecture-specific issue I typically do not care which particular host I am going to login to, just what architecture the host is. After discovering that it is not yet easy for the Debian sysadmins (DSA) to add aliases to DNS for this purpose, I whipped up a quick script to grab the relevant data about Debian machines from the Debian LDAP server and work around this in my OpenSSH config. To use the script you should run the script and place the magic comment lines suggested by the script into your ~/.ssh/config file and then run the script again, which will contact the Debian LDAP server using python-ldap, download the relevant information and replace the relevant part of your ~/.ssh/config file with some OpenSSH configuration directives to map Debian architecture names to hostnames. Within just a few seconds you will be able to login to armel, powerpc.port or kfreebsd-amd64.port.debian.org instead of needing to manually look up which servers to login for a particular architecture. Update: paravoid mentioned his dsa-porterbox script (see below) which is much simpler, does not need to modify your OpenSSH configuration and can be run as like ssh $(dsa-porterbox armel head -n1). I'm hoping we can add this and a possible ssh-porterbox to the devscripts package.

#!/bin/sh
test -z $1 && exit 1
exec ldapsearch -LLL -x -h db.debian.org -b ou=hosts,dc=debian,dc=org \
 "(&(purpose=porterbox)(architecture=$1))" hostname   \
 sed -n 's/^hostname: //p'

There are many system administration and configuration management tools available, I've mentioned them in the past and we're probably all familiar with our pet favourites. The "biggies" include CFEngine, Puppet, Chef, BFG2. The "minis" are largely in-house tools, or abuses of existing software such as fabric. My own personal solution manages my home network, and three dedicated servers I pay for in various ways. Currently I've been setting up some configuration "stuff" for a friend and I've elected to manage some of the setup with this system of my own, and I guess I need to decide what I'm going to do going forward. slaughter is well maintained, largely by virtue of not doing too much. The things it does are genuinely useful and entirely sufficient to handle a lot of the common tasks - and because the server-side requirement is a HTTP server, and the only client-side requirement is CRON it is trivial to deploy. In the past I've thought of three alternatives that would make it more complex:

• Stop using HTTP and have a mini-daemon to both serve and schedule.
• Stop using HTTP and use rsync instead.
• Rewrite it in Javascript. (Yes, really).

Each approaches have their appeal. I like the idea of only executing GPG-signed policies, and that would be trivial if there was a real server in place. It could also use SSL because that's all you need for security (ha!). On the other hand using rsync allows me to trivially implement the only missing primitive I actually miss at times - the ability to recursively download and install a remote directory tree. (I solve this problem by downloading a .tar file and unpacking it. Not good. Doesn't cope with template expansion and is fiddlier than I like). In the lifetime of the project I think I've had 20-50 feature requests or comments, which suggests it might actually be used by 50-100 people. (Ha! Optimism) In the meantime I'll keep a careful eye on the number of people who download the tarball & the binary packages... ObQuote: "I have vermin to kill. " - Kill Bill

[Latest version of these instructions can be found at the SFML Wiki] CMake allows your project to be built in various environments, including command-line make, Code::Blocks project files, Eclipse project files, etc. It's used in SFML 2.0. In this tutorial we'll write a simple CMake configuration file with centralized version numbering, and see how to integrate SFML in it. The source files First, create a cmake_modules directory and copy FindSFML.cmake in it. FindXXXX is automatically searched by CMake's find_package command. Then create a main.cpp, for instance:

#include "config.h"
#include <iostream>
#include <SFML/Window.hpp>
using namespace std;
int main(int argc, char* argv[])  
  cout << "Version " << myproject_VERSION_MAJOR << "." << myproject_VERSION_MINOR << endl;
  sf::Window screen(sf::VideoMode(800, 600), "myproject");
  bool running = true;
  while (running)  
    screen.Display();
   
 

We use a config.h file that is built by CMake, let's also create a config.h.in file:

#define myproject_VERSION_MAJOR @myproject_VERSION_MAJOR@
#define myproject_VERSION_MINOR @myproject_VERSION_MINOR@

And place your project license (such as the GNU GPL) in a file named COPYING. CMake configuration Let's describe our project configuration in the CMakeLists.txt file:

cmake_minimum_required(VERSION 2.6)
project(myproject)
# Set version information in a config.h file
set(myproject_VERSION_MAJOR 1)
set(myproject_VERSION_MINOR 0)
configure_file(
  "$ PROJECT_SOURCE_DIR /config.h.in"
  "$ PROJECT_BINARY_DIR /config.h"
  )
include_directories("$ PROJECT_BINARY_DIR ")
# Define sources and executable
set(EXECUTABLE_NAME "myproject")
add_executable($ EXECUTABLE_NAME  main.cpp)
# Detect and add SFML
set(CMAKE_MODULE_PATH "$ CMAKE_SOURCE_DIR /cmake_modules" $ CMAKE_MODULE_PATH )
find_package(SFML 1.6 REQUIRED system window graphics network audio)
target_link_libraries($ EXECUTABLE_NAME  $ SFML_LIBRARIES )
# Install target
install(TARGETS $ EXECUTABLE_NAME  DESTINATION bin)
# CPack packaging
include(InstallRequiredSystemLibraries)
set(CPACK_RESOURCE_FILE_LICENSE "$ CMAKE_SOURCE_DIR /COPYING")
set(CPACK_PACKAGE_VERSION_MAJOR "$ myproject_VERSION_MAJOR ")
set(CPACK_PACKAGE_VERSION_MINOR "$ myproject_VERSION_MINOR ")
include(CPack)

The interesting part is:

# Detect and add SFML
set(CMAKE_MODULE_PATH "$ CMAKE_SOURCE_DIR /cmake_modules" $ CMAKE_MODULE_PATH )
find_package(SFML 1.6 REQUIRED system window graphics network audio)
target_link_libraries($ EXECUTABLE_NAME  $ SFML_LIBRARIES )

• First we specify where we stored the FindSFML.cmake module.
• Then we request CMake to look for it in the system, and search for the specified modules (here I specified them all).
• Last, we tell CMake to link our executable with the SFML libraries that it just found.

Compilation To build with Make and the GCC compiler on the command-line:

cd build/  # a separate directory so we can easily remove all the CMake work files
cmake ..  # generate Makefile's
make

To create Code::Blocks project files:

cmake .. -G "CodeBlocks - Unix Makefiles"

and open project.cbp with Code::Blocks. Installation CMake supports the classic:

make install

It also supports DESTDIR, useful in packaging:

make install DESTDIR= pwd /myworkdir

You can also define CMAKE_INSTALL_PREFIX when invoking cmake to change the default install path (/usr/local under Unix). DESTDIR would still override this setting. Packaging You then can use cpack to make a project release:

# Binary package:
cpack -C CPackConfig.cmake
# Source package:
cpack -C CPackSourceConfig.cmake

You will get a nice myproject-1.0.tar.gz, among others. Further information

• CMake has built-in help, for instance:

$ cmake --help-variable CMAKE_SOURCE_DIR
cmake version 2.8.5
  CMAKE_SOURCE_DIR
       The path to the top level of the source tree.
       This is the full path to the top level of the current CMake source
       tree.  For an in-source build, this would be the same as
       CMAKE_BINARY_DIR.

• Reference for v2.8
• CMake Tutorial

Some days ago, a hacker group, THC, released a denial of service tool for SSL web servers. As stated in its description, the problem is not really new: a complete SSL handshake implies costly cryptographic computations. There are two different aspects in the presented attack:

• The computation cost of an handshake is more important on the server side than on the client side. The advisory explains that a server will require 15 times the processing power of a client. This means a single average workstation could challenge a multi-core high-end server.
• The use of SSL renegotiation allows to trigger hundreds of handshakes in the same TCP connection. Even a client behind a DSL connection can therefore bomb a server with a lot of renegotiation requests.

Mitigation techniques There is no definitive solution to this attack but there exists some workarounds. Since the DoS tool from THC relies heavily on renegotiation, the most obvious one is to disable this mechanism on the server side but we will explore other possibilities.

Disabling SSL renegotiation Tackling the second problem seems easy: just disable SSL renegotiation. It is hardly needed: a server can trigger a renegotiation to ask a client to present a certificate but a client usually does not have any reason to trigger one. Because of a past vulnerability in SSL renegotiation, recent version of Apache and nginx just forbid it, even when the non-vulnerable version is available. openssl s_client can be used to test if SSL renegotiation is really disabled. Sending R on an empty line trigger renegotiation. Here is an example where renegotiation is disabled (despite being advertised as supported):

$ openssl s_client -connect www.luffy.cx:443 -tls1
[...]
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: zlib compression
Expansion: zlib compression
[...]
R
RENEGOTIATING
140675659794088:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:591:

Disabling renegotation is not trivial with OpenSSL. As an example, I have pushed a patch to disable renegotiation in stud, the scalable TLS unwrapping daemon.

Rate limiting SSL handshakes Disabling SSL renegotiation on the client side is not always possible. For example, your web server may be too old to propose such an option. Since those renegotiations should not happen often, a workaround is to limit them. When the flaw was first advertised, F5 Networks provided a way to configure such a limitation with an iRule on their load-balancers. We can do something similar with just Netfilter. We can spot most TCP packets triggering such a renegotiation by looking for encrypted TLS handshake record. They may happen in a regular handshake but in this case, they usually are not at the beginning of the TCP payload. There is no field saying if a TLS record is encrypted or not (TLS is stateful for this purpose). Therefore, we have to use some heuristics. If the handshake type is unknown, we assume that this is an encrypted record. Moreover, renegotiation requests are usually encapsulated in a TCP packet flagged with push .

# Access to TCP payload (if not fragmented)
payload="0 >> 22 & 0x3C @ 12 >> 26 & 0x3C @"
iptables -A LIMIT_RENEGOCIATION \
    -p tcp --dport 443 \
    --tcp-flags SYN,FIN,RST,PSH PSH \
    -m u32 \
    --u32 "$payload 0 >> 8 = 0x160300:0x160303 && $payload 2 & 0xFF = 3:10,17:19,21:255" \
    -m hashlimit \
    --hashlimit-above 5/minute --hashlimit-burst 3 \
    --hashlimit-mode srcip --hashlimit-name ssl-reneg \
    -j DROP

The use of u32 match is a bit difficult to read. The manual page gives some insightful examples. $payload allows to seek for the TCP payload. It only works if there is no fragmentation. Then, we check if we have a handshake (0x16) and if we recognise TLS version (0x0300, 0x0301, 0x0302 or 0x0303). At least, we check if the handshake type is not a known value. There is a risk of false positives but since we use hashlimit, we should be safe. This is not a bullet proof solution: TCP fragmentation would allow an attacker to evade detection. Another equivalent solution would be to use CONNMARK to record the fact the initial handshake has been done and forbid any subsequent handshakes. If you happen to disable SSL renegociation, you can still use some Netfilter rule to limit the number of SSL handshakes by limiting the number of TCP connections from one IP:

iptables -A LIMIT_SSL \
    -p tcp --dport 443 \
    --syn -m state --state NEW \
    -m hashlimit \
    --hashlimit-above 120/minute --hashlimit-burst 20 \
    --hashlimit-mode srcip --hashlimit-name ssl-conn \
    -j DROP

Your servers will still be vulnerable to a large botnet but if there is only a handful of source IP, this rule will work just fine¹. I have made all those solutions available in a single file.

Increasing server-side power processing SSL can easily be scaled up and out. Since SSL performance increases linearly with the number of cores, scaling up can be done by throwing in more CPU or more cores per CPU. Adding expensive SSL accelerators would also do the trick. Scaling out is also relatively easy but you should care about SSL session resume.

Putting more work on the client side In their presentation of the denial of service tool, THC explains:

Establishing a secure SSL connection requires 15 more processing power on the server than on the client.

I don t know where this figure comes from. To check it, I built a small tool to measure CPU time of a client and a server doing 1000 handshakes with various parameters (cipher suites and key sizes). The results are summarized on the following plot: For example, with 2048bit RSA certificates and a cipher suite like AES256-SHA, the server needs 6 times more CPU power than the client. However, if we use DHE-RSA-AES256-SHA instead, the server needs 34% less CPU power. The most efficient cipher suite from the server point of view seems to be something like DHE-DSS-AES256-SHA where the server needs half the power of the client. However, you can t really uses those shiny cipher suites:

1. Some browsers do not support them: they are limited to RSA cipher suites².
2. Using them will increase your regular load a lot. Your servers may collapse with just legitimate traffic.
3. They are expensive for some mobile clients: they need more memory, more processing power and will drain battery faster.

Let s dig a bit more on why the server needs more computational power in the case of RSA. Here is a SSL handshake when using a cipher suite like AES256-SHA: When sending the Client Key Exchange message, the client will encrypt TLS version and 46 random bytes with the public key of the certificate sent by the server in its Certificate message. The server will have to decrypt this message with her private key. Those are the two most expensive operations in the handshake. Encryption and decryption are done with RSA (because of the selected cipher suite). To understand why decryption is more expensive than encryption, let me explain how RSA works. First, the server needs a public and a private key. Here are the main steps to generate them:

1. Pick two random distinct prime numbers p and q , each roughly the same size.
2. Compute n=pq . It is the modulus.
3. Compute \varphi(n)=(p-1)(q-1) .
4. Choose an integer e such that 1<e<\varphi(n) and \gcd(\varphi(n),e) = 1 (i.e. e and \varphi(n) are coprime). It is the public exponent.
5. Compute d=e^ -1 \mod\varphi(n) . It is the private key exponent.

The public key is (n,e) while the private key is (n,d) . A message to be encrypted is first turned into an integer m<n (with some appropriate padding). It is then encrypted to a ciphered message c with the public key and should only be decrypted with the private key:

• c=m^e\mod n (encryption)
• m=c^d\mod n (decryption)

So, why is decryption more expensive? In fact, the key pair is not really generated like I said above. Usually, e is a small fixed prime number with a lot of 0, like 17 (0x11) or 65537 (0x10001) and p and q are choosen such that \varphi(n) is coprime with e . This allows encryption to be fast using exponentiation by squaring. On the other hand, its inverse d is a big number with no special property and therefore, exponentiation is more costly and slow. Instead of computing d from e , it is possible to choose d and compute e . We could choose d to be small and coprime with \varphi(n) and then compute e=d^ -1 \mod\varphi(n) and get blazingly fast decryption. Unfortunately, there are two problems with this:

• Most SSL implementation expects e to be a 32bit integer.
• If d is too small (less than one-quarter as many bits as the modulus n ), it can be computed efficiently from the public key.

Therefore, we cannot use a small private exponent. The best we can do is to choose the public exponent to be e =4294967291 (the biggest prime 32bit number and it contains only one 0). However, there is no change as you can see on our comparative plot. To summarize, no real solution here. You need to allow RSA cipher suites and there is no way to improve the computational ratio between the server and the client with such a cipher suite.

Things get worse Shortly after the release the denial of service tool, Eric Rescorla³ published a good analysis on the impact of such a tool. He asks himself about the efficiency to use renegotiation for such an attack:

What you should be asking at this point is whether a computational DoS attack based on renegotiation is any better for the attacker than a computational DoS attack based on multiple connections. The way we measure this is by the ratio of the work the attacker has to do to the work that the server has to do. I ve never seen any actual measurements here (and the THC guys don t present any), but some back of the envelope calculations suggest that the difference is small. If I want to mount the old, multiple connection attack, I need to incur the following costs:

1. Do the TCP handshake (3 packets)
2. Send the SSL/TLS ClientHello (1 packet). This can be a canned message.
3. Send the SSL/TLS ClientKeyExchange, ChangeCipherSpec, Finished messages (1 packet). These can also be canned.

Note that I don t need to parse any SSL/TLS messages from the server, and I don t need to do any cryptography. I m just going to send the server junk anyway, so I can (for instance) send the same bogus ClientKeyExchange and Finished every time. The server can t find out that they are bogus until it s done the expensive part. So, roughly speaking, this attack consists of sending a bunch of canned packets in order to force the server to do one RSA decryption.

I have written a quick proof of concept of such a tool. To avoid any abuse, it will only work if the server supports NULL-MD5 cipher suite. No sane server in the wild will support such a cipher. You need to configure your web server to support it before using this tool. While Eric explains that there is no need to parse any SSL/TLS messages, I have found that if the key exchange message is sent before the server send the answer, the connection will be aborted. Therefore, I quickly parse the server s answer to check if I can continue. Eric also says a bogus key exchange message can be sent since the server will have to decrypt it before discovering it is bogus. I have choosen to build a valid key exchange message during the first handshake (using the certificate presented by the server) and replay it on subsequent handshakes because I think the server may dismiss the message before the computation is complete (for example, if the size does not match the size of the certificate). With such a tool and 2048bit RSA certificate, a server is using 100 times more processing power than the client. Unfortunately, this means that most solutions, except rate limiting, exposed on this page may just be ineffective.

---

1. However, since this rule relies on source IP to identify the attacker, the risk of false positive is real. You can slow down legitimate proxies, networks NATed behind a single IP, mobile users sharing an IP address or people behind a CGN.
2. Cipher suites supported by all browsers are RC4-MD5, RC4-SHA and 3DES-SHA. Support for DHE-DSS-AES256-SHA requires TLS 1.2 (not supported by any browser).
3. Eric is one of the author of several RFC related to TLS. He knows his stuff.

As you will know, every file on a unixoid system has some meta-data like owner, group and permission bits. This is of course also true for files part of some Debian package. And it is not very surprising that different files should have different permissions. Or even different owners or groups. Which file has which settings is of course for the package maintainer to decide and Debian would not be Debian if there were not ways for the user to give their own preferences and have them preserved. This post is thus about how those settings end up in the package and what is to be observed when doing it. As you will also have heard, a .deb file is simply a tar archive stored as part of an ar archive, as you can verify by unpacking a package manually:

$ ar t reprepro_4.8.1-1_amd64.deb
debian-binary
control.tar.gz
data.tar.gz
$ ar p reprepro_4.8.1-1_amd64.deb data.tar.gz   gunzip   tar -tvvf -
drwxr-xr-x root/root         0 2011-10-10 12:05 ./
drwxr-xr-x root/root         0 2011-10-10 12:05 ./etc/
drwxr-xr-x root/root         0 2011-10-10 12:05 ./etc/bash_completion.d/
-rw-r--r-- root/root     19823 2011-10-10 12:05 ./etc/bash_completion.d/reprepro
drwxr-xr-x root/root         0 2011-10-10 12:05 ./usr/
drwxr-xr-x root/root         0 2011-10-10 12:05 ./usr/share/
--More--

(For unpacking stuff from scripts, you should of course use dpkg-deb --fsys-tarfile instead of ar gunzip. Above example is about the format, not a recipe to unpack files). This already explains how the information is usually encoded in the package: A tar file contains that information for each contained file and dpkg is simply using that information. (As tar stores numeric owner and group information, that limits group and owner information to users and groups with fixed numbers, i.e. 0-99. Other cases will be covered later.) The question for the maintainer is now: Where is the information which file has which owner/group/permissions in the .tar inside the .deb, and the answer is simple: It's taken from the files to be put into the .deb. This means that package tools could simply be implemented first by simply calling tar and there is no imminent need to write you own tar generator. It also means that the maintainer has full control and does not have to learn new descriptive languages or tools to change permissions, but can simply put the usually shell commands into debian/rules. There are some disadvantages, though: A normal user cannot change ownership of files and one has to make sure all files have proper permissions and owners. This means that dpkg-deb -b (or the usually used wrapper dh_builddeb) must be run in some context where you could change the file ownership to root first. This means you either need to be root, or at least to fake being root by using fakeroot. (While this could be considered some ugly workaround, it also means upstream's make install is run believing to be root, which also avoids some -- for a packager -- quite annoying automatisms in upstream build scripts assuming a package is not installed system wide if not installed as root). Another problem are random build host characteristics changing how files are created in the directory later given to dpkg-deb -b. For example an umask which might make all files non-world-readable by default. The usual workaround is to first fix up all those permissions. Most packages use dh_fixperms for this, which also sets executable bits according to some simple rules and has some more special cases so that the overall majority of packages does not need to look at permissions at all. So using some debhelper setup, every special permissions and all owner/group information for owner groups with fixed numbers only needs to be set using the normal command line tools between dh_fixperms and dh_builddeb. Everything else happens automatically. Note that games is a group with fixed gid. So it is not necessary (and usually a bug) to change group-ownership of files withing the package to group games in maintainer scripts (postinst,...). If a user wants to change permissions or ownership of a file, dpkg allows this using the dpkg-statoverride command. This command essentially manages a list of files to get special treatment and ownership and permission information they should get. This way a user can specify that files should have different permissions and this setting is applied if a new version of this file is installed by dpkg. Being a user setting especially means, that packages (that means their maintainer scripts) should not usually use dpkg-statoverride. There are two exceptions, though: Different permissions based on interaction with the user (e.g. asking question with debconf) and dynamically allocated users/groups with dynamic id. In both cases one should note that settings to dpkg-statoverride are settings of the user, so the same care should be given as to files in /etc, especially one should never override something the user has set in there. (I can think of no example where calling dpkg-statoverride --add without dpkg-statoverride --list in some maintainer script is not a serious bug: Either you override user settings or you are using debconf as a registry. Moral To recap, your package is doing something wrong if:

• Your maintainer scripts unconditionally change permissions of files within the package (Those should either be set within the package or you miss user configuration in dpkg-statoverride).
• Your maintainer scripts call dpkg-statoverride --add without having checked first whether the user already has done so with different values.

Translation server for phpMyAdmin and Gammu/Wammu has been updated to run latest Pootle. I had to do this upgrade to be able to run on latest Django, which is used by other websites as well (this blog is one of them). Unfortunately it was not as easy as running apt-get upgrade as Pootle package has been dropped from Debian recently. So I had to make quick and dirty packages myself (no removal of embedded software and so on). Installing newer version lead to major breakage as the database upgrade silently failed and I had to recover manually. In the end I've dropped all pootle_* tables and recreated them again. Unfortunately this lead to loss of some data from user profiles, but I could not see other way around. Anyway the service should be now back running in normal shape, so go ahead and translate :-).

Filed under: Debian English Phpmyadmin 0 comments Flattr this!

Many people around me switched to Chrome or Chromium. I also used it for a bit, but I was a bit disappointed about the extensions available. To show why, here's a list of the extensions I've currently installed:

• Adblock Plus: I guess everyone knows this. It sits quitely in the background and removes quite a bunch of eye-distracting stuff from web pages. You see the web differently and are always confused when viewing pages on your smartphone.
• British English Dictionary: Pretty self-explaining. Firefox has an integrated spell checker and that one needs a dictionary.
• BugMeNot: You can right-click on a login field and let it insert BugMeNot data automatically. I don't use it often enough to remember that it's there.
• Certificate Patrol: SSL's X.509 trust model is weak, to say the least. This extension implements the "save on first visit" trust model and warns you if the certificate or the CA of a URL changes.
• Download Statusbar: If you're used from, say, Chromium to see your download progress above the status bar, this extension will give you that. I don't like the separate window, especially with Awesome as my window manager.
• Firebug: Most people know this, too. Very useful when you do web development. You can see the effects of CSS as you type, for instance.
• Flashblock: YouTube has its HTML5 trial, so you don't need Flash for it. Sadly I had to give in recently (for live streaming sites like the German Parliament, go figure) and have it installed for "emergency" cases. But really nobody needs Flash advertisements or other silly Flash animations, so Flashblock will conveniently refuse to load the Flash plugin unless you tell it to.
• German Dictionary: As above.
• Google Translator for Firefox: Translates marked sections on a web page in place. It lets Google guess the source language, so you really only mark the area, click the button and be done.
• Greasemonkey: Modifies web pages in place to make them more sane, using little scripts. I use two currently:
• Better Outlook Web Access (OWA): For odd reasons I'm forced to use OWA 2007 at a company of Windows and Mac users. This makes it a little bit more bearable, by allowing you to save your password and by adding a message preview pane. You really don't want to use OWA Light 2007 without this.
• Tagesschau.de - video tag: A simple script that lets you watch videos on tagesschau.de without resorting to Flash. They ship Theora videos alongside H.264, which is supported by Firefox out of the box.
• Lazarus: Form Recovery: This already saved me many, many times. Sometimes I hit the stupid Thinkpad page back/page forward keys, or the browser crashes or I'm torn away from a page in another way. This extension keeps your form content mostly save, so that you don't need to start from scratch. A must have.
• Live HTTP headers: curl -D usually works. But sometimes you need authentication and cookies and stuff, hence doing it in the browser makes sort of sense.
• Modify Headers: I don't really use it anymore. There was this legend that YouTube lets you watch videos that are blocked in your country (Hello, GEMA, I'm looking at you!) if you provide a X-Forwarded-For header with an IP from another country. Never worked for me.
• Mozilla Archive Format: If you need to archive a web page or want to collect a bunch of pages for offline reading, this is the way to go. You can conveniently select either single pages or several tabs to be stored.
• Perspectives: I'm paranoid, so here's the second SSL certificate check. Perspectives uses a bunch of network notaries hosted on PlanetLab to check if everyone sees the same certificate. Together with Certificate Patrol that means if that you save a self-signed certificate on first visit if the notaries all agree that it's the currently installed one.
• PwdHash: Password re-use on different web sites is bad. There are sites where I'm not very concerned about the strength of my password, but where I don't want to leak my main ones. PwdHash uses the domain name and the password I give as components to a hash function. So if I'm at a computer without access to my saved passwords, I can easily reconstruct the hash. If need be, I can use the JavaScript on the developer's web site to do that.
• RequestPolicy: It's currently installed but I don't think it will stick around much longer. Too many sites are using embedded cross-site requests, which this extension will allow you to review. As an example every Blogger site that's on a custom domain (like my blog) will trigger it. Instead half of your web will have red flags everywhere full of blocked requests. Not that helpful. Interestingly enough it also polices Flash's outgoing web requests. Which breaks even more often than normal web pages.
• Secure Login: This gives you a button (or a keyboard shortcut) that allows you to choose from several logins and then goes on and posts those credentials securely to the page in question, bypassing any JavaScript that might want to see them. You also get auto-login bookmarks for those sites which don't allow you to remain logged-in across browser sessions. (Like OWA.)

If Firefox on Android were quicker to start and faster overall, I might even use it there. But as-is it's not very useful. Sadly this also means that I can't use Firefox Sync on my phone and as I don't use Chrome on my desktop I also can't use Chrome to Phone. So I usually go and build a QR code on my laptop and read that with Android's Barcode Scanner.

Of course I'm actually using Iceweasel and I'm very grateful for Mike Hommey's efforts to track the release channel on mozilla.debian.net.

Content Security Policy is a proposed HTTP extension which allows websites to restrict the external content that can be displayed by visiting web browsers. By expressing a set of rules to be enforced by the browser, a website is able to prevent the injection of outside resources by malicious users.

While adding support for the March 2011 draft in Libravatar, I looked at three different approaches.

Controlling the headers in the applicationThe first approach I considered was to have the Django application output all of the headers, which is what the django-csp module does. Unfortunately, I need to be able to vary the policy between pages (the views in Libravatar have different requirements) and that's one of the things that hasn't been implemented yet in that module.

Producing the same headers by hand is fairly simple:

response = render_to_response('app/view.html')
response['X-Content-Security-Policy'] = "allow 'self'"
return response

but it would mean adding a bit of code to every view and/or writing a custom wrapper for render_to_response().

Setting a default header in ApacheIdeally, I'd like to be able to set a default header in Apache using mod_headers and then override it as needed inside the application.

The first problem with this solution is that it's not possible (as far I can tell) for a Django application to override a header set by Apache:

• mod_headers adds its response header after mod_wsgi has returned (unless early processing is used).
• Django's response objects cannot see the early headers set by Apache.

The second problem is that mod_headers doesn't have an action that adds/sets a header only if it didn't already exist. It does have append and merge actions which could in theory be used to add extra terms to the policy but it unfortunately uses a different separator (the comma) from the CSP spec (which uses semi-colons).

Always set headers in ApacheWhile I would have liked to get the second approach working, in the end, I included all of the CSP directives within the main Apache config file:

Header set X-Content-Security-Policy: "allow 'self'; options inline-script; img-src 'self' data:"

<Location /account/confirm_email>
  Header set X-Content-Security-Policy: "allow 'self'; options inline-script; img-src *"
</Location>

<Location /tools/check>
  Header set X-Content-Security-Policy: "allow 'self'; options inline-script; img-src *"
</Location>

The first Header call sets a default policy which is later overriden based on the path to the Django view that's being used.

Related technologiesIf you are interested in Content Security Policy, you may also want to look into Application Boundaries Enforcer (part of the NoScript Firefox extension) for more security rules that can be supplied by the server and enforced client-side.

It's also worth mentioning the excellent Request Policy extension which solves the same problem by letting users whitelist the cross-site requests they want to allow.

This is my monthly summary of my Debian related activities. If you re among the people who made a donation to support my work (130.30 , thanks everybody!), then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. Dpkg work The month started with fixing newly reported bugs to prepare the 1.16.1.1 release:

• #644492: there was a flaw in a change I made to the trigger setup code. This resulted in packages being incorrectly marked as configured while they were only unpacked in a new chroot.
• #642656: dpkg-source s refusal to build when it detects unrecorded changes broke the (mostly unused, except by the lintian test suite apparently) 2.0 source format.
• #644412: the Makefile snippet buildflags.mk did not respect the new maintainer specific environment variables (like DEB_CFLAGS_MAINT_APPEND) because make does not forward environment variable through $(shell ). Fixed that by manually exporting the required variables.
• I also disabled dpkg-buildpackage s output of the build flags since it was confusing several maintainers. dpkg-buildpackage invokes debian/rules and it has no (clean) way to discover the build flags changes that maintainer request by setting the dedicated environment variables in debian/rules. Maintainers expect to see the build flags with the modifications they have requested and not just the default values set by the distribution.

With the help of Guillem, we decided on a proper fix for a race condition sometimes triggered by parallel builds when 2 concurrent dpkg-gencontrol try to update debian/files (see #642608). This ended up requiring a new package (libfile-fcntllock-perl) that the Debian perl team kindly packaged for us. With all this sorted, it was a rather easy fix. Multiarch progress I also spent lots of time on multiarch. I fixed an old bug that requested to support the multi-arch paths in case of cross-building (see #595144), the discussion was not really conclusive on which of the two proposed patches was better so I ended up picking my own patch because it was closer to how we currently deal with cross-building. Then I fixed 2 issues that have been reported on Ubuntu s dpkg. The first one (LP #863675) was rather severe since an installed package ended being disappeared in favor of its foreign counterpart that was removed (but that had some config files left). The second one (LP #853679) only affected dselect users (apparently there are still some!) who had a self-conflicting library (Provides: foo, Conflicts: foo) installed for multiple architectures. But the bulk of the time spent on multiarch has been spent discussing with various parties on how to go forward with multiarch. The release team commented on the schedule of the merge to ensure it makes it into Wheezy, and the Debian project leader also commented on the problems encountered so far. While not the best course of action I could have hoped for, it certainly helped since Guillem started pushing some reviewed commits. Out of the 66 commits that were in my pu/multiarch/full branch one week ago, 20 have been merged in the master branch already. Python-django security update and RC bug Since python-django s maintainer did not manage to prepare the required security updates, I stepped in and prepared version 1.2.3-3+squeeze2 for Squeeze and 1.0.2-1+lenny3 for Lenny. Unfortunately this security update is an example of how an inactive maintainer is likely to result in a severe delay for the release of security updates. Furthermore in this specific case, the security team did not want to release the Squeeze security update until the Lenny one had been investigated (which required some time since upstream no longer supports the version in Lenny) but they did not make this very clear. Later another release critical bug had been filed against the package (#646634) but after investigation, it turned out to be a local configuration problem so I downgraded it. I still forwarded the test suite failure to upstream authors since the test could be enhanced. In any case, co-maintainers for python-django are welcome. I really preferred the situation where I can quietly sit down as backup maintainer WordPress packaging WordPress sounds similar to python-django. I m also only a backup maintainer but Giuseppe has been inactive for many months and I had to step in August because I wanted the new upstream version. I discovered a bit late that I was not subscribed to wordpress bugs and thus the release critical bug #639733 (that I introduced with my new upstream version) went unattended for a rather long time. Once aware, though, I quickly fixed it. I also took the opportunity to start a discussion on debian-devel about how to deal with embedded javascript libraries and proposed a mechanism of opportunistic replacement with symlinks . WordPress is my testbed package for this mechanism, you can check out its debian/dh_linktree that implements the replacement logic. The discussion has not been very interesting but at least I learned that Debian now requires that each source package shipping minified javascript files includes the original files too. It s somewhat of a pain since it s not a license requirement in many cases (many of those libraries are not under the GPL), but just a Debian requirement that many upstreams are not complying with. WordPress is affected and Jakub Wilk thus opened #646729 which is going to be a long-standing RC bug. To give good measures, I spent several hours investigating the case of each javascript file in the WordPress source package and I filed a new ticket on the upstream bugtracker. Dropbox packaging work A few months after the introduction of nautilus-dropbox to Debian and Ubuntu, I can say that the decision to only support the download of dropbox in the postinst has been a mistake. Because of this decision I had to make the postinst fail if the download failed. Even if the error message is relatively clear, this lead to many (mostly automated) bug reports on the Ubuntu side. Various other problems cropped up on top of this (trying to start dropbox while the package was not configured would result in an error because the user did not have the required rights to install the software, reinstalling the package while dropbox was running would result in a failure too, etc.). I have fixed all those issues in the version 0.7.0-2 of the package. Now if the user has to install dropbox, it will use PolicyKit to request the root rights. The postinst will no longer fail if the dropbox download fails since it can be run later by the user. And I fixed the download code to remove the replaced file before unpacking a new file (insead of overwriting the existing file). All this work has been forwarded upstream. The Debian Administrator s Handbook Update I m glad to tell you that the translation will happen because we reached the minimal funding goal on October 22th with the help of 380 supporters. Now the fundraising continues, but this time the goal is the liberation of the resulting book. For this to happen, we need to reach 25000 EUR in the liberation fund. So far we re at 37% of this goal with 9400 EUR in the liberation fund (which means that 59% of the money raised has been put in the liberation fund).

Click here if you want to contribute towards the liberation of this book. With (less than) 27 days left, it s going to be a challenge to meet the goal, but we do like challenges, don t we? Misc work

• I filed #644486 against dh-make so that new packages have proper support of dpkg-buildflags from the start.
• I merged lots of patches from Luca Falavigna in the developers-reference.
• I discussed debtags integration in the PTS with Enrico Zini and Paul Wise.
• I updated publican s packaging for the new upstream version 2.8. I had to write a new patch that I forwarded upstream.
• I filed an upstream bug on hamster-applet because just running hamster-time-tracker no longer brings its window forward.

Thanks See you next month for a new summary of my activities.

2 comments Liked this article? Click here. My blog is Flattr-enabled.

One of the things I liked about Gnome 2 was the ability to run a background 'slideshow' defined in an XML file with a list of background files to give me a change of scenery from time to time. Switching to XFCE4 I can't seem to find a simple way to do that, but the ingredients are all there:

• I can set the background image to a list
• There's a handy-dandy xfdesktop command-line utility I can call to switch desktops

What's missing from the Desktop Settings is a setting for "switching background ever N minutes", which is kind of odd to not have, given the list thing being there - without my script it's only going to change every couple of weeks when I log in, or something. Not nearly often enough for me! There's lots of stuff on the internet saying "Just run xfdesktop --reload in a cron job", but this does not work for me, since cron is running with a different environment, and so xfdesktop doesn't know where the X server is and doesn't have the necessary XAUTHORITY and DISPLAY settings. If it was just DISPLAY that was needed it would be easy enough to set that in the crontab and be done with it - after all it doesn't change very often. XAUTHORITY is harder, since on Debian systems (and presumably others too) it has a random component in the name of a directory which lives in a directory without read permissions. I solved it with this script, which steals those values from the environmnt of xfce4-panel, which will be running already:

#!/bin/sh
#
PANELPID=" /usr/bin/pgrep -U $ LOGNAME  xfce4-panel "
stealEnvironment()  
  tr '\000' '\012' < /proc/$PANELPID/environ   grep -a "^$1="   cut -f2- -d=
 
export DISPLAY=" stealEnvironment DISPLAY "
export XAUTHORITY=" stealEnvironment XAUTHORITY "
/usr/bin/xfdesktop --reload

So now I have my background image switching among my favourite photos again, and my Desktop is effectively back as it was a week ago.