This isn’t the first time tweetdeck appears on my gentoo box, however, it was the first time I was setting it on fluxbox instead of gnome. If you use gentoo you know that the first thing you need to get this app working is to get adobe’s air working. Even though adobe distribute a binary version (no .rpm or .deb), still it needs dpkg or rpm in order to work. For gentoo users what we’ve left is the sdk version of air.

I knew that some had already done the air-sdk install so there’s no point in re-troubleshooting things. A popular link for instance is this from flashinthepan, although it doesn’t center on tweetdeck, the concept is the same: Execute your AIR app through air’s sdl.

Now, here’s the interesting part. There’s already a working ebuild for air-sdk in the sunrise overlay (dev-util/adobe-air-sdk-bin), but I didn’t want to set up layman yet (compiling subversion and git for layman in my decade-old PC is kinda PITA), so I went all manual.

First, a dir for air’s sdk:

# mkdir /usr/portage/dev-util/adobe-air-sdk-bin

A dir for ${FILES}:

# mkdir /usr/portage/dev-util/adobe-air-sdk-bin/files

Three files from this bug report, namely: adobe-air-sdk-bin-1.5.3.ebuild, adobe-air-sdk-bin.xml and airstart.desktop. The ebuild goes to the adobe-air-sdk-bin directory and the others go to the files directory. An interesting note though; while trying the installation, the ebuild failed two times because of errors related to airstart not being found. It turned out that the ebuild expected a file named airstart and another named airstart.desktop, thus, you’ll need a copy with both names on the files directory (just cp airstart{.desktop,} and you’re done). After having the files, just put them where they’re expected:

# cp adobe-air-sdk-bin-1.5.3.ebuild /usr/portage/dev-util/adobe-air-sdk-bin/
# cp adobe-air-sdk-bin.xml /usr/portage/dev-util/adobe-air-sdk-bin/files/
# cp airstart /usr/portage/dev-util/adobe-air-sdk-bin/files/
# cp airstart.desktop /usr/portage/dev-util/adobe-air-sdk-bin/files/

Then, digest the ebuild:

# ebuild /usr/portage/dev-util/adobe-air-sdk-bin/adobe-air-sdk-bin-1.5.3.ebuild digest

And then install:

# emerge adobe-air-sdk-bin

Now, here’s another interesting thing. For those installing on Gnome or KDE, until here you’ll be done with the installation, but if you don’t use any of those environments, you’ll need to do a few things before you can actually start tweetdeck (otherwise it won’t work).

It turns out that air gets confused if you start it on anything not being Gnome or KDE because a dependency with gnome-keyring or kwallet and environment variables related to this packages. I found that someone already documented the env variables but it’s up to you to figure out that if you’re like me, and have a very minimalistic install with no gnome nor kde things laying around, setting those variables won’t do much, you “need” to install either gnome-keyring or kwallet. Gnome-keyring doesn’t have as many dependencies with the gnome environment as kwallet with KDE has, so I take the gnome-keyring route.

Install gnome-keyring (with -nautilus USE if you want to keep everything slim as possible):

# emerge gnome-keyring

Set the environment variable in your .bashrc or in the system wide /etc/bash/bashrc:

$ echo "export GNOME_DESKTOP_SESSION_ID=1" >> ~/.bashrc

or

# echo "export GNOME_DESKTOP_SESSION_ID=1" >> /etc/bash/bashrc

Reload the profile:

$ source /etc/profile

I created a .desktop file so I could call TweetDeck from my Fluxbox menu, the only thing though is that if do something like this on your fluxbox menu (without a .desktop file):

[Exec] (TweetDeck) {/opt/Adobe/AirSDK/bin/adl -nodebug /opt/air-apps/TweetDeck/META-INF/AIR/application.xml /opt/air-apps/TweetDeck}

It won’t work, neither if you put this on a .desktop file:

[Desktop Entry]
…
Exec=/opt/Adobe/AirSDK/bin/adl -nodebug /opt/air-apps/TweetDeck/META-INF/AIR/application.xml /opt/air-apps/TweetDeck

The problem with both is that they won’t read the environment variable you set early, to workaround that I just created a simple bash wrapper named start-tweetdeck to call tweetdeck for me and made the .desktop file to call that wrapper instead:

#!/bin/bash
/opt/Adobe/AirSDK/bin/adl -nodebug /opt/air-apps/TweetDeck/META-INF/AIR/application.xml /opt/air-apps/TweetDeck &

