I hadn’t heard or seen anything from the Kopete devs yet, but I did ping Matt earlier this week to help spread the word to the rest of the project. Remember, this is an activity for you the developers, not me. I make myself available to answer questions and facilitate discussion, but the purpose of the user research profiles is to get developers more aware about their users. I will be at UDS next week and will be checking up on the Kopete User Research Profile once I get back.

Well, things have finally calmed down regarding the OpenSSL problems. Not that it’s necessarily bad to see that many posts and news. One can actually think it’s a good thing problems are addressed and discussed, but I was starting to get tired of reading nothing more than a bunch of complaints.

News flash: Shit happens!

I actually had a big text about the package maintainer, the severity of the problem, etc, etc, etc written, but it’s better to just be quiet, since I can’t do it any better.

Exploitation

After reading so much about it, I was intrigued on how super-easy-because-of-the-32,767-possible-outcomes to crack attack would work, and hdm (from Metaploit) answered them on a great paper:

http://metasploit.com/users/hdm/tools/debian-openssl/

The keys were generated and made available:

http://sugar.metasploit.com/debian_ssh_dsa_1024_x86.tar.bz2
http://sugar.metasploit.com/debian_ssh_rsa_2048_x86.tar.bz2

And a script to use them has been published to Metasploit:

http://milw0rm.com/exploits/5622

After giving it a try on a unpatched virtual machine, I understood the real severity of the problem.

There’s been a flurry of discussion around the idea of syncronicity in free software projects. I’d like to write up a more comprehensive view, but I’m in Prague prepping for FOSSCamp and the Ubuntu Developer Summit (can’t wait to see everyone again!) so I’ll just contribute a few thoughts and responses to some of the commentary I’ve seen so far.

Robert Knight summarized the arguments I made during a keynote at aKademy last year. I’m really delighted by the recent announcement of that the main GNOME and KDE annual developer conferences (GUADEC and aKademy) will be held at the same time, and in the same place, in 2009. This is an important step towards even better collaboration. Initiatives like FreeDesktop.org have helped tremendously in recent years, and a shared conference venue will accelerate that process of bringing the best ideas to the front across both projects. Getting all of the passionate and committed developers from both of these into the same real-space will pay dividends for both projects.

Aaron Seigo of KDE Plasma has taken a strong position against synchronized release cycles, and his three recent posts on the subject make interesting reading.

Aaron raises concerns about features being “punted” out of a release in order to stick to the release cycle. It’s absolutely true that discipline about “what gets in” is essential in order to maintain a commitment on the release front. It’s unfortunate that features don’t always happen on the schedule we hope they might. But it’s worth thinking a little bit about the importance of a specific feature versus the whole release. When a release happens on time, it builds confidence in the project, and injects a round of fresh testing, publicity, enthusiasm and of course bug reports. Code that is new gets a real kicking, and improves as a result. Free software projects are not like proprietary projects - they don’t have to ship new releases in order to get the money from new licenses and upgrades.  We can choose to slip a particular feature in order to get a new round of testing and feedback on all the code which did make it.

Some developers are passionate about specific features, others are passionate about the project as a whole. There are two specific technologies, or rather methodologies, that have hugely helped to separate those two and empower them both. They are very-good-branching VCS, and test-driven development (TDD).

We have found that the developers who are really focused on a specific feature tend to work on that feature in a branch (or collaborative set of branches), improving it “until it is done” regardless of the project release cycle. They then land the feature as a whole, usually after some review. This of course depends on having a VCS that supports branching and merging very well. You need to be able to merge from trunk continuously, so that your feature branch is always mergeable *back* to trunk. And you need to be able to merge between a number of developers all working on the same features. Of course, my oft-stated preference in VCS is Bazaar, because the developers have thought very carefully about how to support collaborative teams across platforms and projects and different workflows, but any VCS, even a centralised one, that supports good branches will do.

A comprehensive test suite, on the other hand, lets you be more open to big landings on trunk, because you know that the tests protect the functionality that people had *before* the landing. A test suite is like a force-field, protecting the integrity of code that was known to behave in a particular way yesterday, in the face of constant change. Most of the projects I’m funding now have adopted a tests-before-landings approach, where landings are trunk are handled by a robot who refuses to commit the landing unless all tests passed. You can’t argue with the robot! The beauty of this is that your trunk is “always releasable”. That’s not *entirely* true, you always want to do a little more QA before you push bits out the door, but you have the wonderful assurance that the test suite is always passing. Always.

So, branch-friendly VCS’s and test-driven development make all the difference.  Work on your feature till it’s done, then land it on the trunk during the open window. For folks who care about the release, the freeze window can be much narrower if you have great tests.

There’s a lot of discussion about the exact length of cycle that is “optimal”, with some commentary about the windows of development, freeze, QA and so on.  I think that’s a bit of a red herring, when you factor in good branching, because feature development absolutely does not stop when the trunk is frozen in preparation for a release. Those who prefer to keep committing to their branches do so, they scratch the itch that matters most to them.

