Future of Foresight Linux – Xfce Edition
There haven't been much updates on Xfce Edition for a while, becauseI was busy with re{decorating,novating} my apartment, planning my upcoming wedding, my job and so on.
Here are some News, I have changed Plans for Xfce Edition a little bit. So read on.
When I had a look at the plans for Xfce 4.6, I realized, that Xfce 4.6 might be closer than I thought (there will probably be delay, as it is software (think of gnu/hurd or dnf)). Anyways here is the new plan. It's pretty simple: "Concentrate on 4.6. Go with the Milestones and have a final shortly after Xfce 4.6 is released".
Some development will take place on xfce.rpath.org, to not break all the Xfce 4.4 things wie already have on foresight.rpath.org. There is a mailinglist too. Helping hands are welcome.
HTTPS is broken and Firefox 3 makes it worse
[Note: this is mainly a long rant. If you're just curious about my possible solutions, scroll to the last few paragraphs.]
I've been using the Firefox 3 betas (and now release candidates) for quite a few months now, and overall, I think it's a great improvement over Firefox 2. My main issues in the past with FF2 have always been with performance and memory usage, and FF3 seems to go very far in addressing both of these (though there's always still room to improve).
However, there's one thing I just can't get over: the SSL error pages. Before I describe FF3's added annoyance here, let me start by saying one thing: the HTTPS model is broken and much less useful than it could be.
Why?
Because the HTTPS/SSL model tries to simultaneously combine two things: encryption and authentication. When you visit a HTTPS site, you get an end-to-end encrypted connection between your web browser and the web server, obviously. But you also get something else, in theory: assurance that the web server on the other end is actually owned and operated by who it says it is. This is done through a hierarchical certificate signing scheme, wherein the browser knows a few "trusted" root certificate authorities (CAs), and any web server SSL certificate that wants to be considered "trusted" (as far as the browser is concerned) needs to ultimately be signed by one of those root CAs. (In practice, this doesn't mean each and every web server SSL cert needs to be signed by a root CA, just that every trusted SSL cert needs to be signed by another signing certificate that was signed by a root CA, or by another signing cert that is signed by a root CA somewhere in its ancestry.)
So where's the flaw? Getting your SSL cert signed by a trusted cert authority costs money. This is fine for banks, but not so fine for some random guy who just wants secure communications with his home server, or webmail, or just a small self-funded website where an encrypted connection makes sense. A semi-solution is self-signed certificates. You can create your own SSL certificate, and your web server will use it, and people who connect to your web server on the HTTPS port will get encryption. But, as far as the browser is concerned, your cert isn't signed by anyone on its trusted list.
So, the website visitor is usually presented with a confusing dialog box warning that the website they're visiting shouldn't be trusted. Visitors who understand all this stuff just roll their eyes, click the "allow" button and go on with their day. People who don't really understand all this, but just want to visit the site, blindly click "allow" and go on with their day. Some panicky users may freak out, click "cancel," and not visit the site.
The people in the middle there are the ones in danger. Blindly accepting dialog boxes just to get them out of the way can get you in trouble if the dialog box is actually warning you of something important. In the context of visiting Gentoo's HTTPS bug tracker website, the warning actually is unimportant: Gentoo is just using a self-signed cert to avoid paying for a "real" cert, and just wants HTTPS for the encryption, not for the authentication. However, in the context of Bank of America's online banking service (just to pick one), the warning is very important: it likely means that someone has intercepted your communications and is trying to masquerade as BoA's server so they can steal your bank account credentials. Or it could also mean you typed the URL incorrectly, and someone malicious has registered the typo-hostname in the hopes of snaring someone with careless fingers.
So there's a problem, definitely. The Firefox 3 developers have chosen to attack this problem by attempting to push people into the panicky-user camp, though they misguidedly believe that they're actually getting users to try to read the messages and make an "informed" decision (despite the fact that they haven't given -- and really can't give -- enough information to inform most users). The new SSL error pages in Firefox 3 put up a scary, confusing, uninformative message right inside the browser window. The message, at first glance, looks reminiscent of one of the several "connection error" messages, so the first reaction is to look up at the address bar to see if you typed the address correctly, and then wonder why the site is down. Then you go and read the error message. Basically, it says a lot of confusing things -- including a semi-raw error enumeration code that is sure to confuse the user even more -- with a very short explanation of the real problem: "The certificate is not trusted because it is self signed." What are the chances that the average user will know what this means? Slim to none.
Then there's some text about adding an exception, and instead of a button, a URL link (in a small font) that you can click to add an exception. Well, sorta. Clicking the link merely modifies the error page to display another semi-scary message, and then shows two buttons: one with a stupid caption: "Get me out of here!" (don't get me started on this one), and the other saying "Add Exception..." Ok, fine, so I click "Add Exception..." Now I get a dialog box, and my eyes automatically seek the bottom of the box, assuming the "confirm" button will be there, waiting for me to click. But it's not. It's there, but it's disabled. Huh? So I look up higher, and I see that only two buttons can be clicked: a "Cancel" button (well, duh, obviously that's not it), and a "Get Certificate" button. Ok, well, I guess I'll try that one. Now the text in the middle of the box changes to tell me "Certificate is not trusted, because it hasn't been verified by a recognized authority." What? I know what all this stuff means, and I have to read it twice to get it. Your average user doesn't stand a chance. Finally, though, the "confirm" button is active, and they've helpfully (wow, they actually did something remotely helpful here!) pre-checked the "Permanently store this exception" check box for me.
So, in total, I have to make four clicks, plus read a bunch of confusing terminology, to get to a website with a self-signed SSL certificate.
This sucks. The UI is absolutely terrible, and the average web user is going to have no idea what's going on. According to the Firefox developers, one of the goals of these new error pages is to cut down on "dialog box whack-a-mole" where users just blindly click to get the dialog out of the way. I fail to see how this is going to help. Some users will now get even more confused, and not visit the site. For the extremely rare case where a malicious site is masquerading as the site they actually want, this is good. But for the much more common case of an innocent site that just wants SSL for the encryption, this is bad. And for most of the users in the "blindly dismiss" bunch, they'll just get used to blindly dismissing this new page+dialog in record time.
What's the real solution? Ideally: scrap the current system. There's no reason why connection encryption needs to be so tightly coupled with authentication/identification. Design a new system, possibly with a new protocol scheme. One scheme should be used for "strong" security, where both the identity of the site and cryptographic strength of the connection are checked. The other scheme will just check the encryption. Users will need to be educated that you never try to connect to your banking site using the less-secure scheme. Sure, user education is always a problem, but it's a problem we still face with the current non-solutions in place.
Of course, in the real world, we can't just scrap a protocol that has been in use for over a decade, and expect everyone (web servers, web browsers, the cert-signing industry) to change overnight -- or at all.
So I'd advocate dropping all the panic about self-signed certs and, in addition, handling HTTPS sites by keeping more state about them in the browser. For starters, at the simplest level, let's stop putting up scary messages when we hit a self-signed site. We're already coloring the address bar differently for HTTPS sites; why not have a different (slightly scary?) color for HTTPS sites that use self-signed certs? There could even be an easily-disableable bubble popup (that doesn't take focus!) that points out the "problem" and is clickable for more information. Or something like that. At minimum, if you visit your bank site all the time and don't see this warning and color change, you'll think twice the time you do.
But to make this stronger, the browser can keep state about the HTTPS sites we've visited. Odds are, the first time you visit your banking site, it'll probably be all correct and proper. So the browser notes the cert's fingerprint, and the fact that it's signed by a "trusted" authority, and checks it every time you visit the site. If the cert changes, and is now self-signed, the browser can raise a larger red flag: "Hey, this site that you visit all the time that usually has a trusted cert? Well, the cert is now self-signed and this might be someone trying to trick you."
What about "phishing" attempts that use common misspellings? Well, if the browser knows that I've visited https://bankofamerica.com/ in the past, and it had a valid, trusted cert, and now I've visited https://bankofamarica.com/, and it not only has a self-signed cert, but has remarkably similar spelling to another site I visit that has a trusted cert, the browser can raise another big red flag. Finding similar spellings is nothing new: there are algorithms to do this that are old and very well-established.
How about phishing attempts that hide the true website URL by using an inline username/password string that looks familiar to the user? Well, we already cover this: Firefox pops up a dialog asking if you really want to connect to the site, presenting the real hostname, and showing the username passed in the URL. So, this new scheme doesn't harm this case's solution.
End rant.
WordPress 2.5.1 hates mod_security, sorta
I upgraded to Wordpress 2.5.1 a few weeks ago. Overall, it seems pretty nice.
Friday, everything was fine. Saturday, I tried to make a post, but when I clicked the "Publish" button, I got a blank webpage. Suck.
So I spent a couple hours (ugh) tracking the problem down today, and finally discovered this in the Apache error log:
[Sun May 25 14:41:59 2008] [error] [client 24.130.18.75] mod_security: Access denied with code 503. Unknown error [severity "EMERGENCY"] [hostname "spuriousinterrupt.org"] [uri "/journal/wp-admin/admin-ajax.php"]
Not a particularly useful error message. Fortunately, my web host (Dreamhost) allows me to disable mod_security on a per-domain basis, so I tried that, and voila, everything works fine. Presumably my web host upgraded mod_security, or changed its configuration, sometime between Friday and Saturday which broke things, as I didn't change anything with Wordpress or my website.
So, if Wordpress breaks for you at some point, be sure to check your mod_security configuration, or temporarily disable it entirely to see if that's the problem.
Hopefully Dreamhost can help me find a better solution than disabling it entirely...
Cubit
Yeah, Cornell CS students! I'm proud of you guys. Looks like my old Operating Systems professor (Prof. Sirer) is involved as well. Cool.
Sharing the love with BitTorrent
Xubuntu 8.04 is out! This release, along with those of Ubuntu, Kubuntu and whatnot, means that the Ubuntu servers are going to have a hard time with everybody and their stork downloading these new releases at the same time. Being the good open source citizen that you are, you are probably more than willing to take some of the load. Look no further, as BitTorrent is here to save the day!
In short, BitTorrent allows you to download files from other people, meanwhile sharing the parts you have already downloaded with other people who, just like you, are eager to try out the latest and greatest the open source community has to offer.
To download files using BitTorrent, you need a BitTorrent client. Since Xubuntu 8.04 includes Transmission, that is what we will be using. If you’re not using 8.04, make sure to install it.
The first thing we need, is a torrent file, a file with a name ending in .torrent that contains all the information Transmission needs to download the appropriate files. The Xubuntu 8.04 torrent can be downloaded from Ubuntu’s torrent website, where you can select the graphical Desktop CD (which is what most people want) or the text-based Alternate Install CD. We want the torrent files for Intel x86 architectures (most computers) or for AMD64 architectures (you’d probably know if you need this, using 64 Bit). A torrent file is not that big, so it should not take too long to download and does not place much of a burden on the servers.
After having downloaded the file to wherever you like, open up Transmission from Applications->Network->Transmission.
When newly installed, Transmission will download all files into the same directory as the torrent file. Instead of adapting to software (by remembering where it downloads files to), I make software adapt to me, so when I open a torrent file with Transmission, I want it to ask me where I want the files to be downloaded to.
Luckily, this is easy: simply open File->Preferences. While the preferences window is filled with cryptic terminology, the option I’m looking for is quickly found: all I need to do, is check the checkbox in front of Always prompt for download directory.
You can configure a whole host of additional options in the prefences window, such as the maximum download and upload speed. Be aware, though, that if you lower the maximum upload speed (i.e. the speed with which you are sharing the files with other people), the download speed will also decrease, so as to encourage everybody to share as much as they can.
When you’re done configuring Transmission, click Close in the Prefences window – it’s time to start downloading! Click File->Add and locate the torrent file you downloaded earlier. After you’ve opened the file and selected a target folder, Transmission will start downloading. While it will still be a long wait (the Xubuntu ISO image is a whopping 544 MB), if a lot of people are sharing the love then it’ll be faster than a direct download, and you’re helping other users at the same time.
Once you’re done downloading, you’ll want to verify that the file you downloaded is the correct one. After you’ve done that, the big moment is there: you can install Xubuntu!
Don’t close Transmission though! If you leave the window open after your download has completed, Transmission will continue sharing the downloaded file with other users – this is called seeding and is a good habit if you want to be a Nice Guy. You can also resume seeding after you’ve closed a torrent – simply re-open the torrent file and select the same download location.
All in all, while often associated with illegal downloading, there are plently of legit situations in which BitTorrent saves the day. Now spread the love!
Xfce Edition alpha1
We eventually put out the long promised alpha1 of Foresight Xfce Edition.It's not perfect (that's why we call it alpha1), but works for me since a long time.
We're still missing some applications, and xfce goodies.
Openoffice is replaced by abiword and gnumeric. And there is no compiz in the default install (that's a feature).
Get it here
Feedback and Comments (and helping hands) are welcome.
Drivel and Keyboard
What have I been doing lately?
Patching Drivel, that's what!
I like using Drivel. I never lose a blog entry with this thing, which is more than can be said when Planet Gentoo suddenly crashes when I'm submitting an entry. (Side note: are there any good graphical clients that work with b2evolution? I've yet to find anything in Portage.)
Even though Drivel upstream seems mostly dead, there are still patches to fix problems or add features floating around Bugzilla, so I've been grabbing them and testing, and if they check out, adding them to the ebuild I use in my local overlay.
So far, I've added patches & fixes to my ebuild that fix a memory leak, fix compiling with gtksourceview-2 (Thanks ecatmur! one fewer app that needs 1.x), update the Blogger login URL, and add tag support for LiveJournal. Upstream left a weird version in ltmain.sh; it was giving libtool version mismatch fits. Some judicious sed usage killed it. With extreme prejudice.
Anyway, Drivel's now much more usable. I haven't been through all the open bugs yet, but there's probably another patch or two that can be made presentable. One thing I discovered is that Drivel is using a few deprecated libraries and functions. It's got several deprecated uses of libegg (which has been replaced by equivalent functionality in gtk+), and it still relies on GnomeVFS.
Fortunately, the open bug for libegg has some info on porting to the appropriate gtk+ code, and there's also the guide to Migrating from GnomeVFS to GIO. I'm actually going to give it a shot. It's well documented, and it looks like it's nothing more than an long, intensive search-and-replace session. Right? Right? Guys? Guys?
Even if I fail utterly, well, it'll be fun to try it. Will follow up on this later.
In the meantime, you can get the updated Drivel ebuild and patches here. Just untar it in your ${PORTDIR_OVERLAY}/net-misc/ directory.
* * *
In other news, my new keyboard arrived in the mail a couple of days ago. It's much cleaner, slightly less resonant, and more interesting than the old keyboard. The Delete key got moved up near Backspace (what's the use in that?!?), so some judicious Xmodmap usage shoved the Insert key left, replacing Control_R, and I changed Ins to Del. I need my Del key right next to the arrowpad when working on documents.
The keyboard isn't as quiet as I'd hoped, but it's less squeaky than the old one, and it masses more, so it sponges up some of the resonance when hammering keys. Also, it's got 17 hotkeys, and every single one of them are correctly detected in Linux, no drivers needed (take that, included Windows XP driver CD!). More productivity, whoo!
Gnome's keyboard utility picked up the hotkeys and allowed me to assign them to various standard media key behaviors, but I chose to forgo that and use Xmodmap, since it works for both Gnome and Xfce. Xfce initially couldn't see the hotkeys, but it recognized them after I setup my /etc/X11/Xmodmap. Interestingly, Xfce correctly executes Xmodmap at login with no further setup needed, but Gnome doesn't. I had to go into the Sessions dialog and create an "Xmodmap" startup program entry.
This is weird, because GDM is supposed to execute any Xmodmaps found, whether in the user's home or systemwide in /etc/, and if it finds both, it's supposed to combine 'em. Poke around in /etc/X11, and you'll see that multiple files try to execute Xmodmap. However, GDM and Gnome have utterly failed here. They're weird like that sometimes. Fortunately, Xfce saves the day yet again.
Drivel and Keyboard
What have I been doing lately?
Patching Drivel, that's what!
I like using Drivel. I never lose a blog entry with this thing, which is more than can be said when Planet Gentoo suddenly crashes when I'm submitting an entry. (Side note: are there any good graphical clients that work with b2evolution? I've yet to find anything in Portage.)
Even though Drivel upstream seems mostly dead, there are still patches to fix problems or add features floating around Bugzilla, so I've been grabbing them and testing, and if they check out, adding them to the ebuild I use in my local overlay.
So far, I've added patches & fixes to my ebuild that fix a memory leak, fix compiling with gtksourceview-2 (Thanks ecatmur! one fewer app that needs 1.x), update the Blogger login URL, and add tag support for LiveJournal. Upstream left a weird version in ltmain.sh; it was giving libtool version mismatch fits. Some judicious sed usage killed it. With extreme prejudice.
Anyway, Drivel's now much more usable. I haven't been through all the open bugs yet, but there's probably another patch or two that can be made presentable. One thing I discovered is that Drivel is using a few deprecated libraries and functions. It's got several deprecated uses of libegg (which has been replaced by equivalent functionality in gtk+), and it still relies on GnomeVFS.
Fortunately, the open bug for libegg has some info on porting to the appropriate gtk+ code, and there's also the guide to Migrating from GnomeVFS to GIO. I'm actually going to give it a shot. It's well documented, and it looks like it's nothing more than an long, intensive search-and-replace session. Right? Right? Guys? Guys?
Even if I fail utterly, well, it'll be fun to try it. Will follow up on this later.
In the meantime, you can get the updated Drivel ebuild and patches here. Just untar it in your ${PORTDIR_OVERLAY}/net-misc/ directory.
* * *
In other news, my new keyboard arrived in the mail a couple of days ago. It's much cleaner, slightly less resonant, and more interesting than the old keyboard. The Delete key got moved up near Backspace (what's the use in that?!?), so some judicious Xmodmap usage shoved the Insert key left, replacing Control_R, and I changed Ins to Del. I need my Del key right next to the arrowpad when working on documents.
The keyboard isn't as quiet as I'd hoped, but it's less squeaky than the old one, and it masses more, so it sponges up some of the resonance when hammering keys. Also, it's got 17 hotkeys, and every single one of them are correctly detected in Linux, no drivers needed (take that, included Windows XP driver CD!). More productivity, whoo!
Gnome's keyboard utility picked up the hotkeys and allowed me to assign them to various standard media key behaviors, but I chose to forgo that and use Xmodmap, since it works for both Gnome and Xfce. Xfce initially couldn't see the hotkeys, but it recognized them after I setup my /etc/X11/Xmodmap. Interestingly, Xfce correctly executes Xmodmap at login with no further setup needed, but Gnome doesn't. I had to go into the Sessions dialog and create an "Xmodmap" startup program entry.
This is weird, because GDM is supposed to execute any Xmodmaps found, whether in the user's home or systemwide in /etc/, and if it finds both, it's supposed to combine 'em. Poke around in /etc/X11, and you'll see that multiple files try to execute Xmodmap. However, GDM and Gnome have utterly failed here. They're weird like that sometimes.
whaawmp 0.2.10
Jeff just released a bugfix release for whaawmp. It doesn't lockup anymore, if xvideo isn't available and it works with other imagesinks too now.I hope to put out an alpha of Foresight Linux Xfce Edition this week eventually.
We will see. Get latest whaawmp while waiting :-)
No GSoC
Sadly, we didn't get accepted into Google's Summer of Code this year. It's a shame, but I'm glad I went through the effort to apply. If nothing else, we got some potentially-useful ideas and possibly some developer interest. Obviously we can't fund any of these people, but it would be great if they still want to contribute.
Update: The coordinator got back to me, and said our ideas page wasn't very fleshed out, and that we should look at other accepted applicants and the program guidelines for help on how to do this right... never mind that I actually did look at some older accepted projects, and their ideas lists were at times even more sparse than ours (though many were much more formally written up as well). Also she gave the usual "we can't accept every great project" excuse, which at least gives some hope for next year. I'm not particularly sure I want to go through the work to apply again, but maybe someone else will.