The /usr/share/applications/TweetDeck.desktop file:

[Desktop Entry]
Encoding=UTF-8
Name=TweetDeck
Type=Application
Exec=/usr/bin/start-tweetdeck
Categories=Network;

And that’s pretty much it. The first time you start tweetdeck gnome-keyring will be called asking you to set a password for the gnome-keyring DB. You’ll also need to provide this same password every time you start tweetdeck.

Happy tweeting.

The Month of PHP Security was announced at the end of March if I recall right and submissions were accepted until mid April. In total, 13 articles and 60 vulnerabilities are the current result of MOPS.

If you haven’t checked out, I suggest you to. The articles are pretty good but I think the more valuables to be (my opinion of course): Virtual Meta-Scripting Bytecode for PHP and JS, How to manage a PHP application’s users and passwords,  Configuration encryption patch for Suhosin, and Generating unpredictable session IDs and hashes.

The bytecode article is a pretty interesting idea, using a VM that can parse PHP and JS in order to obfuscate payload code and execution. This is part of a project named EPHP-VM, currently hosted on the google code repository. The paper shows the design ideas, the concept of utilizing a VM running on top of the scripting environment and a few implementation details. It isn’t incredible complete but the hole concept of the project and the idea, is very interesting nevertheless, so check it out.

The paper about managing users and passwords is a very well thought and complete article. This submission goes from explaining why most common user/password management currently used are far from perfect, it explains several related concepts from hash and salting to stretching and cryptographic decisions. As far as implementation, the article centers on phpass which is a very nice little framework to help in the creation and verification of strong passwords. This definitively is a must.

For the configuration patch for Suhosin, more than the article itself what makes this a good submission is the feature which is talked about. If you ever created an application that had to store credentials to different services (like database access information) you know how difficult is to plan a good way to keep those credentials safe at the same time you make them available to the application that uses them. The feature described lets you put this credentials encrypted in your files and the key to decrypt them in the php.ini itself thus avoiding many of the concerns related to keeping the credentials secure. Of course, this isn’t a silver bullet, but sure as hell that is better than most current methods.

Finally, the article about generating more robust IDs and hashes is a very nice introduction to common problems regarding the randomness used by many applications. The article is more about hints than complete explanations but it serves as a guide for you to research more about it. The final implementation isn’t bad, although is some sort of “use this random generator + this other one if available + that other if it’s also available” which arguably might seem something like hash(“sha256″,(mt_rand().microtime())), however, the method described in the article achieve better randomness by using the functions and OS capabilities that offer the most unique values instead of pilling together a bunch of random data inside a hash function.

The other submissions have a value as well, in case you miss them, check them out. Also, a tweet from the MOPS account today mentioned that php-security.org will receive updates as time pass by, so keep checking the page or subscribe to the feeds, twitter account or whatever you prefer.

Since last week, many people wrote about some “exciting news” stating that Facebook was preparing changes for their privacy settings. To many people who read the stories, it seemed that Facebook does indeed care about your data and what you share and for days everybody was expectant on how this was gonna turn out.

Now there’s something more tangible to talk about this changes as Facebook started to roll ‘em out, but as others have already pointed out, there’s much much to be done in order for something as social as Facebook to provide privacy for its users and their data. Nothing stops you from enhancing your privacy using the controls though.

It seems that many people actually expected to Facebook change its business model, thing that is nothing more than a dream of course.

The changes introduced by Facebook as we know it right now are nothing more than a easy way to change what was already there. Instead of going through several menus and settings in order to make some information private, a new privacy control page is there to provide you easy access to those settings, but that’s about it. No new information constrains, no new private by default, nothing.

The critics about Facebook’s lack of interest regarding privacy have been about things like Connections, sharing with thirdy-party applications and connected websites, opt-out instead of opt-in, everything is public by default and everything is shared.

Now we have this new page to control who have access to what, but all the things that many criticized (Connections, sharing with external websites and so on) are still there. Whatever people criticized about Facebook data sharing practices still remains, thus, nothing change.

For those of you thinking about real changes on data privacy (on Facebook or online for that matter), stop dreaming. Facebook in particular have a very well known business model: Share everything you can with everyone. Mark Zuckerberg says that it isn’t about money, but even if that’s so, is a business model that shape what Facebook is today and is hardly going to change.

Your data is not your data anymore if it’s accessible online, deal with it, online privacy is dead.