I do think that cycle lengths matter, though. Aaron speculates that a 4-month cycle might be good for a web site. I agree, and we’ve converged on a 4-month planning cycle for Launchpad after a few variations on the theme. The key difference for me with a web site is that one has only one deployment point of the code in question, so you don’t have to worry as much about update and cross-version compatibility. The Launchpad team has a very cool system, where they roll out fresh code from trunk every day to a set of app servers (called “edge.launchpad.net”), and the beta testers of LP use those servers by default. Once a month, they roll out a fresh drop from tip to all the app servers, which is also when they rev the database and can introduce substantial new features. It’s tight, but it does give the project a lot of rhythm. And we plan in “sets of 4 months”, at least, we are for the next cycle. The last planning cycle was 9 months, which was just way too long.

I think the cycles-within-cycles idea is neat. Aaron talks about how 6 months is too long for quick releases, and too short to avoid having to bump features from one cycle to the next. I’ve already said that a willingness to bump a feature that is not ready is a strength and not a weakness. It would be interesting to see if the Plasma team adopted a shorter “internal” cycle, like 2 months or 3 months, and fit that into a 6 month “external” cycle, whether Aaron’s concerns were addressed.

For large projects, the fact that a year comes around every, well, year, turns out to be quite significant. You really want a cycle that divides neatly into a year, because a lot of external events are going to happen on that basis. And you want some cohesion between the parts. We used to run the Canonical sprints on a 4-month cycle (3 times a year) and the Ubuntu releases on a six month cycle (twice a year) and it was excessively complex. As soon as we all knew each other well enough not to need to meet up every 4 months, we aligned the two and it’s been much smoother ever since.

Some folks feel that distributions aren’t an important factor in choosing an upstream release cycle. And to a certain extent that’s true. There will always be a “next” release of whatever distribution you care about, and hopefully, an upstream release that misses “this” release will make it into the next one. But I think that misses the benefit of getting your work to a wider audience as fast as possible. There’s a great project management methodology called “lean”, which we’ve been working with. And it says that any time that the product of your work sits waiting for someone else to do something, is “waste”. You could have done that work later, and done something else before that generated results sooner. This is based on the amazing results seen in real-world production lines, like cars and electronics.

So while it’s certainly true that you could put out a release that misses the “wave” of distribution releases, but catches the next wave in six months time, you’re missing out on all the bug reports and patches and other opportunities for learning and improvement that would have come if you’d been on the first wave. Nothing morally wrong with that, and there may be other things that are more important for sure, but it’s worth considering, nonetheless.

Some folks have said that my interest in this is “for Canonical”, or “just for Ubuntu”. And that’s really not true. I think it’s a much more productive approach for the whole free software ecosystem, and will help us compete with the proprietary world. That’s good for everyone. And it’s not just Ubuntu that does regular 6-month releases, Fedora has adopted the same cycle, which is great because it improves the opportunities to collaborate across both distributions - we’re more likely to have the same versions of key components at any given time.

Aaron says:

Let’s assume project A depends on B, and B releases at the same time as A. That means that A is either going to be one cycle behind B in using what B provides, or will have to track B’s bleeding edge for the latter part of their cycle allowing some usage. What you really want is a staggered approach where B releases right about when A starts to work on things.

This goes completely counter to the “everyone on the same month, every 6 months” doctrine Mark preaches, of course.

I have never suggested that *everyone* should release at the same time. In fact, at Ubuntu we have converged around the idea of releasing about one month *after* our biggest predictable upstream, which happens to be GNOME. And similarly, the fact that the kernel has their own relatively predictable cycle is very useful. We don’t release Ubuntu on the same day as a kernel release that we will ship, of course, but we are able to plan and communicate meaningfully with the folks at kernel.org as to which version makes sense for us to collaborate around.

Rather than try and release the entire stack all at the same time, it makes sense to me to offset the releases based on a rough sense of dependencies.

Just to be clear, I’m not asking the projects I’ll mention below to change anything, I’m painting a picture or a scenario for the purposes of the discussion. Each project should find their own pace and scratch their itch in whatever way makes them happiest. I think there are strong itch-scratching benefits to syncronicity, however, so I’ll sketch out a scenario.

Imagine we aimed to have three waves of releases, about a month apart.

In the first wave, we’d have the kernel, toolchain, languages and system libraries, and possibly components which are performance- and security-critical. Linux, GCC, Python, Java, Apache, Tomcat… these are items which likely need the most stabilisation and testing before they ship to the innocent, and they are also pieces which need to be relatively static so that other pieces can settle down themselves. I might also include things like Gtk in there.

In the second wave, we’d have applications, the desktop environments and other utilities. AbiWord and KOffice, Gnumeric and possibly even Firefox (though some would say Firefox is a kernel and window manager so… ;-)).

And in the third wave, we’d have the distributions - Ubuntu, Fedora, Gentoo, possibly Debian, OpenSolaris. The aim would be to encourage as much collaboration and discussion around component versions in the distributions, so that they can effectively exchange information and patches and bug reports.

I’ll continue to feel strongly that there is value to projects in getting their code to a wider audience than those who will check it out of VCS-du-jour, keep it up to date and build it. And the distributions are the best way to get your code… distributed! So the fact that both Fedora and Ubuntu have converged on a rhythm bodes very well for upstreams who can take advantage of that to get wider testing, more often, earlier after their releases. I know every project will do what suits it, and I hope that projects will feel it suits them to get their code onto servers and desktops faster so that the bug fixes can come faster, too.

