So what’s the problem with that, you think? The problem is that almost all Flash applications can be hacked very easily and most developers are not aware of that.

As a reminder of how vulnerable Flash applications are, this post aims to raise awareness for these issues. In a case study, it shows how a Flash-based game and its server side high score can be tricked within a few minutes using free tools only.

Disclaimer

This post is meant to raise awareness for the vulnerabilities of Flash-based applications. It is not a hacking tutorial or how-to. For that reason, I will not describe all steps in great detail, but only sketch the basic steps.

1. Introduction

1.1. The problem with Flash applications

Flash applications are similar to normal Windows/Linux executables: Like normal programs, their source code is compiled to a binary format and later executed on the client machine. The major difference to .exe or Linux binaries is that decompiling is a lot easier: while a C or C++ compiler translates the source code into machine code, i.e. CPU instructions, SWF files contain the ActionScript code in plain text. That is with the right tools, extracting the complete code is a no-brainer!

Combining this with the fact that sniffing into the client-server communication is also not the most difficult task, one can easily simulate the Flash client with own code snippets and scripts, and thereby send forged requests to the server.

1.2. Checksums as a solution?

Most application developers at least know that the client-server communication can be sniffed into. As an attempt to make it more difficult for people to send forged requests to the server, applications mostly use a message authentication code (MAC) or some other checksum-based mechanism. So instead of sending a plain text update query to the server (1), the application creates a hash by concatenating the user input with (to the user unknown) other data (2):

This mechanism is completely based on the fact that the user does not know how the checksum is created. While this approach is very effective in regular applications, it completely fails in Flash programs: disassembling a Windows or Linux binary is very difficult and requires know how in assembler. Decompiling SWF files, however, is fairly easy and can be done in under a minute. That is retrieving the code that generates the checksum is only a matter of seconds.

1.3. Tools and basic approach

The following steps present a generic approach on how any Flash application can be exploited like described above.

Required Tools:

• Firebug: Firefox plugin for basic communication sniffing
• Sothink Flash Decompiler: required to extract ActionScript code (trial version is sufficient)
• Wireshark: required for detailed communication sniffing (byte-for-byte)

Generic Approach:

1. Enable Firebug and start sniffing with Wireshark.
2. Go to the target web site and play the game or use the application.
3. Look at the communication of the Flash application with the server. If there are any parts of the requests that cannot be recreated without the source code, e.g. checksums, download the important SWF files and decompile them.
4. Analyze the ActionScript code and find the part which creates the checksum.
5. Make a script that generates the same request with arbitrary input data, e.g. any score or name. For this script, the checksum algorithm from the ActionScript code can be used (or recreated).

2. Case study: a car parking game (with high score)

Our local newspaper Mannheimer Morgen recently hosted a competition in which users had to park a (virtual) car into different parking spots without damaging the car and with minimal fuel usage. Prizes were a safety training and concert tickets. While in this case the score of the participants did not decide who won (winners were drawn by lot), the winner in other competitions might be the one with the best score. Please note that I did not take part in this competition and I did under no circumstances try to win the prizes.

Parking Game: The target application in this case is a game called “Parking”.

2.1. Capture the client-server communication

Following the instructions from above, the first step is to capture the communication between the Flash client and the server. In this case, we are particularly interested in how to add our name with an arbitrary score to the high score list.

Firebug:
Using Firebug, we can see three interesting requests:

• savescore.swf is the part of the client that is responsible for sending the score to the server.
• serverdate-read.php is called by savescore.swf for no obvious reason – very suspicious. We will later see that the result is used in the checksum generation.
• highscore-write.php is also called by savescore.swf and actually writes the user’s score to the database on the server.

Firebug identifies the interesting files and requests.
In this case, three requests are relevant for the high score forgery.

What is particularly important is the two parameters __ctrl and controlvalue. Both are obviously generated by some checksum function in the savescore.swf-file. So the next step is to decompile the SWF file and look for the checksum-generating function.

Wireshark:
If we additionally enable Wireshark, we can get a plain text (or hex) representation of the HTTP request-response cycle. That is particularly important if one wants to forge a request in a way that it cannot be detected by the server.

2.2. Decompile the SWF file and find the checksum algorithm

Using the SWF Decompiler software (trial version is sufficient), the savescore.swf can be examined very closely. Most of the applications are not very complex and the relevant code pieces are found very easily.

When analyzing savescore.swf, the two parts in which the checksums are created are found at different positions in the file. The __ctrl parameter is generated by taking a MD5 hash over the two concatenated values of score and email. The controlvalue parameter is created in a similar fashion and involves the previously queried serverdate.

The __ctrl parameter is a hash value over two of the variable input parameters.
The controlvalue parameter is created similarly.

2.3. Write a script

Once it is clear how the checksums are generated, the puzzle is solved. The only thing left is to write a script that allows entering arbitrary input values, and using the previously determined checksum-mechanisms to generate a MAC.

Here is a short excerpt of how this could look like (using PHP):

$score = "999.999";
$email = "nobody@example.com";
 
$data = array(
	"__ctrl" => md5($score.$email), 
	...
	"score" => $score,
	"controlvalue" => md5(...), 
	...
);
 
foreach($data as $k=>$v) 
	$data_enc[] = urlencode($k)."=".urlencode($v);
 
$req = "POST /parking/highscore-write.php HTTP/1.1\r\n"
     . "Host: www.morgenweb.de\r\n"
     ...
     . join("&",$data_enc);
 
$fp = fsockopen("www.morgenweb.de", 80);
fwrite($fp, $req);
while ($line = fgets($fp)) { }	
fclose($fp);

3. Conclusion

This blog post introduced a common way to outsmart Flash applications and games. It demonstrated that by sniffing into client-server communication and decompiling SWF files, many Flash applications can be misused. Using the example of a Flash game, the post showed that SWF cannot be compared to Windows/Linux binaries, but must rather be seen as JavaScript-like client code.

Even though this post only demonstrated this using a rather harmless game, more serious misuse is also possible. Flash-based music streaming sites such as Simfy, Spotify Grooveshark are affected as well. They all use a similar mechanism for their Flash-based music player. Using the approach presented above combined with tools like rtmpdump can potentially harm their services significantly.

Flash once was a great way for bringing a little dynamic in the Web 1.0, but is no outdated. With various JavaScript frameworks and HTML5 on the way, Flash is going to retire soon. Developers and companies must be aware of the flaws of Flash and adjust their services accordingly to make sure that they cannot be misused.

