Andrew Pollock writes about visiting Prague, coming through Z rich on the way:

Immigration [at Z rich airport] was the biggest joke ever. There was no paperwork at all, and we just handed our passports to the guy, who just looked at them casually, and waved us through. No stamp, no scan, no nothing. It was a bit disappointing really.

Hey, this is Switzerland, what did you expect? :-) I don't say that bad experiences don't exist, but so far I always have been able to interact with officials (customs, police, judges, clerks, whatever) on the basic assumption that things will work out without too much hassle. Often the most difficult part is finding the office that is responsible for whatever I should do. Knowing what realistically can be expected and what might not be easily possible helps, too.

TED has a post about the design of the new OLPC [1]. I never liked the previous OLPCs [2], for my use a machine needs a better keyboard than the tiny rubber thing that they had. I understand why they designed it that way, for use in places where it would be an expensive asset it is necessary to make it resistant to water and dust to the greatest possible degree. But in a first-world country where a computer is a cheap item, having a better interface makes sense. I’m sure that I could have plugged a USB keyboard into a OLPC, but having a keyboard integrated as well as an external keyboard is just kludgy. The new design of the OLPC with two panels (at least one of which is a touch-screen - I hope that both are) is very innovative. With the keyboard displayed on a touch screen there are much greater possibilities for changing alphabet (teaching children to write in multiple languages is a good thing). Of course a touch-screen keyboard won’t allow proper touch typing, but it should still be possible to plug in a USB keyboard - with the additional benefit that it could use both panels to display data when an external keyboard is used. One of the new uses of an OLPC machine is to play two player games with the players sitting opposite each other. The next logical extension to this idea is to have a multi-user OLPC machine so that two people can use it at the same time (a machine that can run copy of a program that compares to the GIMP can surely run two programs to display electronic books or read email). A large part of the design of the OLPC is based around the needs for children in the developing world, in such cases one computer per home is likely to be common so it would be good if two children could do homework at the same time (or if a parent could check email while a child studies). Finally the new design is much better suited to reading documents, while they show a picture of a book being read in two panes (similar to the way that paper books are read) I think that a more common use will be to display book text in one pane while using the other pane for writing notes. That would mean that instead of having a full-sized (by OLPC standards) keyboard on the touch-screen they would have to use a small keyboard (maybe with a stylus) or an external keyboard. It is awkward and distracting to hold open a paper book with one hand while writing notes with the other, using one half of an OLPC to write notes while the other half displays an electronic book would be a significant advantage. The potential utility of the new OLPC design for reading documents is significant enough to make me want to own one, and I expect that other people who have similar interests to me will have similar desires when they see the pictures. While the OLPC isn’t really designed for the use of people like me, it’s unnatural for me to use a computer without programming it - so I expect that the new hardware developments will encourage new developers to join the OLPC project.

• [1] http://blog.ted.com/2008/05/xo_laptop_redes.php


• [2] http://laptop.org/

Share This

Today was a good day — at least if I average all the things happened today. And since Twitter.com is currently down and there’s no way all those things fit in 140 characters, I decided to pack them in a “short” blog post:

• This afternoon one backplane of our newest backup server caught fire. :-( No collateral damages though. :-) The machine is currently at the manufacturer and should be back on Monday.
• My EeePC (more about it in an upcoming blog post) recently overheated and switched off. It looked as if it since then didn’t turn off correctly anymore, but power and the fan stayed on although the operating system was shut down. Today I found out with help of the debian-eeepc-devel mailing list that my EeePC wasn’t damaged but the snd_hda_intel driver caused the machine to not shut down correctly. One rmmod line into /etc/default/halt and it shuts down perfectly and fast again. :-) See also the hint in the Debian Wiki.
• Even more: I’m sure that it not even has been turned by being hit by something through its neopren bag inside my backpack as I initially expected. It turned out that I must have not noticed that it wasn’t properly shut down and put it in the neopren case in that condition :-( since the power button simply doesn’t work when the lid is close. The good news: It doesn’t seem to have carried away any damage. :-)
• I had the same problem as Beat had: I couldn’t import certificates into my Nokia E51 mobile phone. I already tried to import the PEM and the DER versions of the CAcert root certificates but it just didn’t work. After Beat found out (Kudos to maol who pointed me to Beat’s blog posting), which certificate format is necessary, I found out that while the CAcert PEM certificates have the correct Content-Type header (application/x-x509-ca-cert) the DER certificates have not — they are served as text/plain. Downloading them to my server, adding the right content type to the config and downloading them from there again with the mobile phone worked fine and I now don’t need to acknowledge anymore the certificate of my IMAP server each time I want to read my e-mails on the mobile phone. :-)
• One more EeePC thing. During a discussion on the debian-eeepc-devel mailing list, I noted that the maximum summed up resolution of the internal and external display seems to be 800×800, but it turned out that you can configure that in your xorg.conf. :-) The screen section of my xorg.conf now looks like this:

  Section "Screen"
          Identifier      "Default Screen"
          Monitor         "Configured Monitor"
          SubSection "Display"
                  Virtual         2048 2048
          EndSubSection
  EndSection
  

  See also the xorg.conf in the Debian Wiki.

