For 32-bit
$ wget http://www.skype.com/go/getskype-linux-beta-ubuntu-32
For 64-bit
$ wget http://www.skype.com/go/getskype-linux-beta-ubuntu-64

$ sudo apt-get -f install


Implementations and specifications have to do a delicate dance together. You
don’t want implementations to happen before the specification is finished,
because people start depending on the details of implementations and that
constrains the specification. However, you also don’t want the specification
to be finished before there are implementations and author experience with
those implementations, because you need the feedback. There is unavoidable
tension here, but we just have to muddle on through … I think we’re doing
OK.

I can agree completely. Waterfall model was yesterday.
You need the feedback from developers!

What Mozilla does OK should all other software development projects consider.

[1] http://lists.w3.org/Archives/Public/public-html/2010Jan/0107.html

Thank you guys for this helpful disclosure.

There is no clear information available today what was the root cause of the Atlassian security breach (published yesterday).

Today we got detailed information from Apache Infrastructure Team about the breakin at jira.apache.org:

1. We notified Atlassian of the previously unreported XSS attack in JIRA and contacted SliceHost. Atlassian was responsive. Unfortunately, SliceHost did nothing and 2 days later, the very same virtual host (slice) attacked Atlassian directly.
2. The attackers had root access on brutus.apache.org for several hours, and we could no longer trust the operating system on the original machine.
3. Service isolation worked with mixed results. The attackers must be presumed to have copies of our Confluence and Bugzilla databases, as well as our JIRA database, at this point.

UNBELIEVABLE!

What todo now:

1. Checkout all background information about this vulnerability of JIRA.
2. Check and Upgrade all non-internal JIRA and other Atlassian systems world-wide to prevent these attacks.

And we all should never forget:
Install 3rd party applications as root and run them as user with limited privileges.

[1] Apache Infrastructure Team Incident Report (13 Apr 2010) related to jira.apache.org
[2] Max on Improving Web Security: Six Ways the Apache.org JIRA Attack Could Have Been Prevented by Better Cod (13 Apr 2010)

Be aware that this security issue only affects Atlassian customers who created an Atlassian account and purchased one of our products before June 2008. Since then, we have been using a more secure user management system based on Atlassian’s Crowd product. When you change your Atlassian account password using the procedure below, your Atlassian customer account details will be stored in our updated Crowd user management system, which will further minimise the chance of a security breach occurring in future.

[1] Source: Jason Winder Webnet IT Blog: Atlassian Stored Passwords in Cleartext?

Just after this email it seems that most people were not able to retrieve Atlassian’s service to react.

Now after one hour there was no official statement of Atlassian!

Guys @Atlassian ! Please use Twitter or Uservoice to react in our real-time live and give us some background information!

Update 1:

[2] @atlassian on Twitter at 7 00 PM GMT replied:

Atlassian had a security breach. Apologies for the confusion. Our site is experiencing heavy loads. We are working on getting back up ASAP.

[3] Zoli Erdos at Cloudave: Atlassian Security Breach and Warning

Update 2:
[4] Atlassian’s Mike Cannon-Brookes initial customer feedback today morning

The legacy customer database, with passwords stored in plain text, was a liability. Even though it wasn’t active, it should have been deleted. There’s no logical explanation for why it wasn’t, other than as we moved off one project, and on to the next one, we dropped the ball and screwed up.
Disclosure: in terms of the security breach itself, we will disclose the various attack vectors and what happened once we have a full picture. Expect this in the coming week.

Looking forward to it, so everybody can learn from such IT security mistakes.

Since the migration to 64-bit Snow Leopard xpidl failed with the same bug as described on https://developer.mozilla.org/En/Gecko_SDK.

But i could not followed the solution described there, because in my environment it failed with a typical 32-bit / 64-bit architecture compilation issue:

build-xpt:
dyld: Library not loaded: /opt/local/lib/libIDL-2.0.dylib
Referenced from: /usr/local/xulrunner-sdk/bin/xpidl
Reason: no suitable image found. Did find:
/opt/local/lib/libIDL-2.0.dylib: mach-o, but wrong architecture
Result: 133

