Yesterday I was visiting the Open Source Expo Karlsruhe, a new, quite small conference, at which the guys from OpenStreetMap hat a booth. I was amazed by the progress of OpenStreetMap while I wasn t looking (which is just a few months, I guess); their level of detail in some places like Karlsruhe is astonishing.Anyways, I got hooked and started to try out some of the tools and websites and finally, by tracing the Yahoo satellite image, added my first way to the map: A small footpath in Herrenberg that I know quite well: The live data can also be seen on the OpenStreetMap map, of course.Unfortunately, there is not much to map around where I live in Karlsruhe, even the driveway to my dorm is included, but maybe I can do some proper mapping (with a GPS device) in Herrenberg someday.

A few months back, keithp introduced me to Treehouse/Icehouse as a generic system for gaming, like playing cards. Recently I realized that I didn't actually know many card games, and most of those that I did know I'd forgotten long ago. So today I spent a good chunk of the afternoon learning a few new games and playing them. John McLeod's site was the first hit I found on Google, and it's a phenomenal resource full of games from all over the world. The games that I learned or re-learned today were Casino, 500 Rum (which is a Rummy/Gin Rummy variant), and German Whist.

It's striking how many games are generally unknown these days. We have so many other forms of entertainment available that we've collectively forgotten how to play most of these games. It's fun to be reminded what you can do with a simple deck or two of cards though.

---

Update Added screenshots

---

I spend a lot of time working in front of a screen (many hours in a dimly lit room) and eye fatigue is an issue. A consistent color scheme, especially one which is easy on the eyes, is important and it also helps to have way of doing that where the directives are not all scattered all over my Emacs-lisp setup. Enter Emacs Color Themes, available as the Debian package emacs-goodies. Aided with a HSL color picker, I set around trying to create a dark color theme for Emacs. It does not help that I am blue-green color blind, so subtle variations are often lost on me. I do want to use color contrast to increase productivity, but I also want to avoid the jarring angry fruit salad look, and so I am in the process of crafting a logical color scheme that is high contrast enough for me, without being too unpleasing. In circumstances where there a lot of related faces that can be viewed, for example, the Gnus group buffer, consistent and logical color choices are the only sane option. Gnus groups can be news (bluish) or mail (greenish), have states (large number of unread messages, normal, and empty). The large number unread groups have highest luminosity (appear brighter), and the empty one have lower luminosity (appear greyer), but have the same hue and saturation. Sub states and group priorities are rendered using a color series which has constant luminosity and saturation, and vary in hue by a constant separation so all the related groups have the same brightness ( mail,news / unread,normal,empty ), and a graded selection of foreground colors. It sounds more complicated that it looks. The eye is drawn naturally to the unread groups, and first to the mail, then USENET groups (which is my preference). Similar color variations occur for individual messages in a group; high scoring messages bubble to the top, and have a higher luminosity. This color schema has made me slightly faster at reading mail/USENET. In the message itself, quoted mail messages from different people are color coordinated, with high contrast between citations that are close to each other in the hierarchy, so it is less likely that one misunderstands who said what in a long conversation. The resulting scheme covers programming languages, Gnus, Erc, mail, org-mode, CUA-mode, apt-utils, bbdb, compilation buffers, changelog mode, diff and ediff, eshell, and more. This has allowed me to consolidate all my color directives into a single file, and is in a format that might be usable by others. See the wiki page for details about how to use and switch color themes in Emacs. Enjoy.

FYI, if you're not using xdm/kdm/gdm but are instead starting the X11 server manually with startx (which is what I usually do) you might have experienced brokenness in Debian unstable recently:

Fatal server error:
Unrecognized option: /etc/X11/xinit/xserverrc

This is already reported as bug #482425 and #482527 and should hopefully be fixed soon, but in the meantime this patch against /usr/bin/startx should work around the issue:

--- /usr/bin/startx.orig 2008-05-26 18:21:26.000000000 +0200
+++ /usr/bin/startx     2008-05-26 18:21:36.000000000 +0200
@@ -107,9 +107,7 @@
 if [ x"$server" = x ]; then
     # if no server arguments or display either, use rc file instead
     if [ x"$serverargs" = x -a x"$display" = x ]; then
-       server=$defaultserver
        serverargs=$defaultserverargs
-       display=$defaultdisplay
     else
        server=$defaultserver
     fi

Hope that saves some people out there lengthy investigations and hassle.

