Main menu:


Please consider a small donation:



Or you can donate bitcoin:


Thanks to TekLinks in Birmingham, AL, for providing colocation and bandwidth.

Page Rank


FOSS Force Best Blog--2013 Award

Recent posts

Recent comments

About this blog

I am Eric Hameleers, and this is where I think out loud.
More about me.


My Favourites



October 2015
« Sep    

RSS Alien's Slackware packages

RSS Alien's unofficial KDE Slackware packages

RSS Alien's multilib packages


More june ’15 security fixes for Adobe’s Flash web plugins

adobe_flash_8s600x600_2Here are new packages for the flashplayer-plugin and chromium-pepperflash-plugin. It’s “patch tuesday” and therefore the chances were fairly high that there would be a new Flash security bulletin… indeed, check out Adobe Flash security bulletin: apsb15-14.

For your information: The updated Slackware package for chromium-pepperflash-plugin has version The updated flashplayer-plugin has version The Chromium plugin was taken from the Google Chrome 43.0.2357.130 RPM, and of course new packages for my own chromium package based on sources of that same version are underway – the 32-bit package is being compiled at the moment.

Download locations for the Flash plugins:


Hashed passwords in the shadow file

At work, we use NIS for central UNIX authentication, but server accounts with elevated rights (admin accounts) are actually local, with their own passwd entry. When the NIS password changes (forced password expiry) then I need to request a sync of the new password from NIS to all servers where I have a local account. That is done by syncing the password hash, so that I do not have to enter my plaintext password anywhere along the process – it is fully automatic.

My password had to change again recently, and that made me consider how the encrypted hashes are actually created.  Worthwhile writing that info down in a blog article I think.

On Slackware Linux, we use “/etc/shadow” instead of /etc/passwd to store the password of our user account. The shadow file is not accessible (readable) by regular users, therefore it is not possible to retrieve someone’s encrypted password hash… which would be the ideal catch for a password thief. Brute force cracking tools exist that will yield the plaintext password eventually. So, the shadow suite makes our life more secure.

How does this process work of creating and storing a password at first, and later offering those same credentials to the login program in order to be allowed entrance? When logging in,  you enter your username and the plaintext password. Your computer will use that plaintext password to compute an encrypted “hash” value and compare that computed hash with the hash value that is stored in “/etc/shadow”.

My example username will be “alien” and the password will be “Christmas.2014″:

The entry for the account “alien” in the /etc/passwd file looks like this:

alien:x:1001:100:The Alien,,,:/home/alien:/bin/bash

In the UNIX passwd file, every line consists of a series of fields separated by colons (:), see passwd(5) man page. The second field is where UNIX would store the password hash in pre-shadow times. Nowadays, only an “x” character is stored in that field because the actual password hash is stored inside the shadow file. So, the entry for the same account in /etc/shadow looks like this:


You see that the password field in the shadow file (which is also the second field) is  “$5$QIGCa$VJ16x81oLReQLHBzU60ADKlJoAdXVUJiSSB5FMgtfe.”. This value is the password hash. It can be de-constructed further. If we find out how this hash is constructed we will understand how our password will be checked and accepted at login. It will also become clear why you can try setting your password to the same value several times, and yet the hashed password will be different every time.

To start, let’s first look at the older Slackware releases. Chances are, if you have been upgrading your computer for years, you still have a password hash which stems from the old age. Slackware used to use a MD5-crypt encryption algorithm which is no longer considered secure. We’ll get to the current encryption scheme at the end of our example.

For our user “alien” with his password “Christmas.2014″, a MD5-crypted hash for the password would be: “$1$KdieS$8tz7obSJVIVegXsUtXxkq/”. You will probably have noticed that this hashed password is not simply a MD5 hash like “5ce3f04e74c0bc0d2e791ea0f47f5de0″, which can be obtained by running “echo -n  Christmas.2014 | md5sum”. The MD5-crypt algorithm does a lot more.

For one, it uses a “salt” to randomize the hash value and make it harder for password crackers to crack your password with brute force. So in fact your password hash is being constructed not just from your plaintext password but additionally a salt string (a random string of characters) is used as input for the encryption.

When you set or change your password, you enter the plain text password and your computer generates a random string to use as the salt value. The computed hash is therefore different every time you change your password, because the salt will be different every time! And the salt string with which your password was encrypted is used every time you login: by combining the plaintext password you provide at the login prompt with the original salt string, the system computes your password hash and compares that string with the string stored in the shadow file. If the two match, you are allowed entrance. Simple and elegant.

But how does your computer know which salt string was used in the first place? That is actually also simple and elegant: the salt is stored as part of your hashed password, in the shadow file! Visible only to root, it is safe from snoopers.