But what happens if you accidentally commit a password or other sensitive information to a repository? This post explains how to remove this confidential data permanently from the repository by simply overwriting it in old revisions, i.e. without having to remove revisions or create a new repository.

1. Introduction

1.1. Disclaimer

The following actions might lead to data loss. I am not responsible for anything that goes wrong because of my description.

1.2. Requirements

It is absolutely necessary to have root access to the SVN respository. That is not only through the svnadmin command, but full command line access to the files, particularly to the “repos” directory.

If you do not have root access to the repository, you cannot remove any data from the repository! In that case, contact your SVN administrator.

1.3. Example Scenario

For this example, let’s assume you accidentally committed the file config.cfg with a plain text password 123secret a while ago (in revision 12). The repository is currently at revision 25 and you just realized that the password was in there all the time:

# Config file "config.cfg"
username = someone
password = 123secret
...

2. Local machine: Identify the affected revisions in the working copy

2.1. Fix and commit the affected file

The following commands are performed on your local machine within the working copy of the project, i.e. on the client machine.

Before we start tinkering and forging the SVN history and its repository, first fix the affected file and commit a new revision to the repository. In most cases, people are not going to look in old revisions of a config file, so the faster you commit a new version, the less likely it is that someone sees it!

$ cd ~/Dev/yourproject
$ vi config.cfg
# Change password to something else
$ svn commit -m "config update"
...
Transmitting file data .
Committed revision 26.

2.2. Identify the affected file versions locally

In most cases you will probably realize right away that you just committed something confidential to the SVN repository. In this case, you only have to fix one single version of that file and is pretty clear which revision is affected.

In other cases, however, the affected file might be in the repository for many revisions before you realize it. If this is the case, there might be multiple revisions of the file in the repository and each of these versions needs to be fixed. To identify the possibly affected versions of the file, you can peak into the logs:

$ svn log config.cfg
------------------------------------------------------------------------
r22 | someone | 2011-01-25 01:36:12 +0100 (Tue, 25 Jan 2011) | 1 line
 
update xy config
------------------------------------------------------------------------
r12 | someone | 2011-01-05 00:45:19 +0100 (Wed, 05 Jan 2011) | 1 line
 
added connection details to config
------------------------------------------------------------------------
...

In this case, the file has been altered in the two revisions 12 and 22. Both might include the password and are stored in the repository, i.e. both potentially need to be corrected.

2.3. Get MD5 checksums of the affected versions

SVN ensures the integrity of its repository by saving MD5 checksums of all the files and its versions. Since it is now clear which revisions might be affected, you need to get the current checksums of these file versions and calculate checksums for the new corrected (“forged”) versions. In short, you need to do the following for each affected version:

• Retrieve the version and calculate its MD5 checksum
• Make a copy of file, replace the confidential information with “x”s and calculate the MD5 checksum of the new file.
• Remember or copy all the checksums and versions into a file.

In this example, we’ll have to get the checksums for revisions 12 and 22 of the config.cfg-file. The code below only shows what to do for revision 22; revision 12 is analogue:

# Get current checksum of revision 22
$ svn --revision 22 config.cfg
...
At revision 22.
$ md5sum config.cfg
0e28c6c8342649c290400567130f657b  config.cfg
 
# Correct the file and get new checksum
$ cp config.cfg /tmp/config.cfg-22
$ vi /tmp/config.cfg-22
# Overwrite the password with "xxxxxxxxx" (same length as the old password!!)
$ md5sum /tmp/config.cfg-22
459a78e2eae02b28f810f9fdebdc5b52  /tmp/config.cfg-22
 
# Repeat this for revision 12

3. SVN repository: Correct the affected files

In this step, we finally start altering the repository. All the actions are performed on the server machine as root user inside the actual SVN repository directory, so be sure not to confuse it with you local machine.

3.1. Make a repository backup

Creating some sort of backup is crucial, since we are about to change the binary revision files of the Subversion repository. The easiest way to do this is to backup the whole repository folder of your project, e.g. /path/to/svn/repos/yourproject. However, if its total size is too big you can also choose to only backup the files identified in 3.2.

# Make backup of project; Note the "-a" parameter to keep the permissions.
$ mkdir /backups
$ cp -a /path/to/svn/repos/yourproject /backups

3.2. Verify affected versions

After the backup, we need to verify that we really need to change all the versions we identified earlier. To do that, navigate to the “revs” folder inside the repository and grep for the password:

$ cd /path/to/svn/repos/yourproject/db/revs/0
$ grep 123secret *
Binary file 12 matches
Binary file 22 matches

The matching files are the revisions that contain the password, and hence also the files that need to be “corrected”. Note that sometimes not all the versions identified through the “svn log” command appear in this list. That is because when the file is simply moved and not changed or other parts of it were altered, its contents will not be stored in the SVN revision file.

3.3. Replace the password and checksums

Since the SVN revision files are binary, we need a hex editor to edit them. Hence install hexedit, and then simply replace the password and checksums like identified before:

$ apt-get install hexedit
 
$ hexedit 22
# Hex editor opens the file for revision 22
# Replace passwords and checksums
 
# Repeat this for revision 12

Hexedit is not the easiest editor to use. So here is a step-by-step of what you need to do:

• Hit TAB, then CTRL-S to search
• Enter the password 123secret and hit return
• Overwrite the password with xxxxxxxxx (same length!)
• Hit CTRL-S, then “Y” to save
• Repeat 1-4 for each occurance of the password.
• Do the same for the old checksum “0e28c6c8342649c290400567130f657b”, and replace it with the new one “f85abfd8b63fa7ab68abc9364f2d339e”
• Hit CTRL-X to quit
• Repeat this for all affected revisions

That’s the complete magic. If checked out, the revisions 12 and 22 (and of course also their succeeding versions) will show xxxxxxxxx instead of the initially committed password.

4. Test locally

Now test locally if you can switch between revisions and every works without error messages:

$ svn --revision 12 update
...
At revision 12.
$ grep password config.cfg
password = xxxxxxxxx

If you did everything as the tutorial says, you shouldn’t get any errors. If you forgot to replace checksums or you changed something that you weren’t supposed to change in the SVN revision file, you might get an error like below. However, if that happens, you can always go back to your backup and try it again…

$ svn --revision 12 update
svn: Checksum mismatch while reading representation:
   expected:  f85abfd8b63fa7ab68abc9364f2d339e
     actual:  de6f581d115197baebc43c3975b9e396

5. Bash history cleanup

In step 3.2. we typed the plain text password in the bash. As you might know, this leaves traces in the ~/.bash_history file. Delete them by opening the files and then by simply removing the according lines. Make sure that you do not use the search function of VIM, since that has a history on its own. If you do, delete the history of VIM in ~/.viminfo.