So if I sum up the smileys in this blog posting, I get 5 happy ones and only 2 sad ones. I think being happy outrun being unhappy today. ;-) Now I want to dive into my bath tub to get this smell of burning servers off me and my cloths. ;-)

Been rather busy, so I haven't had a chance to continue recording the trip... We got into Zurich (albeit late), without incident. Immigration was the biggest joke ever. There was no paperwork at all, and we just handed our passports to the guy, who just looked at them casually, and waved us through. No stamp, no scan, no nothing. It was a bit disappointing really. We got our rental car, and drove around aimlessly for a bit, until the GPS got lock, and then headed for Prague. We went through Austria, where the guy at the border did give our passports a more thorough inspection, more because we were confused and were waving them at him. He also gave us a stamp. The woman from Hertz told us we needed to buy some sort of highway sticker for the car to drive in Austria (wow it's hard to type "Austria", "Australia" just keeps coming out from muscle memory), so we bought one of them and stuck it on the windscreen, and then promptly entered Germany. The autobahns in Germany are wicked! Everyone's screaming along at a ridiculous pace. The fastest I got up to was 180 km/h. The roads themselves were surprisingly quiet, and only two lanes. We stopped off for dinner somewhere in Germany, and finally arrived at the hotel in Prague at about 1am on Sunday morning, so it took about 7 hours instead of the 6 that we'd estimated. We got to bed by about 2am. I woke up at about 10am, then went back to sleep until about 2pm. We finally ventured out for a bit of exploration at about 3pm on Sunday. One observation about Czechs: they seem like a pretty dour bunch. Here we were wandering around, being all wide-eyed and touristy, smiling at everyone, and they'd just scowl back at you, no matter how hard we tried to get a smile out of them. After that initial wander, we discovered that there was a Metro station right across the road from the hotel in another direction, so we caught that to go and check out Prague Castle. The Metro system is another one of those great subway systems that I love. It ran regularly, so you didn't need to concern yourself with a timetable. The ticketing was a bit bizarre. It seemed totally honor-system based. There were no barriers to stop you getting in or out. It was fairly late by the time we got to Prague Castle, so we just wandered around the grounds, took a look inside Saint Vitus's Cathedral, and caught an orchestral performance in Saint George's Basilica, then headed back to the hotel. Everything at Prague Castle was pretty mind-blowing. The size of grounds. The view. Saint Vitus's Cathedral. The Cathedral was huge. When you stepped inside and looked up... words can't describe it. It was amazing. Unfortunately, we didn't bring a camera with us, so we don't have any photos from the Sunday excursion, but Sarah went back this afternoon, and her photos are here. I think the thing that struck me the most was that here were some seriously old buildings - older than my home country, and they were in amazingly good condition. They really built things to last back in the day. The weather so far has been pretty miserable, and if the forecast is anything to go by, will remain miserable until we drive out on Saturday. We've survived, language-wise. The default language of the hotel staff seems to be English, and most random people we've had to interact with seem to speak English. I feel really arrogant and rude just speaking in English to people without first asking if they speak English, but I'm also getting really sick of starting every conversation with "Do you speak English?" The printed language is by and large indecipherable. The currency, which in English is called a "crown" is crazy. One US dollar buys about 16 Czech Koruny, and the prices are ridiculous. A glass of wine at the hotel is maybe 250 CZK. Granted, the hotel prices are obscene, but seeing triple-digit prices for a glass of wine seems totally bizarre. The prices in general seem pretty steep. Sarah said she got a 2 koruny coin in change today. We've got no idea what you'd actually use that for. Last night, after the conference had finished for the day, we wandered off in a different direction again, and wandered through the grounds of Vy ehrad Castle. The Cathedral of Saint Paul and Peter has an amazing graveyard in it, including the grave of the composer Dvorak. We grabbed some dinner at a nearby restaurant, which was substantially cheaper than the hotel restaurants. Again, we forgot to take a camera with us.

