Having a computer program communicate with the user in a clear, understandable and consistent way is a non-trivial problem to solve. In the Mac world, the Apple Human Interface Guidelines can help us a long way in presenting information in a format that is familiar for a Mac user. At the same time, a user may expect products from F-Secure to behave similarly across operating systems - an expectation that sometimes conflicts with our desire to fit into the environment. The Technology Preview of F-Secure Mac Protection shares a lot of UI elements with the similarly recent Internet Security Technology Preview for Windows.

Another obstacle is the position our user interface should take with regards of the surrounding environment. The kind of applications we typically develop usually do not require much user interaction - indeed, we even want to minimize user interaction whenever we can, since we don’t want to bother the user without good cause. A user probably expects a prominent notification when our product find malware on the disk, but is not that interested in a regular database update (they come several times per day on Windows platforms). At the same time, the user wants to be sure that the application is actually performing as expected.

In the Mac Protection Technology Preview, we went the way of not displaying any user interface elements at all unless the user explicitly launches our UI, or our on-access scanner has detected malware. We essentially treat the on-access scanning as a system service, that is always running in the background, invisible to the user. If the user is curious whether it is working correctly or not, he or she can launch the user interface from the Applications folder. However, it is clear from the feedback that some users have different expectations - there is a need of telling the user “yes, the product is installed and working OK” in a non-intrusive and lightweight manner.

In the Linux Security products, we have accomplished this with two small programs; one for KDE and one for GNOME, both fitting into the respective environment. In Windows, there is a system tray icon visible giving that kind of feedback. On Mac, the place to give such information is not as clear-cut. There has been considerable discussion about this in our team, and clearly our Technology Preview testers have some thoughts about this too (and, by the way, the feedback we’ve got from our Mac Protection Technology Preview is over-the-top awesome - we are really blessed with such enthusiastic and knowledgeable testers!).

In OS X, I personally feel that the Dock should be reserved for applications that the user interacts with on a regular basis. In an ideal situation, a user should not have to interact with our application in their day-to-day work - only in the rare event that malware is found or during installation/uninstallation et cetera should the user need to bring up our user interface. But as our feedback tells us, if there is no Dock icon visible, how is the user supposed to know that the product is running and functioning properly? One element of the Mac OS X Aqua UI is the “menu bar extras” that sit in the upper-right corner of a Mac, and in some ways it resembles the system tray in Windows. Some applications make their own menu bar extras, but this is strictly reserved for use by Apple according to the Human Interface Guidelines - so we would like to avoid it if possible. But what is there then left for us to use that could be very visible but at the same time non-intrusive? Some users seem to like the idea of having our application icon in the Dock all the time. Right now, we close the UI completely when the last window exits. This is consistent with the Apple guidelines, even though they give plenty of room for interpretation:

In most cases, applications that are not document-based should quit when the main window is closed. For Example, System Preferences quits if the user closes the window. If an application continues to perform some function when the main window is closed, however, it may be appropriate to leave it running when the main window is closed. For example, iTunes continues to play when the user closes the main window.

The way I see it, our user interface is like the Apple System Preferences in that its main purpose is to control the behavior of system services. However, I understand that one could argue that, like iTunes, since our products still perform some function even after the user has closed all its Windows, it should still remain active in the Dock. The upside of that approach would be that we could use the Dock icon to represent the status of the product.

We’re happy to receive any and all opinions our readers may have on this subject - please send them along to . And once again, thanks a million for the feedback we’ve already got - it is extremely useful in guiding us in the right direction as we take one step at a time towards a better user experience.

Last year, when we were writing a series of posts titled ”Stuff that works” (part 1, part 2, part 3, part 4), we were using a home-grown set of shell scripts to automatically build our software. Initially the scripts were run from cron every night, then later every hour and even later the script was triggered for every commit.

The autobuilder script worked, but we were missing features like IRC notifications, triggering builds from a web page and IRC and statistics. We would also have liked to have a history of builds combined with the test results of every build.

We were already setting up a MySQL database for builds and test results when we discovered that Continuous Integration is actually a hot topic these days and there is plenty of software available to help you with it. We eventually decided on software called Hudson.

Hudson is open source software and it is under active development by a large and growing community.
Hudson is written in Java and packaged so it can be set up easily and quickly. Basically you download the hudson.war file and run it: java -jar hudson.war

That’s it! Then you point your browser to port 8080 on that host and you have a pretty Web UI for setting up, managing and monitoring of various build jobs.