After a short Google search i found the solution Patko described on his blog.

It did not work for me from scratch. I run in a architecture dependency error again:

bash-3.2# port -f install libiconv +universal—> Computing dependencies for libiconv
—> Configuring libiconv
—> Configuring libiconv for architecture x86_64
Error: Target org.macports.configure returned: configure failure: shell command ” cd “/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_textproc_libiconv/work/libiconv-1.13.1-x86_64″ && ./configure –prefix=/opt/local –disable-dependency-tracking –enable-static –docdir=/opt/local/share/doc/libiconv –without-libiconv-prefix –without-libintl-prefix –disable-nls –enable-extra-encodings –disable-dependency-tracking ” returned error 1
Command output: checking for random.h… dyld: Library not loaded: /opt/local/lib/libintl.8.dylib
Referenced from: /opt/local/bin/grep
Reason: no suitable image found. Did find:
/usr/local/lib/libintl.8.dylib: no matching architecture in universal wrapper

Here is my simple modification to this solution to install libidl for both architectures (32bit und 64bit):

port uninstall gawk
port uninstall grep
port uninstall autoconf213

port install libtool +universal
(that also installs libiconv, gettext, grep)

port install gawk +universal

port upgrade –enforce-variants ncurses +universal
port upgrade –enforce-variants expat +universal
port install gettext +universal

port install libiconv +universal
port install glib2 +universal
port install libidl +universal

Running foxbeans build using xpidl is now successful.

build-xpt:
Copying 1 file to /Volumes/…
….
BUILD SUCCESSFUL (total time: 0 seconds)

So i get e.g. the German date format 07.02.2010 instead of 02/07/2010 in Orage calendar.

To setup mixed en_US and de_DE locale simple configure /etc/environment

LANGUAGE="en_US:en"
LANG="en_US.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_COLLATE="C"
LC_CTYPE="en_US.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"

see also:
[1] Ubuntu Wiki Locale Documentation

This little script uses the http://svn.automattic.com/wordpress/ as subversion base.
Today this location is not available and the update terminates with the following failure:

svn: PROPFIND request failed on '/wordpress/tags/2.8'
svn: PROPFIND of '/wordpress/tags/2.8': could not connect to server (http://svn.automattic.com)

Don’t know, if this is forever or a temporary failure.
If wordpress.org moved their svn repository to core.svn.wordpress.org completely, the wordpress wiki must be updated!

To update wordpress installations from the “new” core.svn.wordpress.org repository with wptool, some slight modifications are necessary:

1. go to wordpress installation directory and relocate the svn repository

cd /usr/local/your_wordpress_dir
svn switch --relocate http://svn.automattic.com/wordpress/tags/2.8 http://core.svn.wordpress.org/tags/2.8

2. update the wptool script

#svn_base='http://svn.automattic.com/wordpress/'
#lang_base='http://svn.automattic.com/wordpress-i18n/'
svn_base='http://core.svn.wordpress.org/'
lang_base='http://core.svn.wordpress.org/'

3. run the upgrade again

./wptool upgrade /usr/local/your_wordpress_dir
...
Updated to revision 11719.

Success!

See this info on sourceforge forum page.

Any legacy services that might have been hosted on nuclearelephant.com have been discontinued, in particular rabl.nuclearelephant.com

Solution:

simply remove from your postfix main.cf:
reject_rbl_client rabl.nuclearelephant.com

Let’s join the agile methodologies!!!

Nice presentation from Brazil:

Update: Found the way to embed slideshare doc, click on wordpress button below the presentation on slideshare and copy the [...] “link”.

Suddenly i found this simple solution: http://ubuntuforums.org/showthread.php?t=967049

apt-get remove flashplugin-nonfree
apt-get install ubuntu-restricted-extras


Works fine now. I can see all content from slideshare and youtube.