Grisbi is now
available in Emdebian but without libofx. Similarly homebank is in Emdebian (note that homebank-data is also needed and is available), again without libofx.

I'm not convinced that libofx is that much of a loss on an embedded device - especially when libofx and dependencies could add 5Mb to an existing installation - just for the shared libraries!

The screenshots of Grisbi in Maemo gave my the idea of adding grisbi and I've been trying it out on the desktop too. Once I'd tweaked the column widths for the transaction window (hidden away in Preferences), it is quite usable - although I can't see any way of it handling invoices.

My own gpe-cash is not making much progress - the GnuCash objects are just too resistant to use outside GnuCash. It may be easier to create invoices from grisbi/homebank data via CSV and estron.

This is aimed at the more powerful end of Emdebian devices but each package is still 50% smaller in Emdebian than in Debian, closer to 80% smaller if you count the reduced dependencies. The main difference is the use of TDebs.

Christian Perrier and I are planning on working on TDebs during DebConf8 and Extremadura so that bugs and fixes to support TDebs can be implemented in Debian as soon as Lenny is released. Removing translations from the maintainer uploads and translation bugs from the package BTS should make it a lot easier to update translations without requiring an NMU of the entire package (which is complete overkill IMNSHO).

Together with DEB_BUILD_OPTIONS="nodocs" support, TDebs are the simplest way to reduce package sizes and installation sizes in Debian/Emdebian.