Time to dissect the password hash and show you how this is achieved. The hash “$1$KdieS$8tz7obSJVIVegXsUtXxkq/” consists of three distinctive sections separated by ‘$’ characters:

  1. $1$KdieS$8tz7obSJVIVegXsUtXxkq/
    • The ‘$’ characters are separators
  2. $1$KdieS$8tz7obSJVIVegXsUtXxkq/
    • The ‘1’ indicates that the hash was generated with the MD5-crypt algorithm. Different string means different algorithm.
  3. $1$KdieS$8tz7obSJVIVegXsUtXxkq/
    • The string ‘KdieS’ is the actual salt string that was used to compute the hash
  4. 1$KdieS$8tz7obSJVIVegXsUtXxkq/
    • The string ‘8tz7obSJVIVegXsUtXxkq/’ is the hash which was computed from the plaintext password combined with the salt.

In case you are wondering if you can create these hashes yourself, yes you can! Sometimes that can be useful in scripts. Here are two commands to generate the MD5-crypt hashes from the above example password (Christmas.2014) and the salt shown earlier (KdieS):

$ openssl passwd -1 -salt KdieS Christmas.2014
$ perl -e 'print crypt("Christmas.2014", "\$1\$KdieS"),"\n"'

Unfortunately this will not work to generate the hashes you will find in the shadow file of Slackware 14.0 and later. If you look closely at the hash value in the beginning of the article “$5$QIGCa$VJ16x81oLReQLHBzU60ADKlJoAdXVUJiSSB5FMgtfe.” you will see that there is a ‘5’ instead of a ‘1’ inbetween those first two dollar signs. A bit of deduction and your comclusion will be that probably a different encryption than MD5-crypt will have been used?

As of Slackware 14.0, SHA256 (with default of 5000 rounds) is used to hash new passwords. These parameters are controlled by “ENCRYPT_METHOD” and “SHA_CRYPT_{MIN,MAX}_ROUNDS” in the file “/etc/login.defs”. Salt prefix $6$ corresponds to SHA512. And the blowfish patches to glibc use $2a$ for their prefix (according to user mancha on LQ).

The $5$ prefix means that SHA-256 is used for hashing. My Slackware laptop creates a hash with $5$ prefix which means SHA-256 was used. However, the hash of my own password still has a $1$ prefix… carried over through years of upgrading without re-installing obviously…
The openssl and perl commands I showed earlier are not able to generate hashes using SHA hashing algorithms, but there is a Python command that does the trick:

$ python -c "import crypt, getpass, pwd; print crypt.crypt('Christmas.2014', '\$5\$KdieS\$')"

Finally, let me tip you on a command which will be useful when you need to update user passwords in a script. The “chpasswd” utility accepts lines on its input that have the format “username:password” and will set the password for that user in the shadow file using SHA256 hashing algorithm (or any other supported algorithm), as follows:

# echo "alien:Christmas.2014" | chpasswd -c SHA256

Have fun digesting this! Eric


Sourdough weekday adventures

 Time for another lesson in baking a tasty sourdough bread. Sourdough breads are all the breads I eat nowadays.
My son wanted me to “score” the bread in a smiley pattern but it turned out more like a Hallowe’en monster…
Anyway, this sourdough loaf was created using another rhythm than my usual “bake one sourdough bread during a weekend day” routine.
This is how I fit it into my work routine.
The 100 gr sourdough starter (100% hydration meaning equal weights of flour and water) which I used in the bread, was grown from a single tablespoon of starter. I mixed that with 50 gr flour and 50 gr water at 18:00 in the evening and let it ferment for 6 hours until midnight:
The dough for the bread (adding 250 gr whole-wheat flour, 150 gr Waldkorn mix, 50 gr all-purpose flour, 330 gr lukewarm water, 15 gr vegetable oil and 7 gr salt) was then created using this starter at midnight. What I did first was combine all ingredients except oil and salt and autolyse this mix for 25 minutes. Then I added oil and salt and hand-kneaded the dough for 10 minutes.
The kneaded dough ball was left on the kitchen counter at room temperature, covered by plastic wrap in a bowl  (I had a good night’s sleep) until 08:00 the next morning at which time it had about tripled in size.
The dough was deflated carefully, pre-shaped, bench-rested for 15 minutes and then shaped into a boule and put into a basket. The basket went into the fridge inside a sealed plastic bag.
Off to work.
I came back home at 18:00 that evening, transfered the basket from the fridge to the kitchen table (the dough had doubled in size during the day inside the fridge) and set the oven to pre-heat to 250C for an hour, with a pizza stone inside.
At 19:00 I turned the basket over and dumped the dough onto a silicone mat. I scored he bread with a smiley pattern and shoved it onto the pizza stone.
Baked during 20 minutes at 240 C with steam, then 20 minutes at 210 C without steam.
The result: impressive oven bloom, yummy bread with subtly more tones of sourness than my usual weekend breads that ‘only’ take 10 hours from start to finish.

June ’15 security releases for Adobe Flash