A small memo in case it happens again… Maybe this can also help others… I have made a typing error when incrementing a zone serial number this morning (I though we were in year 2009!). I realized this error after the transfer was made to my secondary server, and I couldn’t figure out how I could fix this: if the serial number on the slave server is lower than the serial number on the master, the slave server will attempt to update its copy of the zone. I have read some websites explaining one should add 2147483647 (2^31-1) to the number, reload the zone, let the slave get updated and revert to the appropriate serial number. Unfortunately, this solution hasn’t worked for me. I have read in RFC 1912 (section 2.2 - SOA records), that the system was planned until year 4294. I have henced updated the number of my master server to year 4294123199 (ie. the last possible serial number), reloaded the zone. After the transfer was propagated to the slave, I could simply revert to a standard serial number.

To continue the CECB mini-review series, I picked up an LG/Zenith DTT900 at Circuit City in Southaven this evening with one of my two digital converter box coupons (and $24ish of my hard-earned money at Sam’s Town’s blackjack tables). With essentially the same setup and conditions (same television and el-cheapo VHF/UHF indoor antenna) as the RCA DTA800B tested before, the initial channel scan found the same 17 channels/sub-channels. However, the Zenith’s ability to manually add channels meant that I was able to add WMC-DT/NBC 5 (RF channel 52) and with some fiddling get a reasonably stable signal, something I was unable to accomplish with the RCA—this isn’t that surprising, since the Zenith is based on LG’s ATSC digital tuner chipset, which is known for its superior reception capabilities over most other silicon. In addition, other channels (WHBQ-DT/Fox 13, WPTY-DT/ABC 24, and WLMT-DT/CW 30) that were less-than-stable with the RCA were rock-solid with the Zenith. Bear in mind that WMC is running on a different frequency (and lower on its tower) than it will after the transition is complete in nine months, so indoor antennas in Shelby County at least should cope better with WMC when it is back on VHF channel 5. The built-in guide is a little weaker than that included on the RCA model; the Zenith’s only shows program data for one channel at a time. The Zenith, however, has more functionality accessible from the remote control, including a “favorite channels” feature that would be useful for the compulsive surfer who isn’t interested in switching past the news and weather loops on 3–2 and 5–3 when doing the Letterman/Leno (or Conan/Craig) shuffle, and a sleep button. I also thought the Zenith’s menus were a little more polished and better organized. On the antenna front, the Zenith, unlike the RCA, does not provide an attachment for digitally-steered “SmartAntennas,” which may be a consideration if you already have one of these (they are apparently uncommon at present) or have hard-to-tune channels in multiple directions which might benefit from this high-tech solution. The Zenith’s better signal-handling may reduce the need for a fancy antenna, however; either way, you should probably check out TVFool’s antenna aiming guide or the somewhat less-friendly CEA/NAB-sponsored AntennaWeb website to determine what sort of antenna solution is going to be necessary for you before spending money on one. The only real problem I encountered in testing was that the “zoom” setting seemed to behave oddly; at first, letting it decide on its own seemed to work OK on some channels, but then I ended up with some bizarre “squeezed” pictures on several HD channels. Expect to manually fiddle with the zoom setting when channels switch between showing native 16:9 and pillarboxed 4:3 programs. Those who use closed captioning will also find that it seems to forget the CC setting when you switch channels, although I think there’s a menu option to leave closed captioning on all the time. Finally, caveat emptor: many manufacturing runs of this converter, and its near twin sold by Best Buy under its Insignia house brand, apparently have an audio problem that certain TVs seem to be more susceptible to than others. The converter I purchased had a manufacturing date of April 2008, which has been reported to be the run in which this problem was fixed, and I observed no audio problems during my testing (on an admittedly low-end CRT stereo television/VCR over RCA cables). Overall, I’d assess the LG/Zenith DTT900 as a better option for those who are planning to use the converter on a regular basis; however, if you’re simply buying a converter to serve as a “lifeline” when cable or satellite television is disrupted, or if you would like to take advantage of the SmartAntenna connectivity on that unit, the RCA model is probably adequate for most needs and seems to retail for about $10 less.