(I just wish #448615 could be fixed so that I could get on with preparing patches for packages that install docs without using debhelper.)

It has recently been announced that Debian had a serious bug in the OpenSSL code [1], the most visible affect of this is compromising SSH keys - but it can also affect VPN and HTTPS keys. Erich Schubert was one of the first people to point out the true horror of the problem, only 2^15 different keys can be created [2]. It should not be difficult for an attacker to generate 2^15 host keys to try all combinations for decrypting a login session. It should also be possible to make up to 2^15 attempts to login to a session remotely if an attacker believes that an authorized key was being used - that would take less than an hour at a rate of 10 attempts per second (which is possible with modern net connections) and could be done in a day if the server was connected to the net by a modem. John Goerzen has some insightful thoughts about the issue [3]. I recommend reading his post. One point he makes is that the person who made the mistake in question should not be lynched. One thing I think we should keep in mind is the fact that people tend to be more careful after they have made mistakes, I expect that anyone who makes a mistake in such a public way which impacts so many people will be very careful for a long time… Steinar H. Gunderson analyses the maths in relation to DSA keys, it seems that if a DSA key is ever used with a bad RNG then it can be cracked by someone who sniffs the network [4]. It seems that it is safest to just not use DSA to avoid this risk. Another issue is that if a client supports multiple host keys (ssh version 2 can use three different key types, one for the ssh1 protocol, one for ssh2 with RSA, and one for ssh2 with DSA) then a man in the middle attack can be implemented by forcing a client to use a different key type - see Stealth’s article in Phrack for the details [5]. So it seems that we should remove support for anything other than SSHv2 with RSA keys. To remove such support from the ssh server edit /etc/ssh/sshd_config and make sure it has a line with “Protocol 2“, and that the only HostKey line references an RSA key. To remove it from the ssh client (the important thing) edit /etc/ssh/ssh_config and make sure that it has something like the following: Host *
Protocol 2
HostKeyAlgorithms ssh-rsa
ForwardX11 no
ForwardX11Trusted no You can override this for different machines. So if you have a machine that uses DSA only then it would be easy to add a section: Host strange-machine
Protocol 2
HostKeyAlgorithms ssh-dsa So making the default configuration of the ssh client on all machines you manage has the potential to dramatically reduce the incidence of MITM attacks from the less knowledgable users. When skilled users who do not have root access need to change things they can always edit the file ~/.ssh/config (which has the same syntax as /etc/ssh/ssh_config) or they can use command-line options to override it. The command ssh -o “HostKeyAlgorithms ssh-dsa” user@server will force the use of DSA encryption even if the configuration file requests RSA. Enrico Zini describes how to use ssh-keygen to get the fingerprint of the host key [6]. One thing I have learned from comments on this post is how to get a fingerprint from a known hosts file. A common situation is that machine A has a known hosts file with an entry for machine B. I want to get the right key in machine C and there is no way of directly communicating between machine A and machine C (EG they are in different locations with no network access). In that situation the command “ssh-keygen -l -f ~/.ssh/known_hosts” can be used to display all the fingerprints of hosts that you have connected to in the past, then it’s a simple matter of grepping the output. Docunext has an interesting post about ways of mitigating such problems [7]. One thing that they suggest is using fail2ban to block IP addresses that appear to be trying to do brute-force attacks. It’s unfortunate that the version of fail2ban in Debian uses /tmp/fail2ban.sock for it’s Unix domain socket for talking to the server (the version in Unstable uses /var/run/fail2ban/fail2ban.sock). They also mention patching network drivers to add entropy to the kernel random number generator. One thing that seems interesting is the package randomsound (currently in Debian/Unstable) which takes ALSA sound input as a source of entropy, note that you don’t need to have any sound input device connected. When considering fail2ban and similar things, it’s probably best to start by restricting the number of machines which can connect to your SSH server. Firstly if you put it on a non-default port then it’ll take some brute-force to find it. This will waste some of the attacker’s time and also make the less persistent attackers go elsewhere. One thing that I am considering is having a few unused ports configured such that any IP address which connects to them gets added to my NetFilter configuration - if you connect to such ports then you can’t connect to any other ports for a week (or until the list becomes too full). So if for example I had port N configured in such a manner and port N+100 used for ssh listening then it’s likely that someone who port-scans my server would be blocked before they even discovered the SSH server. Does anyone know of free software to do this? The next thing to consider is which IP addresses may connect. If you were to allow all the IP addresses from all the major ISPs in your country to connect to your server then it would still be a small fraction of the IP address space. Sure attackers could use machines that they already cracked in your country to launch their attacks, but they would have to guess that you had such a defense in place, and even so it would be an inconvenience for them. You don’t necessarily need to have a perfect defense, you only need to make the effort to reward ratio be worse for attacking you than for attacking someone else. Note that I am not advocating taking a minimalist approach to security, merely noting that even a small increment in the strength of your defenses can make a significant difference to the risk you face. Update: based on comments I’m now considering knockd to open ports on demand. The upstream site for knockd is here [8], and some documentation on setting it up in Debian is here [9]. The concept of knockd is that you make connections to a series of ports which act as a password for changing the firewall rules. An attacker who doesn’t know those port numbers won’t be able to connect. Of course anyone who can sniff your network will discover the ports soon enough, but I guess you can always login and change the port numbers once knockd has let you in. Also thanks to Helmut for advice on ssh-keygen.

• [1] http://www.debian.org/security/2008/dsa-1571


• [2] http://blog.drinsama.de/erich/en/linux/2008051401-consequences-of-sslssh-weakness.html


• [3] http://changelog.complete.org/posts/714-Thoughtfulness-on-the-OpenSSL-bug.html


• [4] http://blog.sesse.net/blog/tech/2008-05-14-17-21_some_maths.html


• [5] http://www.phrack.org/issues.html?id=11&issue=59


• [6] http://www.enricozini.org/2008/tips/ssh-host-key-fingerprint.html


• [7] http://www.docunext.com/blog/2008/05/14/my-security/


• [8] http://www.zeroflux.org/cgi-bin/cvstrac.cgi/knock/wiki


• [9] http://www.ducea.com/2006/07/05/how-to-safely-connect-from-anywhere-to-your-closed-linux-firewall/

Share This

(tl;dr: if you have a few minutes, please add information here) Joss, the problem with the new package formats is that there is nothing that actually uses the additional information in a way that adds significant new functionality, so the net result of the change was that we throw away the information at a different layer in our software stack, and one of the interfaces got a lot more complicated in the process. One possible application would be a "poor man's patch tracking" inside the BTS, perhaps with a new state "fixed in patch". I can see two ways of implementing that:

1. by extending the interface of the "new" package formats that Debian,Ubuntu bug numbers are attached to the actual patch files and having the archive maintenance software extract and process that information (reject packages that add a patch for a bug without closing it in the changelog, notify the BTS), or
2. by leaving the package format untouched and simply adding a regex matching "Fixes: #nnnnnn" that is reported to the BTS as "we have added a patch", so the submitter is notified that the bug is gone for him/her; the bug is then closed in the changelog of the upload removing the patch.

The former approach also allows us to link to patches from BTS pages, which the latter doesn't, so there could be actual benefit here if we believe it is worth the additional complexity. (Update: Rapha l thinks it is. I like the idea of a package format with separate patches a lot more in this context than I did without it, but still my fear that it will actually be perceived as sanctioning large patchsets still remains.) About mandatory co-maintenance: the problem isn't "helping". We have plenty of people with commit access to packages they don't even remotely understand who are really helpful (not). The problem is that someone needs to actually read all the commit logs and understand what the changes do in this context. In most cases, that person or group would be upstream, not a DD. My first impression after reading the patch was "adding uninitialized data to the entropy pool is pointless/harmful as it is not random, so this patch makes sense", because the loop around it was not contained in the patch. Obviously I'm not an OpenSSL developer. There is nothing Debian could have done internally to verify the correctness of this patch that would properly scale to the entire archive, even if we put "more emphasis on security". The only solution I see is reporting every patch to upstream immediately and getting affirmation that it is correct. This, however means that we need to produce patches that upstream can accept. For obvious code bugs, that is simple, but for integration patches like paths it is not sufficient to replace one string with another, but rather make it configurable in some place that can be reached from debian/rules. In an ideal world, we end up with very few Debian specific patches, so essentially we are talking about adding functionality to dpkg that we don't want to use. I've started a page in the Debian Wiki, Getting Packaged with an outline of a possible document aimed at upstream developers that should list the typical problems we run into and how to avoid them.

So going alone to the cinema yesterday was not a first, but going alone and being alone in the room certainly was, and an unexpected one. This was, as far as I know, the premiere in Alicante of Enloquecidas, which is certainly not that of a remarkable film, but which was entertaining enough, and provided some very good laughs. What is wrong with this city?! (Update: hm, seems I’m mistaken about the “premiere” bit. Oh well.)

Heh, in the 11 or so hours since my last blog post I've received two emails from people going "yeah BA is crap!" Well the flight itself was fine. The plane was nice. The entertainment system was pretty decent. The UI was all touch screen based, which made it less clunky than Qantas'. Food-wise, I thought the dinner tray was pretty loaded with stuff. Only problem is that the flight was running about 10 minutes behind schedule, then had to hang around in the air at Heathrow for about 10-15 minutes, so we didn't make our connecting flight. BA bumped us to the next one without any problems, so now we're chilling out in the spiffy new terminal 5 BA lounge for an hour. I guess an hour just doesn't have enough fat in it for a connection. Terminal 5 is pretty shiny in general. Hopefully our bags won't get lost.

Unlike Steve, I don’t particularly mind going to the cinema alone. In fact, it’s becoming a growing habit for Friday nights, when my friends go to some meetings about their faith I don’t participate in (nor their meetings, nor their faith). I really hate getting home early on Fridays, so I take chance to go to movies I know we wouldn’t be going together anyway. (Oh, and in case I haven’t said here already, the movie offerings in this “city” suck big balls. Virtually no undubbed sessions, virtually no non-mainstream movies. I don’t think I’ll still be here in a couple years, but boy would I be unhappy if the circumstances forced me to.)

Free software finally gets significant coverage on BBC TV's Click show this week, but I think it's very much Linux rather than GNU/Linux and free cost rather than freedom. They mentioned free security software and even raised the possibility of trojans, but didn't mention how free (as in freedom) software allows any random end-user to check or have it checked. Quite a missed opportunity! However, Click has a regular letters section, so watch it (times below), email click@bbc.co.uk and see if we can get the free software view across. The letters section this week seemed to be flaming proprietary SaaS social network site facebook for their pathetic default-permit approach to security of user details. I really think there's a role for something like noserub in free software social networking. Click-UK is shown on BBC News Channel Saturday 1130, Sunday 0430 and 1130, Monday 0030 and Sunday 0430 on BBC-1 (times BST) Click-World is shown Thursday 19:30 GMT, Repeated Friday 09:30 and 12:30 (Asia Pacific only), Saturdays 06:30, Mondays 15:30, Tuesdays 01:30 (not Asia Pacific, Middle East or South Asia) and 07:30 GMT Anyone else see this?

This post is to some extent a fall-out of the recent discovery of a serious flaw in Debian's openssl and openssh packages. However, as Raghavan will confirm, a weaker version of what is said below was part of our discussion two weeks ago. Moreover, there are earlier posts on this topic in this blog.There are times when I wonder why I am so involved with computers ... this is clearly one of those times.

कर्मण्यैवाधिकरस्ते मा फलेशु कदाचनkarmaNyaivaadhikaraste maa faleshu kadaachana

This is a phrase from the भगवद गीत (bhagavad giit) which has been stuck in my head for the last 30 odd years. It roughly paraphrases into

Do something because you think it is worth doing not because of what you hope to achieve by doing it.¹

The above maxim is a good one but is sometimes a cop-out. Moreover, it provides no basis for actually making ethical choices.Ethics comes from one's interactions with the communities one is a part of. There are (roughly) two communities that I am a part of in the context of computers:

• the FOSS community; specifically, the Debian community.
• the IMSc computer community

I take these in turn below.

Debian and FOSS communitiesBy its own standards, the Debian community has suffered a massive failure ... and by these same standards it has reacted extremely well to this failure.I feel shame and blame. Why have I been ignoring RFH#332498 all these days when it shows up in the output of wnpp-alert? Here I am, a mathematician with some understanding of the issues, not helping out! Three years ago I even gave a short course of lectures on implementations of crypto; the source of openssl and openssh were used as examples. Excuses like, "I don't know anything about library packaging" and "I need more time!" (who doesn't) seem too weak now.At the same time, I feel a sense of solidarity with the Debian (and more widely FOSS) community as it tries to pull out of the resulting mess. The resilience that allows us to laugh wryly at ourselves is IMHO admirable.As Steve Kemp wrote: "[When we look back we will see that] we did good".

IMSc computer communityThe IMSc computer setup was built by volunteers and was genuinely a community when I joined this institute in 1996. It has since then broken into users, system administrators and the computer committee. As Indira Gandhi would have said: "This is a world-wide phenomenon", and as was the case when she said it, my response is: "That doesn't make it a good thing!"

When I speak about this fractured IMSc community below it is in generalities. There are certainly individuals who rise above the shards.

I have been promoting the use of FOSS and more specifically Debian at IMSc ever since I got here. While explaining the pragmatic aspects like cost and security, I have also tried to emphasize the freedom and community aspects of FOSS use. When the latter are not understood or accepted, the former are easily blown away.This year I made an attempt to get the Computer Committee to invite users to choose² their own computers and the software that ran on it, but it turned out that no one really wanted this. Users just wanted to buy "fancy toys", the administrators just wanted to make their life simple and CC members just wanted the power to dictate what people bought.³I also made an attempt to get our users to educate each other on the use of computers for their work --- first through the establishment of a wiki and then through the "No-Excuse" mailing list.⁴Unfortunately, the fractured IMSc computer community sees computers and software as expensive commodities --- with some combination of fear, greed and irritation. In any case, there is no feeling of being part of a larger community that is trying to solve (certain types of) problems.

A wise man once said:

With great freedom comes even greater responsibility.

This may explain why we prefer being dictated to by proprietary vendors and computer committees that "buy stuff for us". We are afraid of the responsibility that comes with freedom.Another much quoted quote is:

If you are not part of the solution then you are part of the problem.

The FOSS community (actively) invites people to join-in in solving problems. This participation (which can be at a level of one's own choosing) is the source of one's freedom in free software. The IMSc community just wants मा-बाप सर्कार (maa-baap sarkaar) to fix their toys.

A decisionThe IMSc computer community was tied to Debian and FOSS after the break-ins into our system in the early 2000's. At that point, I was instrumental in installing a security infrastructure based mainly on Debian. This led to my greater involvement with FOSS and Debian and also to the greater "infiltration" of Debian and FOSS into IMSc computers.From the "commodity" point of view at IMSc we have come a full circle since most users will have to "do a lot" so that the IMSc computer LAN emerges unscathed from the crisis created by the Debian openssl flaw.From the "community" point of view at Debian we have spiralled out and even this major whirlpool will not drag us back in.It is no longer possible (for me) to straddle the circle and the spiral in an attempt to widen the former; I'm taking the "outward radial vector"!

---

1. To this sentiment I have often added "do it because it's fun". ↩
2. ... and be willing to justify their choices of course.[WGFCEGR] ↩
3. OK! I'm exaggerating a bit! ↩
4. No-Excuse is an acronym for Novice and Expert Computer Users. The blurb says:

   Now that this list exists there is "no-excuse" for novices to remain in-experienced or for experienced users to claim that something is "too hard to explain to a novice"!

   ↩

I believe that the Red Hat process which has Fedora for home users (with a rapid release cycle and new versions of software but support for only about one year) and Enterprise Linux (with a ~18 month release cycle, seven years of support, and not always having the latest versions) gives significant benefits for the users. The longer freeze times of Enterprise Linux (AKA RHEL) mean that it often has older versions of software than a Fedora release occurring at about the same time. In practice the only time I ever notice users complaining about this is in terms of OpenOffice (which is always being updated for compatability with the latest MS changes). As an aside, a version of RHEL or CentOS with a back-port of the latest OpenOffice would probably get a lot of interest. RHEL also has a significantly smaller package set than Fedora, there is a lot of software out there that you wouldn’t want to support for seven years, a lot of software that you might want to support if you had more resources, and plenty of software that is not really of interest to enterprise customers (EG games). Now there are some down-sides to the Red Hat plan. The way that they run Fedora is to have new releases of software instead of back-porting fixes. This means that bugs can be fixed with less effort (simply compiling a new version is a lot less effort than back-porting a fix), and that newer versions of the upstream code get tested. With some things this isn’t a problem, but in the past I have had problems with the Fedora kernel. One example was when I upgraded the kernel on a bunch of remote Fedora machines only to find that the new kernel didn’t support the network card, so I had to talk the users through selecting the older kernel at the GRUB menu (this caused pain and down-time). A problem with RHEL (which I see regularly on the CentOS machines I run) is that it doesn’t have the community support that Fedora does, and therefore finding binary packages for RHEL can be difficult - and often the packages are outdated. I believe that in Debian we could provide benefits for some of our users by copying some ideas from Red Hat. There is currently some work in progress on releasing packages that are half-way between Etch and Lenny (Etch is the current release, Lenny will be the next one). The term Etch and a half refers to the work to make Etch run on newer hardware [1]. It’s a good project, but I don’t think that it goes far enough. It certainly won’t fulfill the requirements of people who want something like Fedora. I think that if we had half-way releases of Debian (essentially taking a snap-shot of Testing and then fixing the worst of the bugs) then we could accommodate user demand for newer versions (making available a release which is on average half as old). Users who want really solid systems would run the full releases (which have more testing pre-release and more attention paid to bug fixes), but users who need the new features could run a half-way release. Currently there are people working on providing security support for Testing so that people who need the more recent versions of software can use Testing, I believe that making a half-way release would provide better benefits to most users while also possibly taking less resources from the developers. This would not preclude the current “Etch and a half” work of back-porting drivers, in the Red Hat model such driver back-ports are done in the first few years of RHEL support. If we were to really follow Red Hat in this regard the “Etch and a half” work would operate in tandem with similar work for Sarge (version 3.1 of Debian which was released in 2005)! In summary, the Red Hat approach is to have Fedora releases aimed at every 6 months, but in practice coming out every 9 months or so and to have Enterprise Linux releases aimed at every year, but in practice coming out every 18 months. This means among other things that there can be some uncertainty as to the release order of future Fedora and RHEL releases. I believe that a good option for Debian would be to have alternate “Enterprise” (for want of a better word) and half-way releases (comparable to RHEL and Fedora). The Enterprise releases could be frozen in coordination with Red Hat, Ubuntu, and other distributions (Mark Shuttleworth now refers to this as being a “pulse” in the free software community [], while the half-way releases would come out either when it’s about half-way between releases, or when there is a significant set of updates that would encourage users to switch. One of the many benefits to having synchronised releases is that if the work in back-porting support for new hardware lagged in Debian then users would have a reasonable chance of taking the code from CentOS. If nothing else I think that making kernels from other distributions available for easy install is a good thing. There is a wide combination of kernel patches that may be selected by distribution maintainers, and sometimes choices have to be made between mutually exclusive options. If the Debian kernel doesn’t work best for a user then it would be good to provide them with a kernel compiled from the RHEL kernel source package and possibly other kernels. Mark also makes the interesting suggestion of having different waves of code freeze, the first for the kernel, GCC, and glibc, and possibly server programs such as Apache. The second for major applications and desktop environments. The third for distributions. One implication of this is that not all distributions will follow the second wave. If a distribution follows the kernel, GCC, and glibc wave but not the applications wave it will still save some significant amounts of effort for the users. It will mean that the distributions in question will all have the same hardware support and kernel features, and that they will be able to run each others’ applications (except when the applications in question use system libraries from later waves). Also let’s not forget the possibility of running a kernel from distribution A on distribution B, it’s something I’ve done on many occasions, but it does rely on the kernels in question being reasonably similar in terms of features.

• [1] http://wiki.debian.org/EtchAndAHalf


• [2] http://www.markshuttleworth.com/archives/150

Share This

"Here are three examples of rules that I think it's time to abandon. These particular examples are all about email. 1/ Top Posting [...] 2/ HTML Email [...] 3/ Reply-To On Mailing Lists [...] So, yes, the barbarians are at the gate. The lunatics have taken over the asylum. Good ideas have been crushed by the number of people who don't understand them. But there's no point in complaining about it. You just have to accept it and move on."

-- Pointless Battles For Geeks, By Dave Cross Unsurprisingly, given the above links to my site, I disagree with Dave Cross's conclusion, but I do agree with two aspects: battling is generally pointless and using hard rules about these things is unnecessary. I have those pages on my website so that I can point to them when their broken emails aren't handled as expected. I use some aspects of them as scoring inputs in my mail filters. I don't use them as rules and I try not to complain about them too often. Nevertheless, I still believe sending properly-trimmed plain text emails from a list-friendly email client is clearly best practice, to be recommended when someone asks why their email bad habits are causing them problems.

I'm convinced by The Argument for Posting Ahead [Network Blogging] so why didn't I set it up for my recent trip? Well, a while ago, I had a bit of an email discussion with Steve about delayed posting features for Chronicle which I think ended with the addition of chronicle-spooler to the released files. I initially suggested ignoring a post when its Date is in the future, like Wordpress does, but I think that wouldn't be backwards-compatible and isn't as flexibile as it could be. chronicle-spooler works by moving files from a spool dir into a live dir. I'd forgotten how much it confuses me when files on a "static" site start moving themselves around. It means I have to merge before upload, which isn't a big change, but still annoying. So, I've added the following lines to chronicle to skip entries with a Publish header in the future:-

--- chronicle-2.7/bin/chronicle.orig	2008-05-15 10:13:55.000000000 +0100
+++ chronicle-2.7/bin/chronicle	2008-05-15 10:13:43.000000000 +0100
@@ -607,7 +607,8 @@
         #  Read the entry and store all the data away as a
         # hash element keyed upon the (unique) filename.
         #
-        $results  $file   = readBlogEntry($file);
+        my $result =  readBlogEntry($file);
+        if ($result)   $results  $file   = $result;  
      
 
     #
@@ -1479,7 +1480,7 @@
     my $tags    = "";    # entry tags.
     my $body    = "";    # entry body.
     my $date    = "";    # entry date
-    my $publish = "";    # entry publish date - *ignored*
+    my $publish = "";    # entry publish date
 
     open( ENTRY, "<", $filename ) or die "Failed to read $filename $!";
     while ( my $line = <ENTRY> )
@@ -1527,6 +1528,14 @@
      
     close(ENTRY);
 
+    # MJR - embargo stuff until its publish date.
+    # Steve recommends using chronicle-spooler,
+    # but I want uploaded files to stay where I put them,
+    # else I get my local copy confused.
+    if (($publish ne "") && (str2time($publish) > time()))  
+    	return 0;
+     
+
     #
     #  Determine the input format to use.
     #

I think that's compatible with chronicle-spooler, too...

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.

After recent not so funny thing with OpenSSL in Debian, I realized that I will have to regenerate most of keys and certificates, because last big changes I did in networking/vpn/ssh setup which involved generating keys are not older than broken OpenSSL appeared in archives. First obvious thing was SSH keys and cleanup of ~/.ssh/authorized_keys on all hosts. While doing that, I realized that I still have there several keys, which are more or less gone (not that I'd lost them, but I simply stopped to use them). So it was good opportunity to do cleanup here. While I was at these changes, cleaning up ~/.ssh/known_hosts was also good idea, because I still had there lot of hosts I collected during some of my previous jobs and I definitely won't (and can not) access these machines anymore. So good, big cleanup in SSH configuration was forced :-). Next and harder step was to found out where else I use certificates generated by vulnerable OpenSSL. Server certificates for sure were also generated by OpenSSL, so let's regenerate web and email certificates and hope I did not miss anything. All this happened yesterday, but today I realized that I missed other even more important thing - OpenVPN certificates. While regenerating certificates, I also found some machine keys which are not really used anymore, so I again could drop some of them. So that was task for this evening and now I'm hopefully really done with this issue and I really hope that this won't happen again in near future, I don't need to cleanup that often ;-).

I did this three years ago, too. I guess now's the time to go again: I just went through my referer logs—specifically, keywords people entered in search engines right before they ended up on my site—, and will try to answer those questions people seem to have when they end up on my site. Here goes:

• voorwoord eindwerk: Eh. How about you make your homework yourself? (to my english readers: "voorwoord eindwerk" is dutch for "foreword dissertation"... and a few months ago, I noticed that I accidentally had my brother's dissertation on my website. It's now removed, and the search hits seem to have stopped, too, but it's still in my not-so-recent referer logs)
• php accept language: Yes, I did write that. By the number of people searching for it, you'd think it's the most important contribution I made to open source. I sure hope not, but anyway.
• wouter verhelst: Yes, you found him, all 1.4% of you. Perhaps you meant that other wouter verhelst, however.
• digikam vs f-spot/f-spot vs digikam: I eventually picked digikam, not f-spot. Make sure you pick the right one from the beginning, though, since switching currently requires you to re-tag everything.
• nicknames: My IRC nickname is 'Yoe'. But as I've explained before, I prefer not being called that elsewhere.
• vim vs emacs: Not sure why you end up on my site for that. I use both, depending on what I want or need to do. (emacs is more powerful in some areas, but takes far longer to start...)
• duck with whisky:yes, yes, yes, very funny.
• nbdmagic: The NBD protocol uses a magic number to mark the start of a request packet; this defends against the client and server getting out of sync (which may happen in case of a bug somewhere). If that happens, the server will kill the connection with a message "Not enough magic." Please report the bug, or (even better) fix it :-)

Moving further down, it's fascinating to see what people were looking for when they ended up on my site. Some of the below, I have absolutely no clue what happened...:

• belgium driver licence—go to your local municipal office, please!
• sockets in brainfuck—now, really.
• wouter's mum—look at your own, you dammit you!
• what to do with debian—I should know, how?
• several things related to "android"—I'm not involved in that
• list of programming languages to learn—that's easy: the list of programming languages you don't know, yet.
• kernel panic not syncing aiee killing interrupt handler 2.6.24 (and several other literal panic messages)
• verhelst -meaning—In other words: "anything that has verhelst, but no meaning". Thanks. I guess.

I guess blogging about technical things for several years has made me "interesting" enough for some people. Grin.

So one of the amazing things about the net is not so much how it makes lots of data available (actually that can be the nightmare of the net) but how it makes it available. And one of the more powerful forms of availability is in the form of visual mapping. So this new tool theNNDB Mapper is just one such visualization tool that I have to say, is pretty niftfy, though still a little green and beta at least in terms of its data. Take for example, the hacker map, which is pretty sparse right now but the great thing about it is 1) one can add data 2) and it generates useful data and links, for example, to profiles, such as this this one of Kevin Mitnick. Apparently, he is not linked to anyone, which is ironic (and just wrong) because he it is more correct to say was linked like to an entire generation of hackers, especially those who participated in the Free Kevin movement (and that could perhaps be another field?)..

