I’ve been given the chance to review the new Typo3 Multimedia Cookbook that Packt is publishing. Right now it should be in the mail on it’s way to me and hopefully will arrive in a week or so. After that, I’ll be enjoying some serious tech reading on Typo3 :) I found the Typo3: Enterprise Content Management book from Packt quite useful, so I’m hoping the Multimedia Cookbook will be even better – we’ll see. The description of the book certainly does inspire a certain appetite for reading:

The book gives you a step-by-step process for organizing an effective multimedia system. It also gives solutions to commonly encountered problems, and offers a variety of tools for dealing with multimedia content.

There’ll be a minor delay before the review goes online, though, as I’m off on holidays next week for two weeks – so I expect I’ll be done with the review start March or so. Come back for more reading then :)

Hot on the heels of yesterday’s User management fail post comes User management fail 2! More shocking discoveries! Blood! Gore!

Well, perhaps not, but still a fairly massive security fail.

Background

I’m interviewing for a project doing Zimlets for Zimbra and as part of the preparation I’m looking at existing Zimlets to see how they’re done (the Zimlets are located at gallery.zimbra.com should you be interested in having a look). One of the Zimlets I looked at seemed to have code useful to the project and I wanted to download it – but found no download button. Instead, I spied a login/register combo and figured I had to register first, which I then did. Back on the original page, I then tried to login with my new info.

Fail

When trying to log in, I got an error message, something about lacking permissions for a given area. Not a huge fail, but not really smart either (I registered using the button right next to the login button that doesn’t let me in – if I cannot register for the area the login button controls, then DON’T DISPLAY a register button there). No, the real fail lies with the error output – have a look at the image below:

It’s always good to have descriptive error outputs, and if you’re debugging stuff, then extra output is fantastic. But even though I have seemingly managed to get the ‘eleet’ ID, it’s less than stellar performance that they choose to tell me. And the fact that they’re outputting password hash is downright stupid. Though, of course, the password hash itself wouldn’t get you far, because at Zimbra, passwords are also protected by salts, making a bruteforce attack very hard … unless you know the salt. Which Zimbra happily displays right alongside the password hash on the login fail screen.

There is a factor mitigating this: the output is only displayed for logins that are successful, i.e. you actually have to know the proper user/pass combination to get it, so you cannot just start leeching password hashes from the site. The good news only goes so far, though: any man-in-the-middle has free access to all the data, as the login happens over http and not https.

Note: I have contacted Zimbra about this.

I recently subscribed gocomics/ucomics – wanting to get Doonesbury, Non Sequitur, etc by email delivery (I subscribe to the feeds but forget to read them). And I did finally get en email with Doonesbury … but as I didn’t get all the strips I wanted it was a failure. Not a failure worthy of a blog post, though.

However, trying to get out of the gocomics system has proven hard. The emails that gocomics send out do contain links both for unsubscribing and logging in, however:

• trying to unsubscribe yields: no success, something when wrong
• trying to login yields: username or password wrong
• trying to get a new password sent results in: email address unknown

Now, the fun part comes when you then look at the unsubscribe link in the email sent to you. Normally, for unsubscribe emails, you either expect username/email (insecure, but would work) or a temporary token (the norm). Here’s the link from gocomics:

http://www.gocomics.com/email_manager?user_code=abcdefghijklmnopqrstuvwxyz123456

Yup, that’s right. Gocomics keep sending emails to people without any way for them to unsubscribe. Something tells me this policy runs danger close of being spam … and that’s exactly what I’ve told Gmail that these emails are.

Sending out emails with broken unsubscribe links: fail!

Google announced yesterday that they will stop censoring search results on google.cn. There can only be one response to that: finally! It is definitely the right way to go, as the Chinese government is hell-bent on ignoring all concerns from foreigners (as well as from critical voices in their own country), meaning that any “influencing them slowly” is futile.

In Alarms in Ubuntu, I published a script that lets you set an alarm from the command line, nice and easy. One thing was lacking though: visual notification of the alarm, so if you happen to be away from the computer when the alarm sounds you’ll still see the dialog box. To achieve that I’ve modified the script, added an extra one, so here’s the new and shinier alarm script.

First, the alarm script:

#!/bin/bash
if [ "$1" = '' ]
then
    echo "No arguments for for alarm! Supply with time and optionally message
example:
    alarm 7:45
    alarm 19:59
    alarm '3pm + 3 day'
    alarm 2010-09-18
    alarm 'now + 5 minutes' 'go do ... stuff'
    "
    exit 1
else
    message="alarm time reached"
    [ "$2" = '' ] && message=$2
    if `echo aplay -q /home/fake51/Downloads/gqold.wav \&\& ddisplay \"$message\" | at $1 2>\&1 > /dev/null`
    then
        exit 0
    else
        echo "Setting alarm failed"
        exit 1
    fi
fi

Now, the major difference to the previous script lies in the script accepting a message, setting a default message, and then using ddisplay to display a message box.
Now, ddisplay is not a linux command – it’s the second part of this scripting excercise.

#!/bin/bash
if [ "$1" = "" ]
then
    exit 1
else
    export DISPLAY=:0
    zenity --warning --text="$1"
    exit 0
fi

This script makes use of the zenity command – which basically displays GTK+ dialogs. The ‘warning’ option makes zenity display a normal dialog box on top of everything, while the ‘text’ option is obviously the text to display. Hence, pass a text string to ddisplay and you’ll get a dialog box with it – and that’s what the first script does, thus playing the alarm sound and popping up a dialog box when the sound is done.
The reason for adding the extra script is that ‘at’ schedules commands to run – so putting the dialog box code in a function in the alarm script isn’t an option. One could try sticking the zenity command straight in the ‘echo’ piped to ‘at’, but to run ‘zenity’ from a script, you typically need to set a few environment variables (these are set if you run zenity straight from the command line, but not necessarily if run by cron or at). On the plus side, ddisplay can be reused for other scripts as well, simplifying them.