The recent OpenSSL incident can not be hidden. It was a very important blow to the Debian project's public face and reputation. A major hole slipped under the door in the form of a bugfix - and with all the good intention. This was not a deliberate attack, nor was it the result of a bad or sloppy maintainer - It was a honest, although painful, human mistake.
Several people started laughing at our processes and supposed strengths right away. I do, however, feel this shows how Debian is stronger security-wise than any other system. And it also shows how this saying, with enough eyeballs, all bugs are shallow, not only didn't lose validity, but was reaffirmed. Free Software development was also proved to be better than security through obscurity again.
Why?
Because were it not because of OpenSSL (and in this case in particular, Debian's packaging) being Free and subject to a code audit, this problem would have never been found. I have been asking to some friends who are part of different black-hat groups, and looking for this kind of information on the Web, it seems that -were it not for Luciano's work, we would still be running cryptographically weakened versions of OpenSSL for a long time. After all, 32768 possible keys is still quite a lot for a black-hat group to find as uneven noise, as a lead to showing the undeniable weakness.
It took two years to find the bug, yes. But it was found doing quality assurance work on publicly available source code. It was promptly fixed, mitigating (as far as possible) as much damage as could be caused. Tools for finding and fixing the defective keys were crafted and freed together with the announcement. Yes, there will be some compromises due to this, I'm sure, but an embarassing hole has been dealt with in the best way possible.
Anyway... I am very happy - I was going over Luciano's NM report, and found something I only suspected but was not sure about. I can now state clearly: I have never been so happy to advocate somebody to become a DD.
Luciano wrote a very good blog post (in Spanish) with his viewpoints on the Debian OpenSSL incident. If you happen to understand Spanish and are reading this blog, please drop over Luciano's.
Luciano: Once again, my hat goes off for you :-)

Mom and I went to Wal-Mart today to pick up two digital converter boxes (specificlly coupon-eligible converter boxes, “CECBs”) as emergency backup for Comcast’s frequently-incompetent cable service in Memphis. It took about 15 minutes for the assorted checkout staff figured out how to ring up the converters and use the government coupons for them, but eventually we escaped with two RCA DTA800B converters. I found the box relatively easy to use and hook up. The boxes included quick start guides in English and Spanish and full user manuals in both languages, as well as a programmable remote control (with batteries) and a short push-on coax (F-type) cable for attaching the box to a TV over the “antenna” TV input. Both boxes worked moderately well in southeast Memphis with a rather lame RCA unpowered indoor VHF/UHF antenna I picked up a while back, which is no Silver Sensor but a bit more compact to haul around, less likely to attract quizzical stares from airport security, and better than nothing at all. Neither box was able to scan WMC‘s rather weak digital signal (authorized at 394 kW but clearly not transmitting at anything close to that power) and there’s no manual tuning option. I’d imagine if I’d brought a decent directional antenna like the Silver Sensor I’d have gotten WMC and a more stable signal on some of the other channels. So, overall, I have no real complaints about the boxes themselves, except for the lack of a manual tuning feature available on other converters, and the SmartAntenna feature will be nice for folks with hard-to-tune channels in multiple directions when you can actually buy one again. I’ll probably examine some of the other CECB models before settling on one, however, particularly now that it appears that the reported Zenith DTT900 audio problem is fixed in newer boxes.

One of the most interesting debates concerning new technologies is whether human enchantment technologies have any reseamblance to the older practice of eugenics. One of my favorite articles on this subject is by The Case against Perfection, which simply stunned my students (and they are pretty hard to stun). Recently, the Chronicle of Higher Education published a couple of articles on the topic, and I wrote a response to one of them, (which as you will see, irked me some) here. While I agree with the author that medical genetics is not eugenics, it is still worth our while thinking through today’s genetic and reproductive technologies through the eyes of historical instance of eugenics.

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.)

I’ve just released pommed v1.18, which is mainly a maintenance release. I’ve added some more USB IDs for Apple external keyboards and relaxed the event devices identification for internal keyboards. pommed will now happily start on a machine fitted with a keyboard+trackpad assembly that normally isn’t found on this model. This can happen when the topcase of the machine is replaced with the wrong part. I expect this situation will happen more and more often as people buy parts from EBay or similar to repair their laptops.

