I wanted to start pidgin with all accounts disabled per default as far I want to use some of my accounts on my laptop and desktop in parallel (and avoid collisions). A possible way to do this was suggested to me by ploppy on #pidgin-de (freenode IRC): Start pidgin with the “-n” option. Therefore…

sudo vim /usr/share/applications/pidgin.desktop
Replace Exec=pidgin with Exec=pidgin -n.
When starting pidgin from the menu bar, it will start with the -n option now.

Tested with xubuntu 11.10.

xubuntu release: 11.10 (knome from freenode #xubuntu tells me that a bugfix got introduced in 12.04)

Okay, this was really a lot of luck that I got that fixed. The are many threads on the web about this issue and none of them seemed to be working for me. In general the problem for most people is that the ALSA master channel is muted, but the other component is PulseAudio and that was misconfigured in some way. Okay, let’s start debugging.

First of all, we want to check that neither ALSA nor PulseAudio is muted. We select the pre-installed “Multimedia” > “Mixer”. This Mixer shows the channel settings for all sound cards. We can select sound cards from the DropDown menu at the top. If you cannot see channels, “Select Controls…” as described by the “No controls visible” tab and check all channels to see their settings. I did this for all channels for all sound cards and everything got unmuted.

Okay, I said PulseAudio was misconfigured for me. Well, the above debug report was not successful. It purged all packages, reinstalled them and tried to change all settings. Some guy on the web recommended sudo apt-get install "pulseaudio-*" and all pulseaudio-packages got installed. Now comes the lucky part of the story: “PulseAudio Volume Control” got installed and changing its configuration was successful.

I rather recommend to install this package via the Ubuntu Software Center:

In “Multimedia” > “PulseAudio Volume Control” > “Configuration” I had to set “Profile” from “Digital Stereo (HDMI) Output” to “Off” and I immediately heard my music. I can now reset this setting back to “Digital …” and will still hear sound. So I cannot explain it deterministically, but this one worked out. Strange.

Please recognize that this is also related to the “Flash Player plays videos to fast” bug some users are experiencing. Once I can hear sound again, Flash’s playback is also back at normal speed.

The default configuration of Thunar in Xfce at arch linux allows the user to right-click in a folder and open a terminal at this location. Switching to konsole (because of Unicode problems) instead of xfce-terminal (Terminal), this feature did not work any longer. I figured it out how to solve it:

You can configure this feature in Thunar > “Configure custom actions…” (rather than “Xfce > Application Menu > Settings > Preferred Applications”). Select “Open Terminal here” and click “Edit”.

exo-open --working-directory %f --launch TerminalEmulator

Change this line to:

konsole --workdir %f

>>> The medium obscures the message: why programming languages matter

Good article. And just to add the obvious: Use the right tool for the job.

Pythonists are working on a stackoverflow alternative publicly available in the pypi ([pypi] [website] [github]). At the same time a company is working on a stackoverflow alternative privately for a customer.

Please repeat yourself and reinvent the wheel. This is where the software industry is going nowadays. The boundaries between company contexts and voluntary projects are too broad to be crossed in a copyright-driven society.

Save As Copy with extension pdf worked very well for almost a year. Suddenly it stopped working. PDF export resulted in File {FILENAME}.pdf could not be saved. Very uncomfortable for me as far as I am using SVGs on a regular basis.

The internet is filled up the bug reports… some are having specific plugin problems, some only get blank PDF pages. Well… this Inkscape 0.47 bug report got the solution for me. Remove the preferences.xml file (for me ~/.config/inkscape/preferences.xml) and Inkscape will create a new one when starting up.

What is the reason? I think some important package got upgraded and Inkscape is holding some old, conflicting information about this package.

Tags: Inkscape 0.47 pdf export SVG could not be saved preferences cairo

Because of a discussion with my brother I got curious about the internal handling of switch/case statements in assembly. So I compiled the stuff and studied it. Furthermore I wrote an article about it. I thought an external document is a better approach:

“switch in amd64 assembly” [HTML]

At university, TWiki is a pretty common software. At least at the second Google search results page (for “twiki” as search term) I can see some twiki running at our university’s webserver. TWiki is written in perl and I will refer to the deprecated 4.1.x version which was my test system. I got annoyed by limited security for passwords. Passwords are limited to 8 characters.

Login Managers

During installation you will face a select field like this (in the “Security Setup” section):

All those selections refer to different password management backends. Twiki::Client::ApacheLogin is implemented by /twiki/lib/TWiki/Users/ApacheHtPasswdUser.pm and Twiki::Client::TemplateLogin is implemented by /twiki/lib/TWiki/Users/HtpasswdUser.pm. In /twiki/lib/TWiki/Users/Password.pm the interface is defined. You can check out funny source code sequences like this:

Well… this is our interface. Let’s have deeper look into the implementation.

Twiki::Client::ApacheLogin

ApacheLogin uses the Apache interface to send 401 HTTP Status codes. If the client receives one of those status codes, a Username and Password Dialog pops up.

Using this dialog, the login information will be sent to the server. Using a loop in perl, we can print out what the server receives as CGI variables (the ones defined by the server and given to the perl interpreter). I have put the following source code into /twiki/lib/Twiki/Users/HtPasswdUser.pm subroutine new (don’t forget to include Data::Dumper).

From the Apache log, we will get the following information.

[...]
HTTP_COOKIE = 'TWIKISID=d00fe404e65832f9d95658d6d9112bec';, referer: /twiki/bin/logon/TWiki/TWikiRegistration
[...]
REDIRECT_REMOTE_USER = 'LukasProkop';, referer: /twiki/bin/logon/TWiki/TWikiRegistration
[...]
REDIRECT_STATUS = '401';, referer: /twiki/bin/logon/TWiki/TWikiRegistration
[...]

Actually I was looking for REMOTE_USER, which is a CGI variable only defined when Authorization was done. The cookie is not really interesting, but REDIRECT_STATUS approves that auth was done. REDIRECT_REMOTE_USER seems to be REMOTE_USER I am looking for… in some way. Alright… so what do we have here? Well… password and username associations are tested automatically by the Apache server and perl will not receive the password itself. Perl can assume that auth was done successfully and does not recognize it any further. Alright. So we have to determine where the passwords are stored.

Passwords for mod_auth are stored in .htpasswd files. A small UNIX find will return /twiki/data/.htpasswd. This file is updated for each change by the perl script.

LukasProkop:11/Yysc0Op9D2:unixuser@localhost

So the password is stored as a hash associated with the Login name and the local user name. Now let’s come to our real topic: Passwords with more than 8 characters. Let us create some additional accounts.

Well… our .htpasswd says:

CarminaBurana:UXjIprwRygc1.:unixuser@localhost
DiesIrae:UtCp6NoUsQdaQ:unixuser@localhost
KarlOrff:7kQC9KJ/39yA.:unixuser@localhost
LukasProkop:11/Yysc0Op9D2:unixuser@localhost
SixteAjoutee:R07ipKyeiYlho:unixuser@localhost

Now let’s log in with various accounts. As far as Twiki does not support a Logout button, the most comfortable way is to delete the cookie (see above) and refresh the page. Now we can see our problem: SixteAjoutee and DiesIrae can log in with each other ones password. The strange thing is, that their hashes are different. Our source code journey goes on…

Violation of second-preimage resistance?

$TWiki::cfg{Htpasswd}{Encoding} = 'crypt';

Our configuration file at /twiki/lib/LocalSite.cfg defines a variable for the various encoding algorithms. Of course such a variable is a perfect name to search for. The configure uses this variable, but HtPasswdUser.pm is the only other file.

The file encrypting the password is HtPasswdUser.pm at line 134. This file will apply the crypt function with a random salt to the password. The salt is 2 characters in length and stored at the front of the actually stored password. A small test script reveals the truth:

So there we have our problem. crypt uses the DES algorithm from the operating system and is limited to an input of 8 characters.

The collision-free solution

Of course the algorithm is the problem and a selection of another algorithm like sha1 (nope, no MD5!) would solve the problem. We do not rely on the operating system or missing implementations of other crypto algorithms.

This program returns two different hashes:

{SHA}sgDumzcRNpPJL8tCgM18JIR1ayc=
{SHA}RsUxZFkQgYAeTdsPmIixTYEdFgg=

Migration

How can thousands of user accounts be migrated to another algorithm? As far as the hash is stored as a one-way encrypted string, the encryption of the real password with another algorithm is almost impossible. I have written a small crypt() cracking program in python (sorry, Perl ), but of course it is way too slow; even for a single password. So the only solution is to reset all passwords of all users. First call the /twiki/bin/configure script and change the algorithm setting (“{Htpasswd}{Encoding}” in the “Security Setup” section) [0] and secondly, BulkResetPassword will help you reset the passwords for all users. It takes some effort and time, but in the end you will gain a higher level of security

[0] It is also possible to directly modify the $TWiki::cfg{Htpasswd}{Encoding} line in /twiki/lib/LocalSite.cfg