Last week-end, I was in Prague for FOSSCAMP, a Canonical-sponsor event aiming at bringing together people from various Free Software projects. Such an event is a very good idea, especially after the openssl debacle, where we saw how difficult it is to build good relationships with other Free Software projects. The event was organized in a rather interesting way: the attendees make up the schedule as the event happens, by adding sessions to the timetable using marker pens on a whiteboard (see picture, hi Jorge!). If we have a spare BOF room at Debconf, it would be great to do the same thing: I always find it frustrating that many important discussions at Debconf happen outside BOFs/lectures, and are so easy to miss, simply because you submit talk proposals months before Debconf, so you can’t know yet what will be the hot stuff when Debconf finally arrives :-) It was also interesting to see all the different ways people organized BOFs. It might be interesting to write a list of DOes and DON’T about BOFs (not that the sessions weren’t of good quality!). Does anyone know if such a list already exist? And finally, as usual, it was great to meet all those people from this nice community again. If you still believe that some projects are fighting with each other, you need to attend such an event. And special thanks go to Ond ej ert k for guiding me through a visit of Prague!

Matt Bottrell has written about some issues related to the acceptable weight of laptops for school use [1]. Matt cites a reference from the Victorian government stating that a school bag should not be heavier than 10% of the body weight of the child who carries it [2]. So the next thing we need to do is to calculate what a student can carry without being at risk of spinal injuries. Firstly we need to determine what children weigh, if we restrict this to the 14+ age range (the older children have more need of computers) then children are almost as heavy as they will be when they are 18 and can carry significantly heavier bags than those in the 10+ age range. Also it seems reasonable to consider the 25th percentile weight (the weight which is exceeded by 75% of children). Of course this means that 25% would be carrying overly heavy bags but it does give us a bit more weight allowance. The 25th percentile weight for white girls in the US is 48Kg [3]. The 25th percentile weight for white boys in the US is also 48Kg [4]. When considering the Australian situation it seems that white children in the US will be most similar (in terms of genetics and diet). The 25th percentile weights at age 18 are 53Kg for girls and 64Kg for boys. So the acceptable bag weights would be 4.8Kg for 14yos, 5.3Kg for 18yo girls, and 6.4Kg for 18yo boys. The next step is to determine the weight carried to school. The weight of one of my laptop bags is almost 1Kg, I think that a school-bag would have a similar weight. When I was at school I recall that the worst days for carrying baggage were when I had PE (Physical Education - sports), the weight of PE gear was a significant portion of the overall weight I carried. I tried to estimate this by weighing a track-suit top, a t-shirt, and a pair of board-shorts (the only shorts I could find at short notice), and it was almost 1Kg. While the board-shorts might weigh more than PE uniform shorts I didn’t include the weight of track-suit pants. Assuming that a female PE uniform has the same weight as a male uniform is the least of my assumptions. The weight of a good pair of sneakers (suitable for playing basketball and other school sports) that is in my size is just over 1Kg. To get a rough estimate of the weight of lunch I put six slices of bread and a small apple in a lunch box and found that it weighed 500g. A real lunch would probably include four slices of bread but the other things would weigh at least as much as the extra two slices. If a drink was included then it could be more than 500g. So the total is 3.5Kg for bare essentials (including PE gear) without including any books! It seems that it would be impossible to stick to the government recommendations for school bag weight if a full set of PE gear is included. Probably the best thing that could be done would be to make a school uniform allow wearing sneakers which removes 1Kg from the overall bag weight. So a bag with lunch and PE gear (minus sneakers) is about 2.5Kg, leaving 2.3Kg for books etc at age 14. As text books for 14yo children are considerably thinner than those for 18yo children, it seems that this might be achievable. Fitting a couple of text books and an EeePC into the 2.3Kg weight budget should be achievable. But fitting a full size laptop (which seems to start at about 1.8Kg) and some text books into a 2.3Kg budget will be a challenge - it might be possible to do that but wouldn’t leave any budget for the random junk that children tend to carry around. For an 18yo girl, the weight budget (after the basics have been deducted) is 2.8Kg, it seems likely that on occasion the weight of year-12 text books will exceed that. Therefore it seems that the only way of avoiding spinal injuries in year-12 girls would be to have text books stored in digital form on a light laptop such as an EeePC. Rather than avoiding the use of laptops because of weight (as some people suggest), laptops with electronic text books should be used to replace traditional text books! An EeePC weighing less than 1Kg will give a significant amount of extra capacity for any other things that need to be carried. If there is little other stuff to be carried then 75% of 18yo girls should be able to carry a full size laptop plus PE gear without risk of back injuries. If digital text books are used then if in any journey two text books (which according to my previous measurements can be as much as 1.6Kg [5]) can be replaced with an EeePC then overall something like 600g is saved (depending on the configuration of the EeePC, if one battery was stored at home and another at school then it could save more than that). It seems that a year 12 girl who has PE and three science subjects scheduled on the same day would be most likely to exceed the recommended weight in the current situation (even without having to carry a spare pair of shoes), and that carrying a laptop with digital text books would be the only way of avoiding back injury. For an 18yo boy the weight budget is 3.9Kg after the basics have been deducted. So if they don’t carry other random stuff in their bag (I probably had 1Kg of random junk in my bag on occasion) then they could carry PE gear, a full sized laptop, AND a full set of text books. It seems to me that there is no situation where children would be unable to have a laptop within the reasonable weight allowance if digital text books were used. The only way that the weight of a laptop could be a problem would be if it was carried in addition to all the text books. One final point, it would be good if books from the Gutenberg project were used for studying English literature, that’s one easy way of reducing weight (and cost). Also it would be good if there was an option for a non-literature based English subject. Knowledge of English literature is of no value to most students. It would be better to teach students how to write while using topics that interest them. Maybe have blogging as an English project. ;)