(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.

The OpenSSL fiasco has started a fresh discussion on Debian source packages and the way we handle changes to upstream software. One of the issues under discussion is that some Debian packages don't use a patch system and ship all their modifications unseparated in the Debian .diff.gz, which makes it harder or impossible to extract patches later on and to understand why some changes were made. The commonly recommended way of doing things is instead to keep the upstream source pristine, storing modifications cleanly separated and documented under debian/patches; several tools such as quilt or dpatch can make this process easy.

Out of curiosity, I did a quick scan of my local mirror to see how many packages ship changes outside debian/ in their .diff.gz, and I was surprised to see that 4803 source packages out of 11853 (40%) do so! This is much more than I expected. Some packages even use a patch system but still have changes in .diff.gz, as shown by this lintian check.

The most commonly patched files in affected packages are:

   1006 config.sub
   1002 config.guess
    823 Makefile
    754 configure
    715 Makefile.in
    484 aclocal.m4

Most of these are caused by autotools updates which are necessary if upstream ships old versions of these files. In many cases there are clean ways to deal with this, for example to always have up-to-date versions of config. guess,sub you can simply make them re-exec their authoritative versions (as shown by this patch) and build-depend on autotools-dev.

If you don't use a patch system, now is a good time to start. The New Maintainers' guide has more information on the topic.

There are obviously some things we need to remind if we don t want something like the OpenSSL debacle to happen again. It doesn t mean we need to throw stones nor to rush into changing our processes without thinking. However, there are already some things that should be obvious but unfortunately are not.

1. Shipping a giant diff.gz that contains all changes in one, putting security fixes, policy fixes, bug fixes, cosmetic changes and autotools files at the same level, is not something we should accept anymore. Improvements in the dpkg-source format are much welcome in this direction, but they are useless if maintainers don t use them. Neither a VCS nor a build tool will be able to know which line of the changes is related to which bug. Only the maintainer can.
2. Core packages should all have co-maintainers. This is pretty much stating the obvious, and is much easier said than done. The OpenSSL case is one of the best examples here: Kurt is not one of those who refuses help, but frankly, would you want to maintain that package? Having already maintained packages with messy code, upstreams not understanding at all the needs of a distributor, avalanches of security alerts and randomly-changing ABIs, I can tell you this is no fun like it can be to hack on a desktop environment or a device driver. The only sane reason to do this is that you need the package to work. The only visible result you get from your work is that programs are not randomly crashing.
   I have no magic recipe to propose so that more people help with such packages, and that s where we need to be really innovative. Cross-distribution teams, mandatory co-maintainership on a core package for each DD these (and all ideas I have not heard of) are the experiments we should start now.
3. Patching bad code leads to unpredictable results. What maintainer of a complex package has not introduced a new bug while trying to fix another one? Even when a piece of code is maintained by uncooperative developers, is not commented, uses arcane variable names or is impossible to understand without having contributed 3 winning entries to the IOCCC, it needs to evolve. And in these cases, it is only a matter of time until such things happen.
   Don t get me wrong: I m not trying to put the blame on upstream here. They have contributed very valuable code to the community and their work helped in the considerable widespread of cryptography. It s just that their code is not enough for our needs. If we can t patch it safely (and I m now convinced we can t), maybe we need to focus on alternatives and help them getting used by crypto-related packages. The code in GnuTLS and NSS is not necessarily better, but most (if not all) patches Debian needs to apply to them are build and portability fixes.
4. Unless Debian-specific, 1 patch = 1 bug in the upstream tracker. This should be obvious, but given the number of patches that are never forwarded, it doesn t seem so. You should not only give a chance for upstreams to review the patch, but you need them to track it, and you must give them the chance to review it anytime someone else stomps on a similar issue. If upstream does not have a bug tracker, they probably think their software has no bugs. Which means they are not trustworthy, and we go back to point 3.
5. We need to give more priority to security. Issues in the security team seem now fixed for good and they have been doing an awesome work. There isn t much left to do so that packages are all built with security-hardening features, but it still needs to be done. And there is much more to do so that we can provide out of the box a decent SELinux setup, or, if it turns out unrealistic to do, a decent system hardening setup using another framework. I know the SELinux zealots will jump on their high horses to explain that their framework is better, but the current situation where it is impossible for the average system engineer to setup a Debian-based MAC system is much worse than having a suboptimal setup that already works.

All in all, this incident has a great impact on Debian s image. If we don t react accordingly, adapting our processes and our system to match what our users expect from us and they expect the best they will turn away from us. With very good reasons to do so. Update : It seems OpenSSL does have a bug tracker. Thanks Kurt for pointing me to it.

To follow this little screencast tutorial on editing Web applications:

• apt-get install vim curl subversion on a Debian install
• Letterly source I use for an example
• .vimrc see CleverTab()
• HTML5 VIM script for validator.nu

Recorded with recordmydesktop—follow-mouse -width 256 -height 256. I had to record it on my Thinkpad X40 as my X61 sound setup suffers from some sort of overrun. Couldn’t figure out jackd. Validator.nu is for helping find problems with HTML not PHP, so sorry for the sideline 2:30 mins in the video. :) Finally also “checkout” Google doctype.

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.)

