spass is a tool that creates cryptographically strong passwords and passphrases by generating random bits from your sound card. It works by passing noise from the sound card through a Von Neumann process to remove bias and then uses MD5 to “distill” a truly random bit from every 4 bits of input.

The new version of spass, version 3.1, was released two months ago. The code should now compile easily on both Linux (ALSA, OSS and PortAudio backends) and Windows (only PortAudio is supported). There is some minor tweaks to the CLI, but the main part is a new Qt interface, screenshots of it available on the project’s SourceForge page. I’ve also migrated the build system to CMake (from automake) which should make it easier to build.

You can download the sources, 64bit Debian package and binaries for windows from here. If you use spass and create binary packages for more platforms, it will be great.

BTW as you can see I’ve migrated the code to SourceForge from GitHub. I know it not a popular move, but their lack of binary downloads is really frustrating.

A possible solution to the eavesdropping problem, is to use SSL to secure the communication to the phpMyAdmin. However, SSL certificates don’t present any method to stop brute-forcing. To prevent brute-forcing attempts, you could limit access to your IP address. However, most of us don’t have static IPs at home. The solution I came up with, kinds of combines both approaches.

Instead of using SSL to encrypt the data sent, I’m using SSH and instead of limiting access to my IP address, I’ll limit access to the server’s IP address. How will it work? First we start by editing the phpMyAdmin configuration for lighttpd. This usually resides in /etc/lighttpd/conf-enabled/50-phpmyadmin.conf. At the top of the file you’ll find the following lines:

alias.url += (
        "/phpmyadmin" => "/usr/share/phpmyadmin",
)

These lines define the mapping to the phpmyadmin installation, without it the phpMyAdmin wouldn’t be accessible. We use lighttpd’s conditional configuration to limit who is able to use that mapping by changing the above lines to:

$HTTP["remoteip"] == "85.25.120.32" {
        alias.url += (
                "/phpmyadmin" => "/usr/share/phpmyadmin",
        )
}

This limit access to the phpMyAdmin only to clients whose IP is the server’s IP (of course you’ll need to change that IP to your server’s IP). This stops curtails any brute-forcing attempts, as only someone trying to access the phpMyAdmin from the server itself will succeed.

But how can we “impersonate” the server’s IP when we connect from home? The easiest solution would be to use to the SOCKS proxy provided by SSH.

ssh user@server.com -D 1080

This will setup a SOCKS proxy on port 1080 (locally) that will tunnel traffic through your server. The next step is to instruct your browser of OS to use that proxy (in Firefox it can be done via Preferences->Advanced->Network->Connection Settings, it can also be defined globally via Network Settings->Network Proxy under Gnome). This achieves both of our goals. We are now able to connect to the server while using its own IP and our connection to the server is encrypted using SSH.

This method can be used to secure all kinds of sensitive applications. We could have achieved the same thing by using a VPN, but it’s more hassle to setup compared to SSH which is available on any server.

I’ll describe using both to make encrypted incremental backups for both the files and the database (assuming mysql). If you’re using another database, like PostgreSQL, you could probably do something similar. We start by initializing a duply configuration for our new backup job:

$ duply my_blog create

This will create a duply profile directory ~/.duply/my_blog/. Unless otherwise noted, we will refer to files in that directory.

The next step is to edit the variables defined in conf file to suit your needs. The file is fairly documented, so it shouldn’t be a problem. I’ll walk you through the major things that need your attention and modifications.