Stepping back from the six month view, it’s clear that there’s a slower rhythm of “enterprise”, “LTS” or “major” releases. These are the ones that people end up supporting for years and years. They are also the ones that hardware vendors want to write drivers for, more often than not. And a big problem for them is still “which version of X, kernel, libC, GCC” etc should we support? If the distributions can articulate, both to upstreams and to the rest of the ecosystem, some clear guidance in that regard then I have every reason to believe people would respond to it appropriates. I’ve talked with kernel developers who have said they would LOVE to know which kernel version is going to turn into RHEL or an Ubuntu LTS release, and ideally, they would LOVE it if those were the same versions, because it would enable them to plan their own work accordingly. So let’s do it!

Finally, in the comments on Russell Coker’s thoughtful commentary there’s a suggestion that I really like - that it’s coordinated freeze dates more than coordinated release dates that would make all the difference. Different distributions do take different views on how they integrate, test and deploy new code, and fixing the release dates suggests a reduction in the flexibility that they would have to position themselves differently. I think this is a great point. I’m primarily focused on creating a pulse in the free software community, and encouraging more collaboration. If an Ubuntu LTS release, and a Debian release, and a RHEL release, used the same major kernel version, GCC version and X version, we would be able to improve greatly ALL of their support for today’s hardware. They still wouldn’t ship on the same date, but they would all be better off than they would be going it alone. And the broader ecosystem would feel that an investment in code targeting those key versions would be justified much more easily.

I have been blogging for quite some time. During that time I have used blogspot.com, wordpress.com and now my own wordpress install. The main thing that has made me move from platform to platform is gaining more and more control over my blogging experience. With that said as of late I have been having some really problematic wordpress bugs.

1. Wordpress republishes my rss feeds when I edit my posts
   I expected this was being caused by the Simple Feed Copyright plugin so I have disabled it. I had a reason for installing it but I would much rather be able to edit my posts and I’m not so sure how bother I am by other sites ripping my content (I would still rather they did not however). Despite my best googling efforts I have still not solved this problem. Any ideas? Update: Yup this seems to have solved it!
2. Wordpress is no longer emailing me when someone comments on my blog
   Google did get me more information on this problem. But I have still not been able to solve it. Whenever someone comments on my blog I would like to be notified by email. Any ideas?

About my Setup

• Hosting Plan: 1and1 home linux
• Wordpress Version: 2.5.1
• Plugins:
  • Enabled:
    • AdSense Manager 3.2.13
    • Akismet 2.1.4
    • Google Analyticator 2.12
    • Google XML Sitemaps 3.0.3.3
    • SyntaxHighlighter 1.1
    • TagMahal - Automatic tag suggester 1.0.3
    • WordPress.com Stats 1.2.1
    • wp-cache 2.1.2
  • Disabled:
    • Hello Dolly 1.5
    • Simple Feed Copyright 1.0
    • Theme Switcher Reloaded 1.0
• Theme: SpotLight-Fluid 1.2 By Sadish

If I left out anything let me know. Hope you guys can help me.

• What's been happening for a better GUI on Windows
• What's new in the 1.4 release
• Importing from other VCS's with bzr fast-import

• CVS
  To convert from cvs, you currently use the cvs2svn converter. Which has a flag to generate a "fast-import" stream.
• Mercurial
  There is a script called hg-fast-export.py bundled with the plugin (in the exporters/ directory).
• SVN
  The svn-fast-export script is also bundled with the bzr-fastimport plugin.
• git
  Bundled with the standard git distribution is the git-fast-export command.
• Your own exotic system here.

It's been a long long time that I have not blogged...more than 2 months. I know it is bad.

Well to sum up I've been really busy with many stuffs : the Hardy release, some marvellous holidays all accross Mexico, lots of activities around ubuntu-fr and quite a lot of work for my company.

But I have to blog on the upcoming event : thanks to my company I am heading to the Ubuntu Developper Submit in Prague. It will be really great to meet all the guys with who I, try, to work dialy :) So if you see my face (and my 2 meters that might be with it) come and talk to me !

The recent OpenSSH vulnerability has left me pretty distraught. It really rocked my world… kinda like a “this is actual reality” moments I’m sure we all have every once and awhile where we discover these core ideas or beliefs we had held simply don’t hold up or shatter in the real world. I’m worried about what kind of impact this is going to have on Debian and Ubuntu’s image. What kind of new policies will crop up? What will happen to the credibility of open source software development? Have we shot ourselves in the foot? This vulnerability existed since 2006 and that flies right in my face because I’ve always talked about the “many eyes” principle and how because everyone sees the source code and people are inherently good, chances are the problems will get fixed before secretly exploited. Although I don’t know if this vulnerability has been exploited yet, I certainly don’t mean that big, fat, security issues like this get left in the code for several years when I’m talking to potential adopters of Ubuntu. Another way I relate to the problem is that a debian maintainer made this upload and he or she made a mistake - I’m always paranoid I’m going to make mistakes myself and to see something like this happen on the pretty much worst case scenario scale is rather horrifying to a degree…. Anyhow, I guess we can learn from this and move forward. Lets try and make this as positive as we possibly can, can we?