Since I live in Prague, it's basically compulsory to go to FOSSCamp. Yesterday I went with Lucas to some pubs + sightseeing, today we went in a larger group to this pub:

and we had a couple of good Czech meals with Plze beer:




Seems it tasted good:

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

How does one convert between SSH keys and SSL keys?

Let us first divide the problem into two parts.

Private Key availableThe simpler case is when you have the private key. In this case, SSH private key is in fact the same as an SSL key. If the key was generated using ssh-keygen -t rsa then it is a 2048-bit RSA private key for SSL.It follows that it rather trivial to extract an SSH public key from an SSL private key. You just run

ssh-keygen -f private_key_file -y > ssh.pub

This will prompt you for a password if your key is kept encrypted as it should be. The ssh.pub file contains the SSH public key.It is similarly easy to extract the SSL public key from an SSH private key.

openssl rsa -in private_key_file -pubout -out ssl.pub

will create ssl.pub containing the SSL public key.

Private Key un-availableThe more difficult case is when you only have the SSH public key or an SSL certificate. In this case one should be able to extract the SSL public key from the SSL certificate and interchange between the SSL and SSH public keys.The extraction of the public key from the SSL certificate is achieved by the command¹

openssl x509 -in cert_file -pubkey -noout > ssl.pub

which extracts the public key from the SSL certificate.

The MessThe second part, i. e. converting between SSH and SSL public keys, has a rather tortuous route given that the data contained in the public keys is the same!First of all one needs some somewhat un-common utilities (which are currently only in sid on Debian)

apt-get install lsh-utils 

This pulls in the nettle-bin package which also contains some useful programs. So one can run

ssh-conv < ssh.pub   sexp-conv 

To get a look at the "real stuff" inside the SSH public key.If ssl.pub and ssh.pub refer to the same key then you will see that the output of

ssh-conv < ssh.pub   sexp-conv -s hex

and

openssl rsa -in ssl.pub -pubin -noout -text

are entirely similar and clearly inter-convertible. The same applies to DSA keys with the openssl rsa replaced by openssl dsa in the command above.One could easily write a script that would massage one of these text formats into the other. Luckily, someone did it for us. So we run

sed -e'1d' -e'$d' < /tmp/test.pub   \
 pkcs1-conv --public-key-info --base-64   \
 sexp-conv   \
 sed -e'1s/(rsa/(rsa-pkcs1-sha1/'   \
 sexp-conv -s transport

The output of this is identical to the output of

ssh-conv < ssh.pub   sexp-conv -s transport

Hence, we have reached the point of convertibility! The full pipeline is

sed -e'1d' -e'$d' \< ssl.pub   \
 pkcs1-conv --public-key-info --base-64   \
 sexp-conv   \
 sed -e'1s/(rsa/(rsa-pkcs1-sha1/'   \
 sexp-conv -s transport   \
     lsh-export-key --openssh > newssh.pub

ConclusionHaving got this far the reader may be wondering what the purpose of this (lack of) exercise is --- other than writing complex pipelines instead of real code.

Answer:

Since you can now convert certificates into SSH public keys you can check these certificates against the SSH public keys that became bad as a consequence of the recent fiasco.Moreover, to do this you do not need to have access to the private keys of the certificates.

So help out a friend by checking whether their SSL certificate is based on a weak key. However, note that the above procedure doesn't work for DSA keys. In addition, the publicly available tests for bad keys do not work with 1024-bit RSA keys. If your friend has been using the letter type of keys on a Debian "etch" system then you should advise them to change keys anyway (and switch to 2048-bit RSA in the process).

---

1. Locating this command took a bit of effort since the -pubkey option to x509 is not documented on its man-page. Rather it is documented on the rsautl man-page. (See: Debian Bug #291095). ↩

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.