Eric, I cann’t claim to 100% understand the situation but after glancing trough the logs of the discussions and of the patches the conclusion I came to was this - OpenSSL used supposed randomness of the uninitialized memory as an added source of entropy (interesting hack, but not an example of good coding as such). Valgring caught that problem and the Debian maintainer during a cleanup fixed it. Making such a fix can be considered a preventive step against possible attack vectors by poisoning the uninitialized memory. He took it up to upstream, they did not raise red flags, but did not quite merge the ‘clean up’ patch either. It fell through the cracks. The problem is that in the same file, in another function all other sources of entropy were being merged into the pool of randomness using exactly the same code line as the one code line flagged by Valgrind. The maintainer assumed that the second code line has a similar function to the first and commented that one as well. AFAIK that also did not show up in the emails to the upstream list. So we have:

• Upstream using clever hacks that rely on uninitialized memory having some randomness to it
• Upstream using same code and same variable names to describe different things
• Upstream having no comments in the code explaining the two things above
• Maintainer slightly over-generalizing a change
• A bug slipping trough the cracks in the review processes
• Another Debian Developer discovering the bug and recognizing its significance despite all of the above
• Debian project coming out and admitting all of the above and scrambling to get fixes out to its users ASAP

I am impressed by the swift action of the people involved in fixing this. And while I think everyone can find some lesson be learned here, I think this is another good example of free software in action. And I hope that in the aftermath of this we will find ways to prevent this from happening in the future without stifling our progress.