$ vi ~/.bash_history
# Remove everything that contains the password
# Do NOT use the search function, but search manually!

However, as stated many times by Picasa users and bloggers [1,2,3,4,...], Picasa’s export function misses a tiny little feature that maintains the sort order of the album when exporting it to a folder. Instead of renaming the pictures to keep them sorted in normal file managers (by name), Picasa just copies the files of an album to one folder and thereby destroys the order. As if that wasn’t enough, Picasa also overwrites duplicates filenames from different source folders.

This missing feature has even led to small standalone projects that fix this issue, e.g. Picasa Independent Album Exporter (PIAE) and Picasa Order Preserver. While both applications do their job, both are a bit heavyweight, and PIAE only works for Windows (and not on Wine).

This post presents a tiny little Perl script that renames pictures of an exported album according to their Picasa sort order.

Download & Installation

The script requires Perl module XML::Simple to be installed. In Debian/Ubuntu, install the package libxml-simple-perl.

Download the script, save it to your preferred location and make it executable:

$ sudo apt-get install libxml-simple-perl
$ sudo wget -O /usr/local/bin/picasa-export \
          http://blog.philippheckel.com/uploads/2011/01/picasa-export
$ sudo chmod +x /usr/local/bin/picasa-export

That’s it for the installation.

Download: Picasa Export 0.1, January 2011

Usage

Using the script is also very simple. Simple export the desired album using Picasa’s “Export to HTML Page” function and call the script with the exported folder as parameter.

Example with “YourAlbum”:

1. Picasa: Click “Folder” → “Export to HTML Page…”. Select “XML Code” in the template list. Click “Export”.
2. Console:

   $ picasa-export ~/"Picasa\ HTML\ Exports/YourAlbum"

After that, the new folder “neworder” contains the renamed pictures.

For developers, context-awareness can be both a blessing and a curse. While the mobile operating systems iPhone OS and Android come with relatively good sensor-support, the vast majority of devices deal with Java ME’s basic and heterogeneous sensor functionalities.

The Aware Context API (ACAPI) aims to bridge this gap by providing a framework for building context aware applications for mobile devices based on Java ME. In this article, I’d like to introduce ACAPI, its structure and usage briefly. Please feel free to comment.

1. Motivation and Goals

ACAPI is designed to allow easy and homogeneous access to the different sensors of the mobile device. It creates an abstraction between the available sensors and their usage so that developers can focus on the business logic rather than on how to use the sensor implementations.

Example: A mobile application shall notify the user if another (previously defined) person comes into his or her range, e.g. if the boss arrives at the office.

Using the standard Java ME interfaces, developers have to get to know the different APIs and write a lot of code to solve this or similar problems. In this use case, the application needs to determine its position (the office), monitor the available devices around it (the phone of the boss) and be able to notify the user when both events occur.

The Aware Context API aims to solve this reoccurring problem with an easy-to-use event-based framework that allows defining rules for available sensor data. Using ACAPI, the given example can be solved easily by defining a rule and an action that is triggered when the rule matches:

• Rule: Wi-Fi “OfficeWLAN” available AND Bluetooth device “BossPhone” available
• Action: Notify user, e.g. by playing a sound

2. Development Team and Scope

The ACAPI project was developed within the scope of a team project as part of the curriculum of a Master of Science Degree at the University of Mannheim. The project was a team-effort, carried out over a 1-year duration at the Chair of Business Administration and Information Systems, under the supervision of Prof. Armin Heinzl and his research assistants Erik Hemmer and Sebastian Stuckenberg.

The project team consisted of Lars Bakker, Philipp Heckel (myself), Obie Modisane, Benjamin Schubert and Moritz Wächter.

3. Aware Context API (ACAPI)

The Aware Context API is well-structured and is very easy to understand. It is easily extendible and supports a broad range of devices. It is mainly based on Java ME, but has native parts whenever needed (e.g. for Wi-Fi, battery or telephony).

3.1. ACAPI Structure

ACAPI is horizontally structured into 3 different layers:

• Sensor: On the lowest level, the sensors gather data about the current status and context of the phone. A Wi-Fi sensor, for instance, collects available devices and it issues an event whenever the data changes. Applications can either hook themselves directly into the sensor events or use higher abstractions (conditions and rules).
• Condition: In order to evaluate a single sensor, conditions compare the sensor’s properties to given values. They can become either true or false. A location condition, for example, becomes true if the phone gets into the range of certain coordinates. Similar to a sensor, a condition issues an event when the value changes (from true to false, or vice versa).
• Rule: To express more than one condition, rules can combine conditions to a more complex logical expression. In the above example, the rule only matches if both conditions match (“in the office” and “boss phone available”).

ACAPI Structure (simplified and incomplete!): The Aware Context API is layer-based. Each of the components is easily extendible and has event listeners to react on changes. This chart shows the interdependence of the different layers.

Using this layered structure, ACAPI fundamentally changes the development strategy of mobile applications. Instead of predefining a screen and/or process flow, applications are event-driven. Whenever a rule changes its state (match vs. no match), the application can react by displaying a different screen, notifying the user, or by performing other actions.

Besides the horizontal division, the API is also vertically divided in the two logical parts Boolean and Fuzzy. While the Boolean part assumes correct sensors, the Fuzzy conditions and rules take measurement errors and inaccuracy into account. While the Boolean conditions and rules can only become true or false, their Fuzzy counterparts implement a score-based system that only triggers when a certain threshold is reached. This is particularly relevant for sensors that supply accuracy data, e.g. GPS sensors.

3.2. Implemented Sensors

The current code base of ACAPI includes several predefined sensors, including the most common: Bluetooth and GPS. Most sensors are entirely based on Java ME and will work on any phone that supports the corresponding JSR. However, since Java ME does not provide access to some functionalities, a few native implementations are required (e.g. for Wi-Fi, battery status or telephony status).

The following sensors are already implemented:

• Battery Sensor (native S60): This sensor monitors the status of the battery (%) and the charger (enum value, e.g. on-battery, or plugged-in). There is currently only a Symbian S60 implementation for this sensor since Java ME does not allow access to the battery data.
• Bluetooth Sensor: This sensor monitors available devices, e.g. phones or laptops. It can react on joining or leaving devices.
• Custom Sensor: This sensor allows the integration of business logic in ACAPI, so that rules do not only include actual sensor data, but also virtual business sensor data.
• Location Sensor (GPS and Wi-Fi; partially native S60): This sensor monitors the position and the speed. It uses GPS and Wi-Fi triangulation to get a fast and accurate position. Since Java ME does not allow access to the wireless sensor, the Wi-Fi part is native S60 code.
• Noise Level Sensor: This sensor monitors the noise level (in decibels) of the surrounding area.
• Time Sensor: This sensor delivers the current time and can react on date and time changes.
• Wireless Sensor (native S60): This sensor monitors the available Wi-Fi devices, i.e. access points. It can react on joining and leaving devices. In combination with a web service, it can be used to estimate the position.