• [1] http://matt.bottrell.com.au/archives/155-Laptop-clarifications.html


• [2] http://www.betterhealth.vic.gov.au/bhcv2/bhcarticles.nsf/pages/Back_pain_schoolbags?open


• [3] http://www.halls.md/on/girls-weight-w.htm


• [4] http://www.halls.md/chart/boys-weight-w.htm


• [5] http://etbe.coker.com.au/2008/02/18/laptop-vs-book-weight/

Share This

Back from my travels, it's time for a few updates. I've mostly blogged about these elsewhere, so I'll just give some pointers here. The launch of magnetic-stripe cards at Where 2.0 went well. We had some initial teething issues with Linux talking to the card printers, which was resolved by backing down to Linux kernel 2.6.22 from 2.6.24. I'm not entirely sure what's up with 2.6.24, but it exhibited strange behavior talking to the card printers over ethernet — as if there were MTU misconfigurations. It's a big nuisance, as 2.6.24 is the default kernel shipped with Ubuntu Hardy, an otherwise excellent release. I've been paying some attention to OpenID 2.0 recently, as it's time for me to upgrade my OpenID accepting websites to use the new release of the specification — if for no other reason than Yahoo! OpenIDs are 2.0-only. This investigation led me to notice XRIs again, which are the confusing underbelly of the OpenID specs. The W3C Technical Architecture Group recently advised against using XRIs. I wrote about this over on my XML.com blog. I've not used for that blog for a long time, but will try to do so more. I've realized that I've still got a lot to say about the web, XML and open standards, and the XML.com blog seems like a good place to say it. Finally, to brag for a short moment. Another XTech has been and gone, and this year's was a great experience for everybody involved. This quote from attendee Paul Smith summed things up nicely, as it tells me I succeeded in my main goal for the conference:

What I really liked about this conference was the mix of attendees and presenters, both from academia, and the commercial world both and small. It made it feel much more valid, and it really felt like everyone was there for the right reasons - not trying to sell anything, but out of a genuinely altruistic wish to make the web better.

My sincere thanks to everybody involved in XTech this year.

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

Last Thursday, and the few days after, were quite intense. A series of events made me feel really loved by a lot of people, which is always a good reminder of what kind of friends you are surrounded by. I could talk about Pep's gift at work, Visenteta, a goldfish which now lives in an aquarium at home, which in turn was donated by Cristina and Brande. While I still have mixed feelings about keeping animals in cages, my choices were give it a better place than the small bowl where it initially lived, give it away to someone who could properly take care of Visenteta, or sacrifice it. I unsuccessfully tried #2, can't do #3 myself, so I accepted Brande's offer to have a decently-sized aquarium at home. Visenteta seems happy today, and I've learned all about aquarium maintenance the hard way. During the day my mobile phone didn't rest for too long intervals; everyone was calling it to congratulate me and so on. But the bigger emotions came after leaving work, when I went to l'Alqueria to hang around with my friends and see if they would go have an orxata with Maria and me. Strangely, they refused, being in the middle of an apparently very important plant transplantation operation. When suggested going for dinner instead, the reaction was pretty cold too, but this was understandable as we'd meet on Friday at my place for a tiny celebration. In the end we headed off to Alboraia alone and had a delicious orxata in Toni's shop. Maria said she had a surprise reservation in a Indo-Pakistani restaurant near my house, so after a while we cycled back to Val ncia. As it was getting dark and cold, we went into my house to get some clothes, and when I opened the living room door, I was scared by a bunch of shadows suddenly shouting at me and was buried in confetti. I couldn't react for the next 10 seconds, while my brain quickly built relations of many details that had happened during the week, all part of the preparations for a secret party at my own place. Wow, the feeling is incredible. I've participated in similar surprise parties, but had never been the target. I hope everyone reading this gets one at least once in their lives, I really loved it! But still, when the party ended, I slowly started to find little gifts all over the place: a book under my pillow, a bicycle bell on my handlebar, a cactus for my computer space... My friends had been planning all of this for the last two weeks, and I never suspected anything. Incredible! It really makes me feel surrounded by people who care about and love me, and went through the hassle of coordinating 10 or 12 persons with me not noticing at all. Thank you, everyone! The book, by the way, is Si no plou, plour , by TV3's M nica L pez, a fun compendium of popular weather proverbs which we discovered in a gas station in Tarragona, during our Easter trip to la Terra Alta.