For those interested in the politics of science, or to be more specific, how science is flagrantly twisted to keep important facts and findings about our public health from public view, this book Doubt is Their Product: How Industry’s Assault on Science Threatens Your Health by David Micahels looks like a must read. For those wanting a little here is a review of the book.. In short, the author shows how occlusion comes from the need to secure and protect profits, and is achieved with what he calls the alchemy of twisting numbers and facts: “It’s quite easy to take a positive result [showing harmful effects] and turn it falsely negative. This epidemiological alchemy is used widely.” The problem runs deep as this other article from Slate magazine also indicates. But there are some good sources to get and evaluate your science and health news and health news review seems like one important place to go.

I am affiliated with a project whose origin is the northern parts of Canada, although whose members span the globe called What Sort of People Should There Be?. The idea behind this nifty and catchy title is to get a bunch of researchers in various fields, from disability studies to philosophy and everything that comes in between to start asking a series of questions about the role of human enhancement today and eugenics in the past, all within the context of thinking about the experience and politics of disability. I am super excited about the project because it spans the past and present to confront what it means to be human, how we value variation, how we seek to support or erase difference, and lastly something close to my academic heart, the role of technology in facilitating and dampening the politics of possibility and hope when it comes to disability. The project has recently launched an multi-author blog and I will be posting there from time to time. If you are interested in this topic, do come by for a visit. I am sure you won’t be disappointed. My most recent post is here and it covers an interesting article in the New York Times on Mad Pride, which oddly enough is in the Fashion & Style section.