There are many other possible sensors that could be implemented using the available abstract classes. Examples include an orientation sensor (react on device movement) or a telephony sensor (react on calls, SMS etc.).

4. Example Usage

Having discussed the structure of the Aware Context API, the following section elaborates the above-mentioned example even further. It explains the scenario and shows specific example code.

4.1. Example Scenario and Code

As already briefly mentioned above, the example scenario for demonstrating the API is very simple: The application shall display a warning message and play a warning sound when the boss arrives at the office.

The two conditions depicted in the diagram above are combined in one Boolean rule, i.e. the rule only becomes true if both of the conditions match.

Similar to the API concept, its actual usage is also very simple. The following code snippet shows how to implement the above example in a regular Java ME application.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

// Conditions
Condition inOffice = new WirelessNearCondition("OfficeWLAN");
Condition bossPhone = new BluetoothNearCondition("BossPhone");
 
// The two conditions create one rule
Rule bossDetectionRule = new BooleanRule();
bossDetectionRule.addCondition(inOffice);
bossDetectionRule.addCondition(bossPhone);
 
// React when the rule matches
bossDetectionRule.addRuleListener(new RuleListener() {
   public void ruleChanged(Rule rule, boolean matches) {
     if (matches) {
        playWarningSound();
        displayWarningMessage("Warning: boss has arrived!");
     }
}});
 
// Activate rule
bossDetectionRule.setActive(true);

In lines 2-3, the specific conditions are created. Since both conditions represent very generic cases (Bluetooth/WLAN device in range), ACAPI provides predefined conditions for them. In cases where more complex tests are desired, conditions can be extended via simple Java inheritance. Lines 6-8 combine the two conditions to a single Boolean rule, i.e. a rule that becomes either true or false depending on the status of its conditions. Since the application is supposed to react on changes in this particular rule, it registers itself as a listener in lines 11-17. When the rule is activated (line 20), it tells its conditions to register themselves at the corresponding sensors, which in turn get activated (if not already running). After this initialization, ACAPI notifies all registered listeners whenever the rule changes.

Depending on the status of the rules and conditions, i.e. on the device context, the application can change its appearance, behavior or internal state. In this case, it only plays a warning sound and displays a warning message (lines 14-15).

4.2. Proof-of-Concept Application

In order to test the implemented sensors and the rules engine of ACAPI, we developed a proof-of-concept application that implements a more sophisticated context driven use case.

A field service automation application that reacts upon the context the worker is in at the moment. This can be nicely done with the ACAPI and has a value for businesses. However, as this part of our project is not open source, I will not go into more detail here.

5. Future Work and Conclusion

The Aware Context API provides a framework for building context-aware applications for mobile devices based on Java ME. By providing uniform interfaces to different sensors, the library allows the development of context-driven applications.

The idea and structure of ACAPI are very solid, however, the actual implementation is in a very early development stage. While most sensors and Boolean conditions/rules are already working on the test devices, the Fuzzy conditions and rules are yet to be implemented. The native part only covers Symbian S60 so far and lacks of stability. Hence, the future work will include the implementation of missing parts, testing as well as the documentation.

A. Download and License

ACAPI will be released as open source, possibly under GPL or a Creative Commons license. Since we have not finished cleaning up the code and commenting everything, the code is not available for download as yet.

However, since it will be open source anyway, I will give out the code upon request.

An essential part of this evolution, but mostly hidden to the end-consumer, is the set of tools that enable these large scale applications. Cloud computing is a relatively new technology that serves as underlying architecture for most of these platforms. By providing virtualized computing resources as a service in a pay-as-you-go manner, cloud computing enables new business models and cost effective resource usage. Instead of having to maintain their own data center, companies can concentrate on their core business and purchase resources when needed. Especially when combining a privately maintained virtual infrastructure with publicly accessible clouds in a hybrid cloud, the technology can open up new opportunities for businesses and help consolidating resources.
However, since cloud computing is a very new term, there are as many definitions of its components as there are opinions about its usefulness. Most of the corresponding technologies are only a few years old and the toolkits lack of maturity and interoperability.

This article introduces the basic concepts of cloud computing and discusses the technical requirements for setting up a hybrid cloud. It briefly looks into security concerns and outlines the status quo of current cloud technologies. In particular, it evaluates several existing cloud toolkits regarding its requirements, occurring problems and interoperability.

1. Cloud Computing

1.1. Status Quo

As newest concept in the development of distributed computing, cloud computing is often believed to be “the next step in the evolution of the Internet” (Open Cloud Manifesto). As foundation and enabler for Software as a Service, it delivers computing resources over the Internet and provides elastic scalability for any kind of application. While cluster and grid computing already allowed multiple computers to work together on complex tasks in a distributed manner, the cloud concept extends this idea even further: instead of regarding individual machines, cloud computing treats resources as a utility. That is computing time and storage are provisioned on-demand and paid per usage without the need for any upfront commitment.

As one of the first commercial providers of cloud services, Amazon launched a beta version of its Elastic Computing Cloud (EC2) in August 2006 and announced production stability in October 2008. Google followed with a public beta of App Engine in April 2008, and Microsoft made its cloud platform Windows Azure publicly available in February 2010. The well known alternatives to the commercial solutions are several open source cloud toolkits. Prominent examples include OpenNebula, a project started by researchers of the University of Chicago and Madrid in 2008, as well as the Eucalyptus cloud software, initiated by the University of California, Santa Barbara in 2007.

Even though there are already many commercial and open source cloud solutions, all of them are fairly young and have yet to prove their acceptance and durability. According to the Open Cloud Manifesto, the technology “is still in its early stages, with much to learn and more experimentation to come“. This particularly includes challenges that yet need to be overcome, e.g. data security within the cloud, or interoperability between different clouds.

1.2. Definitions and Key Characteristics

Due to the actuality of the topic, there are several opinions about what cloud computing and its corresponding terms comprises. Some experts see the technology as “one of the foundations of next generation computing” (Tim O’Reilly, CEO of O’Reilly Media, 2008), others believe that the term is just a buzz word to define “everything that we currently do” (Larry Ellison, CEO of Oracle Corp., 2008).