adobe_flash_8s600x600_2Yesterday I uploaded packages for the flashplayer-plugin and chromium-pepperflash-plugin packages, based on the latest Adobe Flash security bulletin: apsb15-11.


The updated Slackware package for chromium-pepperflash-plugin has version The updated flashplayer-plugin has version

Download locations:


KDE 5_15.06 with a few useful fixes

Yesterday there was a new release for the KDE Applications. I know that I updated my KDE 5 package set barely a week ago, but there were a few updates that I wanted to push anyway, so adding the updated Applications packages seemed like the proper thing to do.

So here is my first (there will probably a second) June release: KDE 5_15.06. Components are Frameworks 5.10.0, Plasma 5.3.1 and Applications 15.04.2. The updates to Applications contain KDE 4 Long Term Support (LTS) releases of kdelibs, kdepimlibs, kdepim, kdepim-runtime and kde-workplace.

What’s new in KDE 5_15.06?

The highlights of 5_15.06 (June release) are:

  • KDE Applications have been updated to 15.04.2 (a maintenance release containing the aforementioned KDE4 LTS updates)
  • KDE 4 Extragear has one package now: kdeconnect4, a barebones version of the kdeconnect-kde package that comes with slackware-current. It contains just those files that are required to access your Android device’s filesystem through Dolphin (which itself is still KDE 4 based). The rest of the old KDE 4 extragear is now part of slackware-current itself: grab these extragear packages (calligra, k3b, kdev-python, kdevelop, kdevelop-php, kdevelop-php-docs, kdevplatform, kio-mtp, kwebkitpart, oxygen-gtk2, oxygen-gtk3, partitionmanager, skanlite) from any slackware-current mirror.
  • KDE 4 based package kactivities no longer ships with the daemon kactivitymanagerd. The daemon is incompatible with the Frameworks version of kactivities, and in some cases this file overwrote the Frameworks version of kactivitymanagerd, causing severe desktop crashes.

Installing or upgrading Frameworks 5, Plasma 5 and Applications

As always, the accompanying README file contains full installation & upgrade instructions. Note that the packages are available in several subdirectories below “kde”, instead of directly in “kde”. This makes it easier for me to do partial updates of packages. The subdirectories are “kde4″, “kde4-extragear”, “frameworks” “plasma”, “plasma-extra” and “applications”.

Upgrading to this KDE 5 is not difficult this time, especially if you already are running KDE 5_15.04 or later. You will have to remove old KDE packages manually. If you do not have KDE installed at all, you will have to install some of Slackware’s own KDE 4 packages manually.


If you are using slackpkg+, have already moved to KDE 5_15.01 or newer and are adventurous, you can try upgrading using the following set of commands. This should work but feel free to send me improved instructions if needed (assuming in this example that you tagged my KDE 5 repository with the name “ktown_testing” in the configuration file “/etc/slackpkg/slackpkgplus.conf”):
# slackpkg update
# slackpkg install ktown_testing (to get the newly added packages from my repo)
# slackpkg install-new (to get the new official Slackware packages that were part of my deps previously)
# slackpkg upgrade ktown_testing (upgrade all existing packages to their latest versions)
# slackpkg upgrade-all (upgrade the remaining dependencies that were part of my repo previously)
# removepkg sddm-theme-breeze (gone after KDE 5_15.01)
# removepkg libmm-qt5 (gone after KDE 5_15.03)
# removepkg qt-gstreamer0 (gone after KDE 5_15.04)
# slackpkg reinstall qt-gstreamer (ensure that none of the overlapping files of qt-gstreamer0 are left)
# slackpkg reinstall kactivities-framework (ensure that you are using the frameworks version of kactivitymanagerd)

And doublecheck that you have not inadvertently blacklisted my packages in “/etc/slackpkg/blacklist“! Check for the existence of a line in that blacklist file that looks like “[0-9]+alien” and remove it if you find it!

Recommended reading material

There have been several posts now about KDE 5 for Slackware-current. All of them contain useful information, tips and gotchas that I do not want to repeat here, but if you want to read them, here they are:

A note on Frameworks

The KDE Frameworks are extensions on top of Qt 5.x and their usability is not limited to the KDE Software Collection. There are other projects which rely (in part) on the KDE Frameworks, and if you are looking for a proper Frameworks repository which is compatible with Slackware package managers such as slackpkg+, then you can use these URL’s to assure yourself of the latest Frameworks packages for Slackware-current (indeed, this is a sub-tree of my  KDE 5 “testing” repository):

Where to get the new packages for Plasma 5

Download locations are listed below (you will find the sources in ./source/5/ and packages in /current/5/ subdirectories). If you are interested in the development of KDE 5 for Slackware, you can peek at my git repository too.

Using a mirror is preferred because you get more bandwidth from a mirror and it’s friendlier to the owners of the master server!

Have fun! Eric