The first thing which you will want to set is SOURCE to where your blog resided (e.g. /home/user/my_blog. We’ll also drop the sqldump of the database there, but more on that later.

TARGET determines where the backups will go to. Almost anything that comes to mind is supported: FTP, SFTP, SSH, Amazon S3 (my favorite), Ubuntu One, Cloud Files, loc files and even mail (and I haven’t listed everything). You should see Duplicity’s documentation on URL format for details on exactly how to specify it, as it is backend dependent. Some examples are:

file:///home/user/backups
ftp://example.com/backups
s3://s3.amazonaws.com/my_bucket/backup_dir

You should use TARGET_USER and TARGET_PASS to specify the username and password for authenticating the backend if necessary (if you are using S3 it will be your AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY respectively).

MAX_FULLBKP_AGE specifies how often should a full backup be preformed instead of incremental ones. Time format can be specified using values like 1Y, 3M etc.

You’ll want to set MAX_AGE and MAX_FULL_BACKUPS as this help you remove old incremental and full backups as they expire.

Last but not least, the GPG_PW and GPG_KEY are used to specify encryption passphrase and keys. If you don’t specify a GPG_KEY, the passphrase will be used for symmetric encryption. If you do specify, asymmetric encryption will be used. The config file duply created will have further information on more advanced configurations (like encrypting and signing with different keys, or encrypting but no signing so no private key is needed).

The next thing to edit is the exclude file and add patterns for files to ignore. If you use wp-cache or WP Super Cache you should do the following:

$ echo "**cache" >> ~/.duply/my_blog/conf

Until now we handled the backup of files, and nothing was WordPress specific. Save the next snippet under ~/.duply/my_blog/pre (taken from my Improved FTP Backup for WordPress script):

#! /bin/bash
 
umask 077
 
# Uncomment for duply >=: 1.5.4.2
# if [ "${CMD_NEXT}"  != "bkp" ]; then
# 	echo "Skipping, not running a backup"
# 	exit 0
# fi
 
 
DB_NAME=`echo "<?php require_once(\"${SOURCE}/wp-config.php\"); echo DB_NAME;" | php`
DB_USER=`echo "<?php require_once(\"${SOURCE}/wp-config.php\"); echo DB_USER;" | php`
DB_PASS=`echo "<?php require_once(\"${SOURCE}/wp-config.php\"); echo DB_PASSWORD;" | php`
DB_HOST=`echo "<?php require_once(\"${SOURCE}/wp-config.php\"); echo DB_HOST;" | php`
 
mysqldump --user="${DB_USER}" --password="${DB_PASS}" --host="${DB_HOST}" \
 --databases "${DB_NAME}" > "${SOURCE}"/dump.sql

The is will cause the script above to run before each backup. The script reads wp-config.php and dumps the blog’s db into a file called dump.sql in root directory of the blog. Now in order prevent accessing the dump file, black list it in the web server. If you use Apache, add the following to your htaccess

<files dump.sql>
Deny
</files>

If you use lighttpd, you can use mod_access to do the same:

url.access-deny            = ( "~", ".inc", ".sql" )

(this will block everything that ends with “.sql“, change this if it doesn’t suit you).

Finally to the backup itself.

$ duply my_blog backup
$ duply my_blog restore

The first will backup everything as you configured, making incremental and full backups as needed. The second restores the files to their original location. After restoring, you’ll need to manually import the dump.sql file. See duplicity and duply documentation on how to restore to other location, restore only specific files, etc.

Afterwards, on the phone, click on “Install from device storage” under Settings->Security->Credential Storage. If you did everything as you should at the previous step, it will display the certificate name, and ask you to confirm its installation. If you’ve exported the certificate as the wrong format, gave it the wrong extension or placed it somewhere else than the root of the internal storage, it will display the following error:

No certificate file found in USB storage

If you see it, just make sure you are exporting the certificate correctly and saving it at the right place.

More details: Work with certificates (Geared towards Galaxy Nexus, but should apply to any Android 4.0 and above.

Back in December, GitHub dropped their support for downloading files from outside the code repository. They say that they believe that code should be distributed directly from the git repository. This is probably fine for projects written in dynamic languages (such as python, ruby, javascript) where no binary distribution is expected. However, this seems to me like a blow to any GitHub hosted C/C++ project. No one expects lay users to compile projects directly from source, it a hassle for most people except developers (and possibly Gentoo users ).

It might be a good idea on GitHub team, as they promote themselves as a developer collaboration tool, and also most of their projects a indeed in dynamic languages (see the top languages statistics). The GitHub teams offers in their post two solutions: Uploading files to Amazon S3 and switching to SourceForge, and I’ve read at least a few people recommending putting binary releases in the git repository (bad idea).

Overall, I think this move by GitHub, just turned SourceForge into the best code repository (for compiled code) once again.

make CXX='~/.vim/bin/cc_args.py clang++'

However, the makefile generated by CMake doesn’t support the CXX configuration.

The solution is to call CMake with the CXX environment variable set:

CXX='~/.vim/bin/cc_args.py clang++' cmake ..
make

Note that this will create the clang_complete file in the build directory (I’ve assumed out-of-place build), so just copy over the file to the working dir of your vim so it can find it. You’ll need to re-run cmake again (without the CXX, to disable re-creating the .clang_complete file each time.

While looking for this solution, I’ve first tried solving it by setting the CMAKE_CXX_COMPILER variable in CMake, however for some strange reason it didn’t like it, saying that the compiler wasn’t found (it shuns command line arguments given in the compiler command).

The more I use clang_compelete the more awesome I find it. It has it quirks but nonetheless it’s much simpler and better than manually creating tag files for each library.

Luckily, the not-so-new C++11 provides, among other things, interface to high-precision clocks in a portable way. It’s still not a perfect solution, as it only provides wall-time (clock_gettime can give per process and per thread actual CPU time as well). However, it’s still nice.

#include <iostream>
#include <chrono>
using namespace std;
 
int main()
{
	cout << chrono::high_resolution_clock::period::den << endl;
	auto start_time = chrono::high_resolution_clock::now();
	int temp;
	for (int i = 0; i< 242000000; i++)
		temp+=temp;
	auto end_time = chrono::high_resolution_clock::now();
	cout << chrono::duration_cast<chrono::seconds>(end_time - start_time).count() << ":";
	cout << chrono::duration_cast<chrono::microseconds>(end_time - start_time).count() << ":";
	return 0;
}

I’ll explain a bit the code. chrono is the new header files that provides various time and clock related functionality of the new standard library. high_resolution_clock should be, according to the standard, the clock with the highest precision.

cout << chrono::high_resolution_clock::period::den << endl;

Note, that there isn’t a guarantee how many the ticks per seconds it has, only that it’s the highest available. Hence, the first thing we do is to get the precision, by printing how many many times a second the clock ticks. My system provides 1000000 ticks per second, which is a microsecond precision.

Getting the current time using now() is self-explanatory. The possibly tricky part is

cout << chrono::duration_cast<chrono::seconds>(end_time - start_time).count() << ":";

(end_time - start_time) is a duration (newly defined type) and the count() method returns the number of ticks it represents. As we said, the number of ticks per second may change from system to system, so in order to get the number of seconds we use duration_cast. The same goes in the next line for microseconds.

The standard also provides other useful time units such as nanoseconds, milliseconds, minutes and even hours.

The first step is to grab the 64bit deb package from Citrix website. Next install it using dpkg:

~$ sudo dpkg --install Downloads/icaclient_12.1.0_amd64.deb

This results in the following error:

dpkg: error processing icaclient (--install): subprocess installed post-installation script returned error exit status 2 Errors were encountered while processing: icaclient

Which can be fixed by changing line 2648 in /var/lib/dpkg/info/icaclient.postinst:

         echo $Arch|grep "i[0-9]86" >/dev/null

to:

         echo $Arch|grep -E "i[0-9]86|x86_64" >/dev/null

And then execute

~$ sudo dpkg --configure icaclient

Credit for this part goes to Alan Burton-Woods.

Next, when trying to actually use the Citrix Receiver to launch any apps, I’ve encountered the following error:

Contact your help desk with the following information: You have not chosen to trust "AddTrust External CA Root", the issuer of the server's security certificate (SSL error 61)

In my case the missing root certificate was Comodo’s AddTrust External CA Root, depending on the certificate used by the server you’re trying to connect to, you may miss some other root certificate. Now you can either download the certificate from Comodo, or use the one in /usr/share/ca-certificates/mozilla/AddTrust_External_Root.crt (they are the same). Either way, you should copy the certificate to the icaclient certificate directory:

$ sudo mv /usr/share/ca-certificates/mozilla/AddTrust_External_Root.crt /opt/Citrix/ICAClient/keystore/cacerts/

These steps got Citrix working for me, but your mileage may vary.

\documentclass{article}
\usepackage{amsmath,hyperref}
 
\begin{document}
\section{My Section}
\newtheorem{theorem}{Theorem}
\begin{theorem}[My Theorem]
\label{theo:My}0=0
\end{theorem}
This is a named reference: \nameref{theo:My}
\end{document}

You would expect the named reference to refer to the theorem’s name. However in reality it refers to the section’s name.

While searching for a solution I came across the following answer by Catalin in StackOverflow, which suggest it’s an old bug in nameref that (according to the mailing list conversation he linked to) should have been resolved in nameref-2.37. This is a conversation from 2010, but my Ubuntu 12.04 still has nameref-2.31 from 2007.

It seems like Ubuntu is a bit behind at updating TeXLive. I’m considering at installing off-the-repo TeXLive so I would have up-to-date TeX installation. I think I had in my two years ago more up-to-date version of TeXLive. Migrating to the official distribution would probably fix the Debian bug causing the installation of culmus-latex to fail as well.

But in the meantime I’ve looked for a workaround. After reading the nameref documentation, I concluded that the problem is that nameref doesn’t properly hook the theorem-like environments to set the \@currentlabelname. A possible workaround requires defining the theorem environment using thmtools. The thmtools gives us the \thmt@optarg command which expands to the name passed to the theorem environment, so we’re able to set \@currentlabelname properly. Basically, you need to add the following line after the \begin{theorem}[some name] and before the \label part:

\makeatletter \let\@currentlabelname\thmt@optarg\makeatother

A full example this looks like this:

\documentclass{article}
\usepackage{amsmath,thmtools,hyperref}
\declaretheorem{theorem}
 
\begin{document}
\section{My Section}
\begin{theorem}[My Theorem]
\makeatletter \let\@currentlabelname\thmt@optarg\makeatother
\label{theo:My}0=0
 
\end{theorem}
 
This is a named reference: \nameref{theo:My}
\end{document}

I think a better solution would be to automatically hook after the \begin{theorem} to add the fix. This is maybe possible using \addtotheorempostheadhook, but I haven’t figured it out yet.

Update 2012-12-16: I’ve installed the offical TeXLive 2012, and it was easier than I thought. It also, as expected, fixed the problem.

The new project management software gives SourceForge its much-needed update. A new code browsing design and ticketing systems are among the things that were updated. They even have some nice little features like syndicating a feed as the your project news on the project’s page.

Overall everything looks pretty nice, and it seems that finally SourceForge tries to stay competitive in the edge of GitHub. Despite the notorious user interface SourceForge had, I always kind of like it as it was there before others and it was one of places that got me started using and later developing open source programs. I really hope they keep up the good work and continue to improve it.