However, while the term is being criticized, there are still many intersecting definitions describing the technology. Some are broader than others and include not only the technical part, but also the services enabled by the cloud, i.e. SaaS applications. For the Laboratory of Distributed Systems of the University of California, Berkeley, for instance, “cloud computing refers to both the applications delivered as services over the Internet and the hardware and systems software in the data centers that provide those services” (Armbrust et al., 2009). Not contrary to that definition, but limiting the term to hardware and software, IBM describes cloud computing as “an emerging computing paradigm where data and services reside in massively scalable data centers and can be ubiquitously accessed from any connected devices over the Internet” (O’Neill, 2009).

In this article, cloud computing is defined by the three key characteristics shared by many experts:

• Resource abstraction: resources inside the cloud are not directly observable by the cloud user, but are virtualized using technologies like Xen or KVM, and can be accessed via an application programmable interface (API).
• Elastic capacity: the cloud appears to users as a pool of infinite capacity, being able to allocate and free resources on-demand. Scaling up and down avoids over- and under-utilization and thereby allows an optimal load.
• Utility-based pricing: storage, CPU time and network bandwidth are charged by the hour using a pay-per-use pricing model. Resources can be allocated almost instantaneously without any upfront commitment.

1.3. Classifications

Similar to the attempts to define the term cloud computing, the categorization of it is rather difficult, if not “impossible in the currently rapid evolution of the cloud landscape” (Lenk et al., 2009). However, many papers classify cloud systems by their level of abstraction and their exposure to the Internet.

1.3.1. Service Models: Abstraction Classes

In order create the illusion of infinite resources and elasticity, virtualization technology is needed. Depending on how abstracted resources are, different service models are differentiated (cmp. NIST, 2009, and Armbrust et al., 2009):

• Software as a Service (SaaS): at the highest level of abstraction, users are mostly unaware of the fact that are using cloud-enabled applications, and are hence not able to control the underlying resources. Instead, they simply use client interfaces such as web browsers. A popular example is the salesforce.com CRM system.
• Platform as a Service (PaaS): users are able to develop and deploy applications within the provider’s hosting environment, e.g. a Java application framework. Low-level resources are not controlled by the cloud user. Prominent example is the Google App Engine.
• Infrastructure as a Service (IaaS): at the lowest level of abstraction, cloud users have access to virtualized resources such as processing time, networking or storage. They are provided virtual machines and can run arbitrary software. Famous example is Amazon EC2.

1.3.2. Deployment Models: Exposure Classes

Not every cloud is available for public use: depending on the level of exposure to the Internet, the following deployment models are differentiated (NIST, 2009):

• Public Cloud: the cloud infrastructure is publicly accessible via an API. It is hosted by a cloud provider who sells its capacity using a pay-per-use payment model. All of the above mentioned examples are public clouds.
• Private Cloud: the cloud infrastructure is hosted within the data center of an organization and used by local users only. It focuses on providing a flexible virtualized infrastructure rather than on selling the cloud resources.
• Hybrid Cloud: the hybrid cloud approach extends the private cloud model by using both local and remote resources. It is usually used to handle flash crowds by scaling out when the local capacity is exhausted. This so called cloudbursting enables highly elastic environments. The key difference between private and hybrid clouds is “the extension of service provider-oriented low cost cloud storage to the enterprise” (Lesem, 2010). That is remote cloud resources are seamlessly integrated in the private cloud, and thereby create a hybrid cloud.

As Debian/Ubuntu user, I am spoiled when it comes to update management: apt-get updates most of my software, and apticron notifies me when updates are available. For WordPress however, the packaged versions of Debian/Ubuntu are really old and less adjustable which unfortunately makes a manual installation inevitable. While there are several automated WordPress update mechanisms out there, I couldn’t find a simple notify-on-update tool.

This post introduces the WordPress Update Notifier (WP-UN), a simple script that frequently compares the installed WordPress version with the latest available one. If a new version is available, it sends an e-mail to a given address.

Update

February ’11: I updated the script so that it now uses the WordPress API. If you want, you can still download the old version of WP-UN, but since wordpress.org changed their download mechanisms, it does not work any more.

Requirements

WP-UN is compatible with WordPress 2.5-3.x. It needs a local mail server such as Sendmail or Postfix to deliver the notification e-mail.

Download & Installation

Download the script, save it to your preferred location and make it executable:

$ wget -O /usr/local/bin/wp-un \
          http://blog.philippheckel.com/uploads/2010/01/wp-un
$ chmod +x /usr/local/bin/wp-un

That’s it for the installation. The script can now be called by simply running wp-un.

Download: WP-UN 0.2, February 2011
Old version: WP-UN 0.1, January 2010 (broken!)

Usage

Now you can call the script with the following arguments:

• –test: to test if the notification works, use the –test parameter (optional).
• INSTALL-DIR: the path to your local WordPress installation, for example /var/www/myblog.
• NOTIFY-EMAIL: the e-mail address of the person to notify if a new WordPress version is available.

By default, the script is completely silent so that adding a cronjob doesn’t require output redirections. If, however, the –test option is given, it is more verbose and sends the notification e-mail in any case.

If a new WordPress version is available, the output looks something like this:

$ wp-un --test /var/www/myblog admin@example.com
Checking installed version... WordPress 2.5.1
Checking latest version... WordPress 2.9.1
Update required; Sending notification to admin@example.com... done.

If WordPress is up-to-date, WP-UN would normally not send any notification. If, however, the –test option is enabled, it sends the e-mail no matter what. In this case, the output will look like this:

$ wp-un --test /var/www/myblog admin@example.com
Checking installed version... WordPress 2.9.1
Checking latest version... WordPress 2.9.1
Update not necessary; WordPress is up-to-date.
TEST-flag enabled: sending notfication to admin@example.com... done.

The notification you receive will look like this:

 The WordPress installation on host example.com needs an update:
 
   Installed Version: WordPress 2.5.1
                  at: /var/www/myblog
 
      Latest Version: WordPress 2.9.1
            Download: http://www.wordpress.org/latest.tar.gz

As cronjob

If you want to be notified as soon as a new version comes out, installing a cronjob is a good idea. Simply run crontab -e and add the following line to the file:

0 6 * * * /usr/local/bin/wp-un /var/www/myblog admin@example.com

WP-UN will now run every morning at 6am and notify you if a new WordPress version is out there!

Conclusion