As some people have guessed, not posting means that I'm doing quite well these days! The major advancements in my life since the last post are:

* Feeling comfortable enough to drive a car.

I finally feel like I can look around enough to shoulder check, although I can't twist enough to back the car up. When it comes time to park in out parking spot, I get Angie to do that bit.

* I'm allowed in the hot tub!

While this one seems like less of a big deal, since sitting in a hot tub in mid-20 degree weather is a bit weird, it's one more thing to do when I'm at home, and really pleasant on my back and shoulder muscles.

* My first HIV test came back negative.

Yay blood transfusion. The doctors consider the risk to be so negligible that they don't actively recommend that people get tested. They do, however, make you sign scary paperwork. So in order to be a responsible partner, and not a hypocrite when I teach OWL, I'm getting tested. One more test at 3 months, one more at 6 months to go.

Otherwise, things are going well. Physical Therapy is continue to put me on harder weights and Therabands almost every week. I'm continuing to reduce my meds at one pill per week (So I think I might be able to have a "Yay, I've got a 5-year visa" celebratory drink when I can back!). I'm still taking the anti-nausea drugs almost every day, but hopefully as I get off the pain killers, that will be less of a problem.

Oh, and I got our Canadian taxes mailed off (yay!). Now if we can only get the accountant to get the US ones off...

We're going up to Vancouver soon. There'll be at least one party for Leif, please email me if you want info. When we get back, I'll be straight into work, so forgive me if I suddenly go silent for a few weeks. =)

Now, back to homework. A course started a month earlier than I thought it did. =(

I'm just back from a trip to Cuba. Sorry for the abrupt disconnect. I expected to have limited connectivity there, whereas I actually had none at all except for 23 minutes! I hope the other members of the cooperative and the editorial team stepped in suitably well. I'll check in with them now and then start on the emails, but I wanted to put this broadcast out first for those who are watching closely and wondering...