In a nutshell a job consists of following steps:

Poll a version control repository for changes.

Check out the source to a workspace directory.

Execute a build script.

Archive build results from workspace (or build artifacts like Hudson calls them.)

(Optional) pick up test results from XML files in workspace.

Each build of each job has a nice web page showing if the build was successful, when it was run and how long it took. The build artifacts can be downloaded from the same page and you can also inspect the test results.
You can configure a job to trigger one or more other jobs. For example, when the job that builds F-Secure Mac Protection finishes successfully, we have set it to trigger 2 other jobs: Installtest and Smoketest.

A job does not have to build software. Hudson does not care what the build script does. The build script in Installtest downloads the last successful build artifact from the job that launched it and installs it on a Mac mini running on a side table in the corner of the team room. Then it makes couple of simple checks and uninstalls the software. The result of this run is recorded in an XML file in the JUnit format. When the build script exists successfully, Hudson reads the XML file and stores the test results.

Hudson executes the Installtest parallel with the Smoketest job. Smoketest takes much longer to run (about 7-8 minutes), which is why we have the Installtest to provide us fast feedback in case we break something. Smoketest is similar to Installtest, except it runs many more tests.

We have also a number of other jobs, which are triggered by the Smoketest: Fulltest (runs all the tests taking about an hour), Upgradetest (runs upgrade from previous version and all tests from fulltest) and Performancetest (runs a set of common user tasks, measuring the time it takes.)

As you see, it is a good practice to split long jobs into multiple smaller jobs that run quicker. The quicker a job runs, the faster you get to know if you broke something and the faster you can fix it.

Hudson also has a whole lot of plugins that can be used to enhance and extend the basic functionality. There are plugins for supporting most of the popular version control systems and plugins to analyze source code and create reports and lots more. (And there is a plugin for IRC too.)

If you are doing continuous integration you could do a lot worse than use Hudson to help you. I definitely recommend you check it out.

The team hit a major milestone last week: technology preview of F-Secure Mac Protection.

The team is now called ”Mac & Linux team” and we’re taking care of all F-Secure Linux software and also the new Mac software. Mac OS X is, after all, a UNIX system under the pretty user interface.

We are considering whether we should post also Mac-related articles here on the Linux blog or not. We love Linux as much as we love the Mac, but maybe our readers are only interested in one or other. Please tell us what you think by email to

Last month we released a beta of Internet Gatekeeper for Linux. Now it has reached maturity and we’re announcing its general availability. Internet Gatekeeper is a stable multi-purpose virus scanning proxy that supports the FTP, SMTP, POP3 and HTTP protocols. As mentioned before, the Internet Gatekeeper now builds upon the same foundation as our product Linux Security, enabling us to provide fast and effective updates. IGK supports several modes of operation, including acting as a transparent proxy, a reverse proxy scanning incoming files in HTTP PUT or POST request, as well as chaining with other proxy software such as Squid.

Please download your free 30-day trial from our main website. Check our support pages if you have any problems, and in particular, try searching our Knowledge Base articles.

We are now releasing a new beta version of our Internet Gatekeeper for Linux. This version contains several architectural improvements and utilizes the same core components as our Linux Security 7 product. More information can be found in the release notes and manual within the product package.

Without further ado - please download and give it a spin on your test box :). And, as always, do drop us a note about your experiences with the beta!

Product package:
f-secure-internet-gatekeeper-for-linux-3.02.1164-beta.tgz (MD5, SHA1)

A new version of Linux Security 7 is available. Please find the product package here:

f-secure-linux-security-7.02.73807.tgz (MD5, SHA1)

This release contains several bug fixes. For example, scanning speed for certain types of archive files has been improved, and the automated command-line-only installation now works properly. Have a look at the release notes for a more in-depth view of what has changed.

Please note that from now on, the product manual will be available for downloading separately, which makes it easier for us to keep it up to date. You can find it on the F-Secure Product Manuals web page, as well as here.

We recently made a small new feature for the Rescue CD. One of our customers had problems with a system file that was renamed by our virus scanner, but the detection was actually a false positive. Problem was of course promptly fixed in anti-virus databases, but since the system file was renamed, the machines in question failed to boot. To help this customer we implemented a new feature for Rescue CD that allows the user to run repair scripts from a USB stick when booting with the Rescue CD. Since this feature might be useful in some other situations too, we decided to make a new public release. Here are instructions on how to use the feature:

1. Copy the script (repair_script.sh) onto a USB stick, in a folder called fsecure/rescuecd (for example, in Windows this might be E:\fsecure\rescuecd\repair_script.sh). The script must be called repair_script.sh, and if the script is from F-Secure, it should have an accompanying gpg signature file (repair_script.sh.sig) which should also be copied to the same folder.

2. Insert the USB stick in the broken computer and boot the computer using Rescue CD 3.01.

3. When Rescue CD asks which partitions to scan, there is now a new option to run the repair script. Select that, and which partitions you want to run the script on, and continue.

4. If the script is not from F-Secure or the gpg signature is not correct, the script will still be shown, but Rescue CD will display a warning and ask if you still want to run the script.

5. After the script has ran, the results will be displayed and you have the option to continue with a file system scan or reboot the computer.

Please note that this version only supports running the repair script before the actual virus scan. So if you must run a repair script after a virus scan, you should first boot and scan the computer, and then insert the USB stick containing the repair script and reboot with Rescue CD.

The new version can be downloaded here.

checksums for f-secure-rescue-cd-release-3.01-14505.zip:
md5sum: 5c2b86cdb11f9d1cade3243818afb7ca
sha1sum: 8eb21784e780222c1823c09d9e21ac577888ba4c

It seems that some people have experienced problems with Rescue CD not mounting NTFS partitions for scanning.

If you encounter a display that looks like this It means that the partition was not mounted for some reason. In this case only one partition - hda1, but it could be multiple partitions. If mounting failed because the NTFS partition was marked dirty (windows had not been properly shutdown), there are ways to try and fix this.

The Best solution in this case is to detach the network cable or disable wireless and boot the Windows preferably into safe mode by removing the CD and pressing F8 in boot sequence and selecting “Safe Mode”. After Windows has booted, select shutdown. After machine has turned itself off, attach/enable network and boot into Rescue CD.

However, if your computer is so badly infected that booting to Windows will not work or it gets hung up till infinity and beyond, you might be able to mount the problematic partitions for scanning with following procedure.

Press Alt-F2 and into command prompt type
root!tty2:/# grep scan /tmp/mount_error_details.txt

You should get the commands that you can try to use for mounting dirty NTFS partitions.
ie.
mount -t ntfs-3g /dev/hda1 /mnt/scan/hda1 -oforce
mount -t ntfs-3g /dev/hda5 /mnt/scan/hda5 -oforce

With the df command you can verify if the mount succeeded and also check the partition information (how big it is and how much of it is used/free)

After you have verified that the partition you wish to scan is mounted, press Alt-F1 and press
enter to verify next and continue with scanning process.

The workaround is a bit complicated, I know. We will try to fix the issue in the next version of Rescue CD.

We released F-Secure Rescue CD 3.00 beta two weeks ago. After one more development sprint, here’s the actual release of F-Secure Rescue CD 3.00 for you!

Rescue CD scans the computer and renames all files containing malware to .virus file extension.

• Rescue CD will by default scan:
  • all hard drives in the computer
  • all USB drives attached to the computer
  • Windows FAT and NTFS drives
• Virus definition databases are updated automatically if the computer has an internet connection
• Virus definition databases can be updated manually by using a USB drive
• The Rescue CD Guide (pdf) has step by step instructions how to use the CD

Rescue CD is localized to English only.

The release package including an ISO image, the manual and release notes can be downloaded here. See the release notes for more information. Feel free to send us feedback!

details of f-secure-rescue-cd-3.00-release.zip:
size: 153MB
md5sum: ed690b558493c3096bb666ea19749316
sha1sum: 71017c8325e90aaf19f8d2cb2f235519239384c2

The next version of F-Secure Rescue CD is going to see the daylight in few weeks. And here comes a feature complete beta for you to try. The big changes compared to 2.00 include a proper manual for the product, ability to update databases manually with a USB stick, better hardware support (Knoppix version 5.3.1), upgraded NTFS driver (NTFS-3G 1.2506) and the ability to detect MBR viruses.

The beta package including an ISO image, the manual and release notes can be downloaded here. See the release notes for more information. Keep the feedback flowing!

details of f-secure-rescue-cd-3.00-beta.zip:
size: 151MB
md5sum: 8a66ca08ccdcb4759fae6bc9ce1818df
sha1sum: abdec0cd567880170c6e5fea2c780c549d82730a