Anyhow, the real point of my post is to talk about a reply I saw on a Fedora forum the other day. An individual who was obviously new to the software he was trying to use had asked a question and someone replied to the effect “In the spirit of teaching a man to fish…. go google it”. The first question that popped into my head was “When you go to teach a man to fish, do you tell him to go fish or do you go actually show him and help him do it. You’d probably catch the first few fish to demonstrate, no?”. This leads me to believe that our policy regarding not telling people to “go google it” is an excellent one. By giving the answer (and often telling them *how* we got that answer), we provide the user with a number of valuable things: a) the answer they were looking for (which can relieve a lot of stress and anxiety for someone with a question they really want answered), b) a positive experience, c) an opportunity to build relationships with other members of the community, d) they start learning how to start finding and getting that information themselves. I believe if we all made an active effort to ensure we detail how we got our answers or where more information can be found on a topic we’d improve our effectiveness further; we’d be “teaching them to fish” and helping them become better netcitizens. So the next time someone gives you a hard time about how we deal with users, maybe you should point to this post and explain how you found it ;].

Anyhow, I haven’t slept since Tuesday night (so sorry if this post doesn’t make any sense, lol) and I haven’t been sleeping very well the last few days before that (maybe subconscious anxiety about going to Prague?). It is actually 6:30am here and I’m at work finishing up stuff so that I can minimize my anxiety of anything going wrong while I’m away from the office<g>. My flight leaves in 5 hours so I should probably get home ASAP and get to the airport soon. Oddly, I’ve been very calm and collective about the whole trip even though I know I’m eager and excited to be there. However, now that I’m only hours away from boarding the plane, I have to admit I’m starting to feel a few butterflies in my tummy. I suppose it has seemed so surreal thus far that I wasn’t phased but now t… I guess I’m having another “moment”, aren’t I?

Cheers.

And today, I finally turn 30. I've been grumpy about this day getting closer and closer for the last three or four years, which have passed in front of my eyes with me nearly not noticing.

The last year has had more downs than ups, and at times has been quite dark. I feel things are slowly getting better, and I spend more time looking forward than back, which certainly should help.

Tomorrow I'll hold a small party at home with some friends, but the big and proper event will be in September, when five or six people in our colla, born in 1978, will celebrate our 30^th birthday, in a massive, weekend-long party already dubbed La festa dels excessos. You shouldn't miss this one!

Thanks to the many people who have phoned, texted or emailed me already. It reminds me that I'm surrounded by people who love me and were there when I needed them.

OK, so the scenario is this…You are a new Linux user or want to try Linux, but would like to know more before hand. You hear about a local Linux Users Group and prior to going to one of their events, you sit back for a moment and try to envision what it would be like.

Tell me, what is that you envision?

Now that you have envisioned it, how would you really like the LUG to look, feel, and run?

The reason I am asking, is that the LUG in which I am the Vice President of is currently in the restructuring phase. I would like to get some ideas on how to make LUG meetings not only better, but make then accessible to every type of person that shows up.

So, if you have any suggestions, just add them to the comments. Thanks!

They call it a feature, but it’s really just a pain in the ass.