I'm excited by version 7 of debhelper, in particular the opportunity for debian/rules minimization. I suspect this will lower the barrier for rapid, reasonable packaging of simple software tools in a way that should be easy to audit and maintain. The most-minimized debian/rules possible with it is just (from dh(1)):

#!/usr/bin/make -f
%:
	dh $@

And all of the project-specific interesting bits go into nice, clean, well-named files under debian/. However, lintian (at least as of 1.23.48) complains loudly about the minimized debian/rules:

E: xdotool source: debian-rules-missing-required-target binary
E: xdotool source: debian-rules-missing-required-target binary-arch
E: xdotool source: debian-rules-missing-required-target binary-indep
E: xdotool source: debian-rules-missing-required-target build
E: xdotool source: debian-rules-missing-required-target clean

I'm not sure the right way to proceed: should i try to manually add overrides for each package that uses a minimized debian/rules? Should lintian recognize debhelper-specific minimized rules files and accept them? Should debhelper assuage lintian somehow? Or is this rules file minimization actually not as good an idea as I think it is? I notice that mr, which is Joey Hess's first example package using the minimized rules also reports the same errors.Tags: debhelper, lintian, packaging

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.

(This post is mostly as a reminder to myself on how I've set up my backup system. It should probably go on a wiki instead so I can keep it up to date.) After the recent OpenSSL debacle in Debian and Ubuntu, I found that all my backups were encrypted with something amounting to a well-known secret key. Ouch. I was not entirely happy with how my old backup system worked either (it was based on boxbackup). In particular, the on-disk format was opaque, the tools needed to access it were not particularly user-friendly and I had to run Yet Another CA for managing the keys for it. After looking around a little, I settled on rdup which is a tool very much written in the unix tradition of "do one thing and do it well". As it reads on the home page:

The only backup program that doesn't make backups!

(which is almost true). It keeps a list of information about which files have been backed up locally on the machine to be backed up, including some meta-information such as file size and permissions, so it can take a new backup if any of those changes. For more details, read the web page and the source. rdup is more of a framework for making your own backup system than a complete system in its own right, so this post is really about how I have customised it. First, I want my backups to be encrypted, and rdup supports encryption (both GPG and mcrypt). I'm lazy, so I settled on what rdup-simple gives me, which is mcrypt. Key generation is easy enough: head -c 56 /dev/random > /root/backup-$(hostname).crypt.key and then a chmod 600 to avoid it being world-readable. In /root/.ssh/config, I put

Host backup-$hostname
Hostname $backupserver.err.no
User backup-$hostname
IdentityFile /root/.ssh/id_rsa_rdup
ProxyCommand pv -L 40k -q   nc %h %p

so as to make it fairly easy to move stuff around and to make it pick up the right identity. The last bit is a trick to rate limit it so it doesn't saturate my DSL. pv has a wonderful -R switch which lets me change the arguments to an already-running pv, if I want to do that. ssh-keygen -t rsa -f /root/.ssh/id_rsa_rdup to generate an ssh key. It got put into /home/backup-$hostname/.ssh/authorized_keys on the backup server, so the line reads like:

command="/usr/local/bin/rdup-ssh-wrapper",no-pty,no-port-forwarding,no-agent-forwarding,no-X11-forwarding ssh-rsa AAAAB3N

The /usr/local/bin/rdup-ssh-wrapper is a small perl wrapper which only allows the rdup commands and sanitises the command line somewhat. Since I don't want to make a backup of all bits on my machines, I have an exclude file, which lives in /root/rdup-exclude. It is just a list of regexes of files to ignore. To actually make a backup, I run something like for p in /etc /home /var; do rdup-simple -v -a -z -E /root/rdup-exclude -k /root/backup-$(hostname).crypt.key $p ssh://backup-$(hostname)/srv/backup/$(hostname)/$p ; done which then goes on for a while. It gives me nice structures with hard-linked files to avoid using more disk space than needed. I can then just have a small find(1) script prunes old backups as I don't need them.

Yes Erik, SourceForge did not do anything. But what is even more "funny" is that changing keys over web interface does not change ~/.ssh/authorized_keys. So even if you are aware of this problem and change keys in interface which should do it, it does not work. I just realized this today when I read your post and wanted to check whether this file is really world readable...

GNOME has reacted and removed all blacklisted SSH keys from their authorized_keys, which is the minimum you should do to ensure safety.For all I know, sourceforge.net has not yet done so (I didn't check if I could have logged in with my old key, though - maybe they installed the blacklist in the SSH server, not touching the users' keys; there is no blacklist in /etc/ssh though). authorized_keys files are world-readable, so I can login at sourceforge and read other users' authorized_keys. With this approach I believe you could hack dozens of SSH accounts on Sourceforge within a few hours, without having to employ brute-force.These keys could then be used in turn to inject backdoors and/or trojans into other OpenSource projects (where at least one developer with write access did use a vulnerable key).If you were affected by the Debian OpenSSL bug, please replace your SourceForge key as soon as possible. Please verify any commits made on SourceForge until they've taken appropriate measures to block bad keys.SourceForge and other operators of such platforms should install blacklists NOW, and remove any vulnerable keys from their databases.

Looking at the current discussions, I'm wishing some people would calm down a bit. It's always impressive how some things switch sides like pendulums. First of all, Debian already is centered about packing software and not developing them. We already have the rules and policies and methods in place. Our policy states:

If changes to the source code are made that are not specific to the needs of the Debian system, they should be sent to the upstream authors in whatever form they prefer so as to be included in the upstream version of the package.

And our source format shows how important marking the difference is to use: We have explicit .diff.gz files to contain them. The differences are not hidden in same Version Control System (like BSD) or in propretary formats (ever tried to unpack a .srpm without rpm or without downloading some magic perl script?), but in a simple universal understandable format. That said, please remember we are a distribution. Our priorities are our users and not the whims of software authors. We have to find the middle ground between harmful and necessary changes. Patching software to abide the FHS, to allow the user choose their editor or browser in an common way or any other thing to form a coherent set of packages is no bug in Debian, it is a bug in upstream to not allow this at least via some configure option. We have neither the manpower nor the job to rewrite and fork stuff to a usable state, though. Thus we have to keep to upstream and hope they will include our modifications or forward-port them to every new release. Thus, we need both: We need to patch (and in general, the worse the software from a distribution's point of view or from a general point, the more of this we need. This does not necessarily hold in the other direction, though.). And we need and want to show what we change. So our users can find out how exactly the software we ship is different. And so other people dealing with the same software can profit from our changes. (After all, free software is about "giving back" a lot.). And of course maintainer change over time and we want the new one understands what the previous one did. That said, there is of course things that can be improved. But as with all improvements there are things that improve and there are things where nothing is worse than good intentions. Adding more thing to keep in sync is almost always a bad thing in the long run. The easiest way to keep things accessible is to use stuff actually used. I think any additional place to track patches will be futile. A good interface to view the .diff.gz files in our archive in some browser, on the other hand, could hardly get unuseful. The format of a single .diff.gz is of course also improveable. Things like a quilt-like standardized patch series look like a very good idea to me. But the format is of course also very downgradeable. Storing VCS formated information for example, tempting as it is, spoils two very important points:

• universal readability is lost. Everyone coping with software can work with patches or patch series, no matter what tools they use.
• visibility of changes is sacrificed for history. Every single VCS I ever saw primarily coped with history. Even patch based ones represent changes in time and not by itself changes by topic.

And of course, a lot can be improved by just using some rules more strictly. Not using a pristine tarball or a proper subset of one where the first is not possible should not be some mere ignorable non-conformist behaviour, but seen as the serious problem it is.

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