WP-UN is just one of many solutions and it’s only the work of one afternoon. However, it doesn’t need any additional software and keeps it simple. It serves its purpose and keeps my WordPress installation always up-to-date. If you have any suggestions or questions, feel free to comment below.

I have always wondered why most ESPs don’t offer greylisting for their mailboxes, but only rely on less effective and resource-hungry post-retrieval filter methods. Unfortunately, my e-mail provider is one of them so that I get at least a couple of spam mails a day …

Luckily, it is very easy to set up your own mail relay with greylisting support, i.e. a mail server that simply forwards the mail to your real provider once it passes the greylist-filter.

This little tutorial describes how to set up Postfix and SQLgrey as mail relay.

1. What you need

• A dedicated or virtual private server with SSH root access.
• Access to the DNS entries of your domain for adjusting the MX record; in this post called example.com

2. How it works

If you have outsourced all e-mail services to a service provider like I have, the MX record of your domain usually points to your provider’s mail server. That is, your mails go directly to the mail server of your provider, e.g. Google’s mail server → your provider’s mail server. That is, your DNS configuration looks something like this:

$ dig example.com mx
...
example.com.		IN	MX	50 mx0.example.com.
mx0.example.com.	IN	A	(your provider's mail server IP)
...

In order to pre-process mails with greylisting and blacklisting, your server will handle mails as intermediary, i.e., mails will always traverse your server first; in the above case something like Google’s mail server → your mail server → your provider’s mail server. Consequently, the MX record has to be changed to the IP address of your server:

$ dig example.com mx
...
example.com.		IN	MX	50 mx0.example.com.
mx0.example.com.	IN	A	(your server IP)
...

But, first things first: we need to configure our server before we change the DNS records!

3. Installation & Configuration

If you have a Debian based system, install Postfix, SQLgrey and MySQL using apt-get:

$ apt-get install postfix sqlgrey mysql-server

This will install:

• Postfix: a fully functioning MTA which will be configured as mail relay, i.e., instead of storing arriving mails on the system, it will just greylist them and then forward them to their real destination (your provider’s mail server).
• SQLgrey: a SQL-based greylisting add-on for Postfix. Before accepting mails blindly, Postfix will ask the SQLgrey daemon whether to accept the mail or not. SQLgrey keeps track of mail delivery attempts and only replies with success if the foreign MTA tried delivering the mail at least twice.
• MySQL: a RDBMS which will be used as back-end for storing Postfix’s routing tables and SQLgrey’s caching tables. Both Postfix and SQLgrey also support other back-ends such as PostgreSQL.

3.1. Configuring SQLgrey

SQLgrey’s config files reside in /etc/sqlgrey/, the main configuration happens in /etc/sqlgrey/sqlgrey.conf. The file is well documented and offers many possibilities.

The most important options are:

• inet: IP address and port to bind the daemon to, default is 127.0.0.1:2501
• db_*: database connection details, i.e., database, user and password
• greymethod: defines which IP class to use for greylisting. Especially important for big e-mail service providers since the same mail might be delivered from two different IP addresses (Class C greylisting recommended!).
• optmethod: defines if greylisting is enabled by default (optout), or has to be enabled specifically for each address or domain (optin).

3.1.1. Config file /etc/sqlgrey/sqlgrey.conf

My configuration looks like this:

inet = 10101 # bind to localhost:10101
reconnect_delay = 5 # no reconnect before 5 minutes
max_connect_age = 24 # no reconnect after 24 hours
 
# database settings
db_type = mysql
db_name = sqlgrey
db_host = localhost
db_user = sqlgrey
db_pass = sqlgreypassword
db_cleandelay = 1800 
clean_method = sync # 'async' is said to be buggy
 
# greylist by class C network. eg: 2.3.4.6 connection
# accepted if 2.3.4.145 did connect earlier
greymethod = classc
 
# one must optin to have its (incoming) messages being greylisted
optmethod = optin

3.1.2. Database

SQLgrey has a fixed database structure which is set up automatically when the script is started. All that needs to be done is to create a new database sqlgrey with a corresponding user. You can do this manually, or with a tool like phpMyAdmin:

CREATE USER 'sqlgrey'@'localhost' IDENTIFIED BY 'sqlgreypassword';
CREATE DATABASE IF NOT EXISTS `sqlgrey` ;
GRANT ALL PRIVILEGES ON `sqlgrey` . * TO 'sqlgrey'@'localhost';
FLUSH PRIVILEGES;

3.1.3. Populating the database

SQLgrey automatically creates the required tables when it starts for the first time. So start the daemon using the provided init.d-script:

$ /etc/init.d/sqlgrey start

This creates a couple of tables in the sqlgrey-database. For our purpose and configuration, the tables optin_email and optin_domain are most interesting because only domains and e-mail addresses in these tables will be greylisted.

For our example, we will enable greylisting for the whole domain example.com:

INSERT INTO `sqlgrey`.`optin_domain` (`domain`) VALUES ('example.com');

That’s it for SQLgrey. Once we connect it to Postfix, it’ll provide us with the greylisting service we want.

3.2. Configuring Postfix

Postfix is a very flexible and powerful mail transfer agent (MTA) and can be used as final destination, or mail forwarder (mail relay). For this scenario, Postfix will be a mail relay which only forwards an e-mail if

• its recipient is listed in the database
• and it passes the greylisting-filter

The configuration files of Postfix reside in /etc/postfix/. The most interesting file for our purpose is /etc/postfix/main.cf.

In order to not be confused by all the more or less useful config parameters, the file shown here is minimal, i.e., you cannot remove any parameter without major consequences. Details to each of them can be found in the Postfix configuration man-page.

The most important parameters for the configuration as mail relay are:

• myhostname: this defines your hostname, i.e., in this case relay.example.com. Regarding the hostname, two things must be considered very thoroughly:
  1. The hostname must resolve to the IP address of your server, i.e., make sure you don’t state a fake host here. Postfix uses this value as HELO/EHLO identification, and some mail servers might reject your mails if this value doesn’t resolve to your server’s IP address.
  2. If you use your top level domain here, e.g. example.com, some mail servers might additionally perform a MX lookup and match your server’s IP address with the one of the MX record. In case the MX record points to a different IP address than the A record of the TLD, foreign servers might also reject all your mails. In my case, this resulted in log entries like this:

     postfix/smtp: to=<john.doe@example.com>, 
       relay=mx.my-esp.tld:25,  status=bounced 
       (host mx.somedomain.com[1.2.3.4] refused to talk to me: 
       550 Forged HELO: you are not example.com)

     As you can see, the foreign hosts suspected me of forging the HELO name, and denied relaying my mails.

• relay_domains: this option links to the database table relay_domains and defines the domains managed by this mail server. If a recipient-domain is not in this table, Postfix will reject the mail. For this example, the domain example.com must be added to this DB table.
• relay_recipient_maps: this option links to the database table relay_recipients and defines the e-mail addresses managed by this mail server. If a recipient address is not in this table, Postfix will reject the mail. This option is closely linked to relay_domains and will not work without it!

  In this case, only one address will be added to this table: john.doe@example.com.

• transport_maps: this option links to the database table transport and defines to which mail server incoming mails will be forwarded. Routing can happen address- or domain-based.

  In this case, mails for example.com shall be forwarded to our provider’s mail server, i.e., this table must have an entry of the form example.com → smtp:[mx.my-esp.tld].

  For details on the value format, read the transport man page.

• smtpd_recipient_restrictions: this is where the actual magic happens. This option checks the RCPT TO field of each incoming mail, i.e., the recipient, and then queries the greylisting service. Its options closely relate to the relay_*-tables from above:
  • permit_mynetworks allows local applications to send e-mails. If you have web sites running on localhost that may use e-mail, do not remove this option.
  • reject_unauth_destination queries the relay_domains SQL table, i.e., it checks whether a the incoming recipient domain is relayed by our server.
  • reject_unlisted_recipient queries the relay_recipients SQL table to find out if the exact address is relayed.
  • check_policy_service queries the SQLgrey daemon which in turn either allows or rejects the mail.

3.2.1 Config file /etc/postfix/main.cf

Here’s the minimal main.cf config file to make Postfix a mail relay with greylisting support:

# This is a minimal main.cf config file. Make sure to read the above 
# comments so you understand what each option means.
 
# server name; must resolve to your server's IP address
myhostname = relay.example.com
 
# avoid warning message 'dict_nis_init: NIS ...'
alias_maps = 
 
relay_domains = mysql:/etc/postfix/mysql_relay_domains.cf
relay_recipient_maps = mysql:/etc/postfix/mysql_relay_recipient_maps.cf
transport_maps = mysql:/etc/postfix/mysql_transport_maps.cf
 
smtpd_recipient_restrictions =
        permit_mynetworks,
        reject_unauth_destination,
        reject_unlisted_recipient,
        check_policy_service inet:127.0.0.1:10101

3.2.2. Database

Postfix is very flexible when it comes to address and route handling. In fact, its configuration doesn’t need a database back-end at all. However, using a SQL database makes everything much easier. I decided to use a very straight forward database structure which directly relates to Postfix’ configuration options.

First, create a database postfix and a corresponding read-only user:

CREATE USER 'postfix'@'127.0.0.1' IDENTIFIED BY 'postfixpassword';
CREATE DATABASE IF NOT EXISTS `postfix` ;
GRANT SELECT ON `postfix` . * TO 'postfix'@'127.0.0.1';
FLUSH PRIVILEGES;

Note: It is important that you use 127.0.0.1 as host, and not localhost, because Postfix runs in a chroot-environment and wouldn’t be able to access localhost.

After setting up the database, add the following three tables:

CREATE TABLE `relay_domains` (
  `domain` VARCHAR(255) NOT NULL,
  `active` enum('y','n') NOT NULL DEFAULT 'y',
  PRIMARY KEY  (`domain`)
);
 
CREATE TABLE `relay_recipients` (
  `email` VARCHAR(255) NOT NULL,
  `active` enum('y','n') NOT NULL DEFAULT 'y',
  PRIMARY KEY  (`email`)
);
 
CREATE TABLE `transport` (
  `pattern` VARCHAR(255) NOT NULL,
  `relay` VARCHAR(255) NOT NULL,
  `active` enum('y','n') NOT NULL DEFAULT 'y',
  PRIMARY KEY  (`pattern`)
);

In order to connect Postfix with the database, we need to create the three config files specified above: /etc/postfix/mysql_*.cf:

# /etc/postfix/mysql_relay_domains.cf
hosts = 127.0.0.1
user = postfix-read
password = postfixpassword
dbname = postfix
query = SELECT domain FROM relay_domains WHERE domain='%s' AND active='y'

# /etc/postfix/mysql_relay_recipient_maps.cf
hosts = 127.0.0.1
user = postfix-read
password = postfixpassword
dbname = postfix
query = SELECT email FROM relay_recipients WHERE email='%s' AND active='y'

# /etc/postfix/mysql_transport_maps.cf
hosts = 127.0.0.1
user = postfix-read
password = postfixpassword
dbname = postfix
query = SELECT relay FROM transport WHERE pattern='%s' AND active='y'

Before we can now start testing our server, we need to compile these config files to Postfix compatible lookup tables. Do that by running the following command:

$ postmap /etc/postfix/mysql_*.cf

3.2.3. Populate the database

Now we have to fill Postfix’ database with the domains and addresses we’d like to relay. In particular, that means we have to add example.com to relay_domains and transport, and the full addresses to relay_recipients:

INSERT INTO `postfix`.`relay_domains` (`domain` ,`active`)
   VALUES ('example.com', 'y');
 
INSERT INTO `postfix`.`relay_recipients` (`email` ,`active`)
   VALUES ('john.doe@example.com', 'y');
 
INSERT INTO `postfix`.`transport` (`pattern` ,`relay` ,`active`)
   VALUES ('example.com', 'smtp:[mx.my-e-mail-service-provider.tld]', 'y');

The entry structure for each table is different. Please refer to the Postfix manual for details (cp. transport, relay_domains, and relay_recipient_maps).

Note: the database structure above is not optimal since it requires redundant entries in three different tables. Even though the structure is not perfect, I have chosen this layout to make it easily understandable!

4. Test your server

After this short configuration period it’s now time to finally start the Postfix server:

$ /etc/init.d/postfix start

To make sure you didn’t make any mistakes in the configuration, you should now check the log files. Postfix and SQLgrey both use syslog so that you should be able to determine the system’s status like this:

$ tail -n 20 -f /var/log/syslog

If the log doesn’t show any errors, we can now try if everything works as expected. To do so, simply connect to the server from your home computer via telnet:

$ telnet relay.example.com 25
Connected to relay.example.com.
Escape character is '^]'.
220 relay.example.com ESMTP Postfix
HELO somebody
250 relay.example.com
MAIL FROM: some@address.tld
250 2.1.0 Ok
RCPT TO: john.doe@example.com
450 4.7.1 <john.doe@example.com>: 
   Recipient address rejected: Greylisted for 5 minutes

If Postfix replies with a 450 error code, i.e., relay temporarily denied, everything works just fine. On the server side, the log should output something like this:

postfix/smtpd: connect from 1-2-3-4.your-isp.tld[4.3.2.1]
 
sqlgrey: grey: new: 4.3.2(4.3.2.1), some@address.tld->john.doe@example.com 
postfix/smtpd: NOQUEUE: reject: RCPT from 1-2-3-4.your-isp.tld[4.3.2.1]: 
    450 4.7.1 <john.doe@example.com>: 
    Recipient address rejected: Greylisted for 5 minutes; 
    from=<some@address.tld> to=<john.doe@example.com> ....
 
postfix/smtpd: disconnect from 1-2-3-4.your-isp.tld[4.3.2.1]

Wait 5 minutes and try connecting again via telnet. This time, SQLgrey will detect that this is your second delivery attempt and add the sender e-mail and its IP address to the automatic white list (AWL). Postfix will accept your mail and forward it to your provider’s mail server (according to the transport-table):

postfix/smtpd: connect from 1-2-3-4.your-isp.tld[4.3.2.1]
 
sqlgrey: grey: reconnect ok: 4.3.2(4.3.2.1), 
    some@address.tld -> john.doe@example.com (00:22:42) 
sqlgrey: grey: from awl: 4.3.2, some@address.tld added 
 
postfix/smtpd: client=1-2-3-4.your-isp.tld[4.3.2.1]
postfix/cleanup: message-id=<201001...@relay.example.com>
postfix/qmgr: from=<some@address.tld>, size=422, ...
postfix/smtp: to=<john.doe@example.com>, 
    relay=mx.my-esp.tld[12.34.56.78]:25, status=sent, ...
postfix/qmgr: removed
 
postfix/smtpd: disconnect from 1-2-3-4.your-isp.tld[4.3.2.1]

5. Go live: change the DNS record

Play around a little and make sure that everything works as expected. If it does, change the DNS record like described above, i.e., set the MX record of the domains to be relayed to your server’s IP address.

Note: For the first few mails, you should definitely watch the logs. If anything goes wrong, you can always change back the MX record. But be aware that DNS changes might take up to 48h!

If you have any questions, please comment below. I am open for suggestions!

On my journey through the Web I looked into the details of various business notebooks. I stumbled across the Dell Latitude E6400, which looks nice and has everything I wanted. Unfortunately, it also seems to have problems with Ubuntu. In particular, the fan seems to run all the time (and not too slow, but very loud) – as many forum posts and user reviews prove [1,2,3,4].

Since I couldn’t find a solution, I decided to ask the Dell support via their support chat.

Update Nov/09: It appears that a BIOS update addresses the heat problem. Please refer to the community forum post (thanks to chato) for details.

Here’s what I found out. Note: This is a chat with the German Dell support from September 21, 2009, translated into English.

Me:
The Latitude E6400 has (like many forum posts say) a big problem with Ubuntu. In particular, the fan is always on and makes a lot of noise.

Agent:
Welcome to the Dell Chat.

Me:
Hallo. I’d like to know if there already is a solution for this problem. I was thinking about buying a E6400, but I couldn’t find any solutions for the fan/noise problem in Ubuntu.

Agent:
Since we do not support Ubuntu on this device, Dell does not work on a solution. Ubuntu is currently only supported on netbooks. There is no solution.

Me:
Okay. Do you think there will be a solution in the future? Is Dell planning to support Ubuntu on the E6400? Or never?!

Agent:
As I said, we don’t sell the device with Ubuntu.

Me:
Okay. Thank you for the honest answer. I’m gonna have to buy a Thinkpad then … Have a nice day.

Agent:
I’m sorry. But we don’t support Linux.

Me:
It’s not your fault. Thanks anyway. Good bye.

Agent:
I’m so sorry.

So the outcome is: The Dell Latitude E6400 doesn’t support Ubuntu and is NOT planning to solve the fan/noise problem.. That means, I’m gonna have to buy one of those ugly Thinkpads. But what other solutions are there?! None!

Even though this is a good idea for some situations, most of the times, it’s just annoying: Collecting ideas for seminar papers or a thesis, for instance, is almost impossible without being able to Copy & Paste certain paragraphs from the PDF.

Fortunately, Linux can solve this problem with a simple tool called pdf to text. This command line tool simply strips all text from the PDF file and saves it to a given text-file.

Installation

The tool is part of the package poppler-utils and can be installed via your favorite package manager, e.g. apt-get:

$ apt-get install poppler-utils

Extract text from PDF files

This is also pretty simple and the man-page gives the instructions: pdftotext [options] <PDF> [<text-file>].

$ pdftotext PDF-file-with-copy-and-paste-restriction.pdf

In case you’d like to perform this for every PDF-file in a folder (recursive search), simple do that:

$ find -name '*.pdf' -exec pdftotext "{}" \;

After executing the command, there will be a *.txt-file for each PDF file in the folder, – containing the plain-text of the corresponding PDF file.

This is where a password manager comes in handy: Open the password vault by typing in the master password, put in all you secrets and crucial information, save it and be happy. As if!

Almost every password manager I found on the Web was crowded out by details so that it took minutes to add a single account. What I wanted was something like a text-file with password — and that’s what I made: A simple command-line password safe.

How it works

Simsafe is nothing else but a simple Perl script wrapped around the symmetric encryption functions of GPG. Every box with GPG and Perl installed can hence use the script (= every linux box!). And even if the simsafe-script is not installed on the system, a simple gpg –decrypt FILE shows the plain text contents. That is, Simsafe files are nothing more but text-files with password!

Usage

It’s simple and really easy to use.
Syntax:

$ simsafe FILE

Create a new password safe file

$ simsafe mySafe
simsafe: Creating a new password safe 'mySafe'
simsafe: Please enter the new password: (type in your password)
simsafe: Please confirm the password: (confirm your password)
simsafe: Executing editor vi ...
  // VI or your favourite editor opens
  // and you can edit the plain text file
simsafe: Encrypting with GPG ...

Adding/Removing entries to the password vault

$ simsafe mySafe
simsafe: Please enter the safe password: (type in your password)
simsafe: Decrypting with GPG ...
simsafe: Executing editor vi ...
  // VI or your favourite editor opens
  // and you can edit the plain text file
simsafe: Safe unchanged.

Get it!

It’s a reeeaallly small script and this post is possible longer than the perl-file itself, but here it is. Simply download it, make it executable and put it somewhere in your PATH.

Download: Simsafe v0.1, Apr. 2009