1. Make sure the project isn't already registered. A lot of upstream projects have already been registered in Launchpad, as it is used to track issues in Ubuntu. So it is always good to start on the main page and use the search box "Is your project registered yet?".
2. If you don't find your project, there will be a link to Register a new project
3. The form for filling out your project details has been updated a bit, but you should know the answers. (I still use 'bazaar' as the "part of" super-project, and bzr-plugin-name for my plugins)
4. This is where things start to get easier. After you have registered the project you can follow the Change Details link. This is generally https://launchpad.net/PROJECT/+edit. It was the same before, but now more information is on a single page, so you can set up more at once. Here I always set the bug tracker to be Launchpad, I click the boxes to opt-in for extra launchpad features.
5. Optionally you can assign the project to a shared group. Follow the "Change Maintainer" link (https://launchpad.net/PROJECT/+reassign). I generally assign them to the bzr group, because I don't want to be the only one who can update information.
6. At this point you should be able to push up a branch to be used as the mainline using:
   bzr push lp:///~GROUP/PROJECT/BRANCH
   in my example, this is lp:///~bzr/PROJECT/trunk. (You may need to run 'bzr launchpad-login' so that bzr knows who to connect as, rather than using anonymous http:// urls)
7. You now want to associate your mainline branch with the project, so that people can use the nice lp:///PROJECT urls. You can follow the link on your project page for the "trunk" release series (usually this is https://launchpad.net/PROJECT/trunk) On that page is a "Edit Source" link, or https://launchpad.net/PROJECT/trunk/+source.
   Set the official release series branch to your new ~GROUP/PROJECT/BRANCH.

Ok, so it seems that the whirlwind on OpenSSL has settled down a bit. Posts about it are coming from everywhere, ranging from rants on package maintenance to blame-pointing on both upstream and packager sides. And, of course, Slashdot.

Where does all this leave the end user with? Well, probably not much except to regenerate weak SSH keys with the new openssh-server (now enhanced with openssh-blacklist, see the new advisory) and hope to $DEITY all gets well soon. And maybe, just maybe, a minor suspicion that other Debian-packaged software may be "tainted" with a similar blemish (that being having patches that are supposed to fix something, applied with upstream's blessing, and yet not really audited enough to ensure functionality AND security of the system is maintained.)

Obviously, there's going to be some adjustments to be made on the Debian side. But I do hope to $DEITY that major revamps ought to happen on the OpenSSL side as well, in particular on clarifying their public channels to reaching upstream developers (read: publish openssl-team@openssl.org in a legitimate way, being the legitimate upstream contact endpoint it is,) and keeping a closer eye on the vendors who package their software (yeah, it may not be an obligation at all for OpenSSL, but heck, their vendors are users, too!) Upstream may be free not to partake on a social contract like Debian's, but it shouldn't escape from them the fact that vendors nevertheless aggregate continuing and potential users (aside from being users themselves) for their benefit.

More importantly though, is that delivering FOSS is a community effort. Sure, its easy to put blame now, but in the end, the blame isn't as important as the real cause and effects of the problem/bug/issue are. Better to move on and work together towards a real fix, rather than the bickering that currently passes as FOSS entertainment.

New toys at work:

Every mother loves her baby, every baby is valued and Mr Rudd should value all babies equally. We should not live in Australia where Mr Rudd thinks that some babies are more valuable than others. It’s very, very important that Mr Rudd understand that every mother loves her baby and this should be an Australia where all babies are equal. — Brendan Nelson, single-handedly raising the level of political discourse in Australia

(Blogging this in absolute surprise that the clip wasn’t already available on YouTube! Had to find and upload it myself. Lazyweb, where are you?)

Brendan Nelson’s Baby Equality Plea on YouTube

Yesterday evening I had the pleasure to pick up the following three security notices:

• [USN-612-1] OpenSSL vulnerability
• [USN-612-2] OpenSSH vulnerability
• [USN-612-3] OpenVPN vulnerability
  

I can tell you these are really not funny. They really generate a lot of work indirectly. Annoying but doable are things like regeneration SSH keys. The PITA situation is with OpenVPN, looks like we have the push new keys out to all the clients in a few setups. That really deserves a curse or two.

As a special bonus:

Once the update is applied, weak shared encryption keys and
SSL/TLS certificates will be rejected where possible (though
they cannot be detected in all cases). If you are using such
keys or certificates, OpenVPN will not start and the keys or
certificates will need to be regenerated.

Which means I am happy to read security notices. Just updating might result in a broken setup.

If anybody could give extra information on how weak those keys actually are and how easy they are to crack, I would be delighted. In the meanwhile, looking at the amount of servers, I guess I can schedule a teambuilding event where we can mass regenerate keys.

ps. I can tell you I’m quite happy that our backup machines which use SSH+RSYNC for automatic incremental backups are not vulnerable.

Update: I’ve been suffering some ungly and stupid bugs today, so I’ve fixed them and released version 0.2. It also includes a new script wp-update-home.

I’ve just published some scripts that help me manage my personal wordpress installations, and publish some plugins I’m working on.

Warning: these are early versions which I use for small tasks. If you find
a bug or have suggestions, contact me at jbernal@warp.es

Download version 0.1 version 0.2 or browse the wordpress-scripts git repository.

wp-dump

wp-dump helps you to backup your wordpress database. Just tell where is the wordpress directory and where to put the dump file

Syntax

$ wp-dump wordpress-dir outfile

outfile will be a gzipped SQL dump, so you should use the .sql.gz extension

wp-import

wp-import helps you to restore your wordpress database. Just tell where is the wordpress directory and where to read the backup file

wp-import expects the backup to be a gzipped dump

Syntax

$ wp-import wordpress-dir infile

publish.sh

publish.sh is useful if you:

• Manage your plugins with git
• Want to publish versions to a remote server using scp

Syntax

$ publish.sh plugin_name version

publish.sh will replace version numbers in your code (see Requirements), tag
the release with git, create a tarball and upload it to the specified server.

Requirements

First, you need a config file called ~/.wpplugins. An sample way to do this is

$ echo myserver.example.com:public_html/plugins/ > ~/.wpplugins

where myserver.example.com is your server and public_html/plugins/ is the
path (relative from your $HOME) to upload the tarballs

publish.sh can also replace version numbers in your plugin. It will detect these two cases

• Plugin header: Version 0.1
• Version constant: define(plugin_name_version, ‘0.1’);

wp-update-home

When you are syncing wordpress databases, one of the fundamental things to change is the siteurl and home options with the remote URL.

Syntax

$ wp-update-home wordpress-dir myhost.example.com

It’s been a while since I last released some open source project (beyond small patches) and it feels as good as ever

I’m sure many of you have heard by this point that there is a reported vulnerability in openSSL and openSSH.  The basis of this is that they keys that are generated when you use these tools (ie; installing openssh-server, etc) are generated in a weak manner and can be prone to simple brute force attacking.

If you’ve never installed openssh-server, used openssh-clients or generated an X.509 certificate you should be safe.  If you have done any of the above keep reading for a validation and fix instructions.  It can’t hurt to run the validation script in either case, just to be safe.

Security patches have been deployed to the Ubuntu archives so the first step is to, of course, apply any security patches available.

Am I Affected?

The first item at hand is verifying whether or not you have been affected by the vulnerability.  As mentioned above there are some common tasks that would qualify, but lets test your machine to make sure.

Download the script linked below and run it using the example syntax below:

dowkd.pl.gz (Download this file and unzip)

dowkd.pl PGP signature (Optionally verify the signature of the script)

Cut-n-Paste command-line example of downloading and running the test:

wget -c http://security.debian.org/project/extra/dowkd/dowkd.pl.gz
gunzip dowkd.pl.gz
chmod u+x dowkd.pl
./dowkd.pl user
./dowkd.pl host <hostname>

If you see output similar to:

/home/username/.ssh/id_dsa.pub:1: weak key

…then you have been affected by the vulnerability.  If you do not see “weak key” reported then you are OK.

How Do I Fix My Machine?

To update your machine and patch the vulnerability the first thing you want to do is check for and apply any system updates available.  The main Ubuntu archives have been updated with the fixes.  If you are using an alternate mirror the fix may not have propagated yet, so you may not see it available for another few hours.

Apply any updates:

sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade

You should see an update for openssl and openssh packages (along with anything else available).

After these new packages have been applied you’ll want to regenerate any keys that you’ve generated (ie; openssh keys, CA cert, etc).

UPDATE: The latest package release will automagically re-create any server-side ssh keys for you and notify you of the reason. Also, there is a new utility built into the latest release that will check keys for you. After your updates are applied try the tool:

ssh-vulnkey

To generate a new openssh key for your user: (This only required if ‘./dowkd.pl user‘ reports weak)

ssh-keygen -t dsa -b 1024

To generate a new openssh key for your server: (This only required if ./dowkd.pl host <hostname> reports weak)

sudo rm /etc/ssh/ssh_host_{dsa,rsa}_key*
sudo dpkg-reconfigure -plow openssh-server

You should now run the validation script again and make sure it does not report any errors.  If you still see reported warnings such as:

/home/username/.ssh/authorized_hosts:1: weak key

…this means that you have authorized_host keys saved that are still affected.  Open the .ssh/authorized_hosts file with a text editor and delete the affected line (:1: means line 1, etc).

Continue to run the ./dowkd.pl script until no weaknesses are reported.

These steps should be run on any system that you manage to ensure they are sufficiently patched.

Random Posts

• Microsoft: We won’t be evil, either
• A Little Help From The Readers…
• Use Evolution with Microsoft Exchange : Ubuntu (6.06 / 6.10)
• Synergy - share input between multiple machines : Ubuntu (6.06.1 / 6.10)
• Ubuntu 8.04 “Hardy” Alpha 4 Released
• **Ubuntu Tutorials domain transfer**
• United States of Ubuntu : State of the Union
• Save Bandwidth With Multiple Machines with Apt-Cacher : Ubuntu (6.10)
• Flock
• Support for Broadcom wireless : Ubuntu (6.06.1 / 6.10)

I got this here. I am sharing an abridged version. The original has some nice commentary. My version only includes the actual Gandhi quotes for each number.

1. Change yourself. “You must be the change you want to see in the world.” and “As human beings, our greatness lies not so much in being able to remake the world - that is the myth of the atomic age - as in being able to remake ourselves.”

2. You are in control. “Nobody can hurt me without my permission.”

3. Forgive and let it go. “The weak can never forgive. Forgiveness is the attribute of the strong.” and “An eye for eye only ends up making the whole world blind.”

4. Without action you aren’t going anywhere. “An ounce of practice is worth more than tons of preaching.”

5. Take care of this moment. “I do not want to foresee the future. I am concerned with taking care of the present. God has given me no control over the moment following.”

6. Everyone is human. “I claim to be a simple individual liable to err like any other fellow mortal. I own, however, that I have humility enough to confess my errors and to retrace my steps.” and “It is unwise to be too sure of one’s own wisdom. It is healthy to be reminded that the strongest might weaken and the wisest might err.”

7. Persist. “First they ignore you, then they laugh at you, then they fight you, then you win.”

8. See the good in people and help them. “I look only to the good qualities of men. Not being faultless myself, I won’t presume to probe into the faults of others.” and “Man becomes great exactly in the degree in which he works for the welfare of his fellow-men.” and “I suppose leadership at one time meant muscles; but today it means getting along with people.”

9. Be congruent, be authentic, be your true self. “Happiness is when what you think, what you say, and what you do are in harmony.” and “Always aim at complete harmony of thought and word and deed. Always aim at purifying your thoughts and everything will be well.”

10. Continue to grow and evolve. ”Constant development is the law of life, and a man who always tries to maintain his dogmas in order to appear consistent drives himself into a false position.”

I’ve just updated all my SSH keys, as everyone who is running a Debian-based system should. I’ve also changed the ports that SSH listens on on a bunch of systems, just to be safe, and to be a less obvious target to script-kiddies. Debian itself has also taken caution by disabling key-based logins to some developer services for now. If the changes I made caused any breakage for anyone, please let me know, and I’ll get it sorted out.

EDIT: As per https://lists.ubuntu.com/archives/ubuntu-security-announce/2008-May/000706.html , upgrading the package will test the sshd key, amongst other things.

It would appear that the openssl algorithm used to generate the ssh or ssl keys for Ubuntu and Debian isn’t as random as required to be secure, and is therefore vulnerable to brute force attack.

As outlined: http://www.ubuntu.com/usn/usn-612-1

Thankfully Debian security team have written a pretty nifty perl script to help find if your keys are weak!

So ensure you have upgraded to the latest libssl0.9.8 package (as outlined in the USN) then:

To test the public key fingerprint on a server, do the following:

$ wget http://security.debian.org/project/extra/dowkd/dowkd.pl.gz
$ gunzip dowkd.pl.gz
$ chmod +x dowkd.pl
$ ./dowkd.pl file /etc/ssh/ssh_host_{dsa,rsa}_key.pub 2>/dev/null

This will tell you if the public key is weak.  If it is, you should move/remove the key pair, then generate a new pair with:

$ sudo dpkg-reconfigure -plow openssh-server

Authorized keys, that can login using key based authentication.

$ ./dowkd.pl file ~/.ssh/authorized_keys 2>/dev/null

This will return any weak keys that are authorized to login using key based authentication, these entries should be removed and a new one generated and added to the file.

To see if your own user key(s) is vulnerable:

$ ./dowkd.pl file ~/.ssh/id_{rsa,dsa}.pub 2>/dev/null

If it is, you should remove the key - and create a new one using “ssh-keygen”,  and redistribute the public key (including to Launchpad)

NOTE: you should test all user keys on the system.  Might be worth saving any weak key’s, incase you do get locked out of a system.

Please pass this on to anyone using SSH.

EDIT: As per https://lists.ubuntu.com/archives/ubuntu-security-announce/2008-May/000706.html , upgrading the package will test the sshd key, amongst other things.

My pet project BillReminder was featured in the third episode of ProgBox, kicking off the brand new section “Pimp My Project“! It was also featured as an exemple on packaging software for Arch Linux (sorry, Brazilian Portuguese only) written by Hugo Dória.

So, watch the show, read the guide if you can, and use BillReminder!

I won't repeat it here, but there's DSA-1571-1 waiting for your attention, especially if you made some material out of openssl over the last couple of years or so. Yes, you read it right: COUPLE.

Upgrading to the new OpenSSL is easy. Generating new keys is another story.

To save (or add to, depending on how you handle this) your pain, there is a simple checker that can currently see if your OpenSSH or OpenVPN public keys are weak enough to warrant replacement. I await a version that can handle X.509 certificates too (though I only just generated a new one today, before the announcement, so that means I have to do it again (and get its CSR to CACert for signing, etc.)

And yeah, if you're running openssh-server, consider regenerating your host RSA and DSA keys, e.g.:

# mv /etc/ssh/ssh_host_{dsa,rsa}_key* /some/place/else
# dpkg-reconfigure -plow openssh-server

That should regenerate your keys and restart openssh-server once the new keys are installed to /etc/ssh.

The hard part (of making sure all the keys of your systems are updated and tested) is still up to you, however.

UPDATE: The Debian wiki has up-to-date information regarding other packages that generate SSH/SSL keys at postinst. Please refer to that while the key-rollover page isn't up yet.

UPDATE 2: openssh-server is updated (with corresponding DSA-1576-1) that is linked to the updated OpenSSL library. Be sure to upgrade! The new package also pulls in openssh-blacklist, a new package that contains the database needed by the new ssh-vulnkey for checking SSH public keys.

I am a huge fan of the google docs, In fact I am pretty much a fan of all of googles services. I love having all my information with me wherever I go and I am willing to “sacrifice” my privacy in exchange for that service. Anything really important and I will keep it on my own server but I am yet to have anything that I really worry about. That said some people might not want to use google to host there expenses, I do.

The great thing about using google docs to host my expenses is that I can add an expense from anywhere using the google docs form feature In the example I provided (Fake Expenses), I use the forum feature to add expenses on the road as well as getting real time updates about the amount of money I spend per day, week, etc.

If you would like to use my expense tracker you can view it here (Be sure to check all the sheets (Form, Overview, Worker, and Totals)), or download it here. Then simply upload it to your google docs and set up a form. Also feel free to play around and add fake expenses to the doc.

How do you track your expenses?

Update 01: Click here to get your own copy of the doc in your google docs. Thanks JR.
Update 02: Any idea why when I edit my posts they are being republished?

ssh-keygen -t dsa -b 1024 -f /etc/ssh/ssh_host_dsa_key -N '' &&
  ssh-keygen -t rsa -b 1024 -f /etc/ssh/ssh_host_rsa_key -N '' &&
  /etc/init.d/ssh restart

I really don’t think distributors should try to patch cryptographic stuff, especially not to silence debuggers.

Just read this and the security release. There is a checker provided in the security release note, but at any rate, your ssh key was probably generated incorrectly with respect to random time (mine were). Joy.

Update: Ubuntu Security Advisory.

Warning! Your ssh keys will stop working:
“Once the update is applied, weak user keys will be automatically rejected where possible (though they cannot be detected in all cases). If you are using such keys for user authentication, they will immediately stop working and will need to be replaced (see step 3). “

I primarily develop in Python these days, and have been giving Django a try. John Anderson posted a very detailed, excellent blog post about using VIM as a python IDE. If you follow that post, and use synic’s colorscheme, you pretty much have my IDE environment. I find this feature complete with any Visual Studio type program I have used, as long as you know a few vim commands you will be good to go.

I should also note, to install a plugin for vim, you just put it in your .vim/plugin directory. If that dir does not exist, just create it (mkdir -p ~/.vim/plugin)

One of the people I met at BarCampMiami was Anthony Bryan of metalinker.org, and he taught me about metalinks. What are metalinks? The description from metalinker.org is pretty interesting:

Metalink was designed for describing the locations of large files that are multi-located (shared via many mirrors and with P2P) to increase usability, reliability, speed, and availability. If a server goes down during a download, download programs can automatically switch to another mirror. Or segments can be downloaded from different places at the same time, automatically, which can make downloads much faster. Besides location, it also describes content. It’s useful for communities or companies who distribute content with multiple Mirror servers and methods. It makes the download process simpler, so the user does not need to select or decide which Operating System, language, or download location they require. Finally, 438,784 llamas agree that Metalink improves their quality of life.

Anthony reminded me today that the Ubuntu 8.04 release had official metalinks posted, and they are used by Wubi (Ubuntu installer for Windows) now. Turns out metalinks are popping up all over the place! They have their own mime type, and look pretty easy to implement. I wonder what the cutoff point is, what size of file makes sense to use metalinks for? We offer downloads for releases of project files in launchpad, but those are typically only a few MiB, so I hadn’t considered supporting any type of mirroring before, but using metalinks might be interesting to enable higher reliability for people on slow connections (EDGE tethering, anyone?)

Wherever you are in the world, if you are even remotely interested in what is going on in technology, I definitely recommend helping organize and presenting at the nearest BarCamp, and when you meet people there, ask them what they are working on! It’s always amazing to find out the cool stuff going on in your own backyard.

Mark Shuttleworth presented an interesting idea on his blog yesterday that I would love to see adopted. I think this would be a great benefit to the FOSS world, not just Ubuntu, and I hope that there is some interest among the Red Hat, Novell and Debian crowd, all of whom I respect very highly. The benefits of synchronization would be huge. For what it is worth, I vote a huge +1.

There’s one thing that could convince me to change the date of the next Ubuntu LTS: the opportunity to collaborate with the other, large distributions on a coordinated major / minor release cycle. If two out of three of Red Hat (RHEL), Novell (SLES) and Debian are willing to agree in advance on a date to the nearest month, and thereby on a combination of kernel, compiler toolchain, GNOME/KDE, X and OpenOffice versions, and agree to a six-month and 2-3 year long term cycle, then I would happily realign Ubuntu’s short and long-term cycles around that. I think the benefits of this sort of alignment to users, upstreams and the distributions themselves would be enormous. I’ll write more about this idea in due course, for now let’s just call it my dream of true free software syncronicity.

• Ubuntu, Fedora, OpenSUSE and OpenSolaris Community Managers — A Radio Free Software Interview - Barton, Fedora, Glynn Foster, Jono Bacon, Karsten Wade - “Barton moderates a discussion between Karsten Wade of Fedora, Jono Bacon of Ubuntu, Zonker Brockmeier of OpenSUSE and Glynn Foster of OpenSolaris. (44:08)”
• Ubuntu landed on Berlin metro system | Screenage - “The guys from “Berliner Fenster”, a company responsible for the content of the television system installed inside underground vehicles (more than 3.700 displays) were so kind (thank you!) providing us with a spot for our release party this Saturday for free. So just on time with the release starting from today there are small spots viewable by an audience of about 1.5 million people per day according to their web site.” See pictures of the ad.
• n00.be » Ubuntu in Vermist - “we present to you the Belgian movie Vermist where police detectives apparently use Ubuntu as their operating system of choice…”
• iTWire - Why we love Ubuntu Linux (or maybe we don’t) - “Ubuntu had all the signs of being the most unifying and popular Linux distro of all time, but on the other I kept finding people grumbling about it. On reflection, the grumbles may be because Ubuntu has been so massively hyped that the reality can be disappointing when compared to expectations. Perhaps Ubuntu has made itself a victim by virtue of its own marketing…”
• Why Brazil Loves Linux : Gustavo Duarte - “These markets are also friendly towards Linux and pose significant challenges for Microsoft. This post is my take on the reasons for Brazil’s fondness of Linux. I speak for Brazil since I was born and raised there, but I think much of this applies to the other BRIC countries and emerging markets in general.”

Taking the most amount of time get out the door so far it’s episode0.3 of pr0g80X.vid. This episode was a real nightmare to edit, however the end result means not only is it looking sweet, but also that I have a much firmer tool for working on 0.4.

In this episode we have,

• New Look
• News [01:26] - Short news segment
• Pimp My Project [03:28] - Bill Reminder gets the first PMP treatment
• Hugin [06:55] - Learn how to create stunning panoramics
• Beginning Python [15:13] - Book review on this little number
• Keyboard Hacking [19:24] - So just how does our faithful friend work
• Sign Off [26:37] - The usual see ya next time

Don’t forget we have the new site now with forums, and you can chat to us in #progbox on irc.freenode.net

Disclaimer
Though messing around with keyboards is fun, touch the wrong contacts and you could end up harming the keyboard, and indeed your PCs USB ports. pr0g80X.vid accepts no responsibility for equipment damaged through trying tricks shown in the show. You have been warned.

Thanks to everyone for watching and look out for episode 4 coming soon!!

Jos Poortvliet present some movies, which show some new features in KDE 4.1, especially in Plasma, Kwin, Dolphin, Gweniview and some other applications. This movies show imposingly the proceedings of KDE 4.1

new Plasma features
      
watch this movie on Youtube

new Kwin features
      
watch this movie on Youtube

new Dolphin features
      
watch this movie on Youtube

new Gwenview features
      
watch this movie on Youtube

new features (other apllications)
      
watch this movie on Youtube

You can watch this movies on Youtube or download them via Bittorrent to your pc.

KDE4 ROCKS!

Just to show how much work goes into producing a single episode of progbox. 2 hours of recording. 2 hours of sound and video support material. 5 hours in Cinelerra. And this is the result……

The Technology in Education (TIE) conference takes place each year in June in the mountains of Colorado. The conference is mainly aimed at Colorado educators, but there are always attendees from elsewhere as well. This year’s conference is June 24-27 at the Copper Mountain Resort.

Last year I presented a session on using free software and Ubuntu as