May 15, 2008

Daniel Burrows

Worst Debian day ever.

Regarding the OpenSSL debacle, Julien Blache writes:

Worst Debian day ever since the 2003 compromise. And that was a BAD one.

I disagree. This is far, far worse than the 2003 compromise. The compromise was scary, but the key updates for users were straightforward and as far as we know, user security was never actually compromised. In contrast, every single user who uses Debian or Ubuntu for anything serious is now vulnerable to attacks on their supposedly secure cryptography [0] unless they perform a labor-intensive and error-prone series of steps to regenerate all their cryptographic keys -- not to mention finding a secure way to distribute their public keys to everyone who needs them!

[0]: Update: I should perhaps make it clear that I mean anyone who generated a key on such a system. But in a way this makes things worse: unless you're willing to regenerate every key in sight, you need to check each key manually, which means that there's a nontrivial chance that you'll overlook one and leave yourself vulnerable...

04:56am

Joey Hess

charter

So, Charter will be spying on every web page their customers view, and collating and using this information in a Big Brotherly fashion. But it's for advertising, so it's a good thing, right?

Yeah, right. I signed up for fiber to the home from my local ISP today. $charter_customers--. Oddly, besides not being a privacy nightmare, my local ISP is cheaper too. Who'd have thought.

Anyone using http://kitenet.net/wifi wireless or on the network here: You should assume Charter is spying on you for now.

01:01am

May 14, 2008

Wouter Verhelst

Long live the NMBS

When an emergency occurs in a critical piece of your infrastructure, problems are to be expected. I don't think anyone can argue with that. If you do have a piece of infrastructure so critical that the use of your services all over the country will be affected by it not being there anymore, you'll want to have emergency procedures in place; one of these procedures could be having a backup copy of your infrastructure standing by, allowing it to take over should the primary break down. If you have multiple instances of almost-but-not-quite the same thing, allowing another instance of said thing to take over your functioning should you break down might be a good idea, too. If the emergency that sparks the problem in the first place turns out to be "fire", it might be a good idea to investigate your infrastructure for fire safety; you wouldn't want the same thing to happen all over again in te near future on a different site.

And if things go really bad, you will want to inform your users as much as humanly possible: in today's day and age, that would include posting something on your website, even if that's only reference to a phone number which people can call for more information.

Welcome to the real world. Long live the NMBS... Not.

Last year or so, some critical piece of infrastructure in the Brussels South trainstation burned down. As a result, trains were delayed and often cancelled for months afterwards. This clearly shows they did not have any emergency procedures in place; if they did, train services would have returned to normal after, at most, a few days. Granted, the piece of infrastructure that burned down last year was a power transfer station, which might be hard to replace, but still.

Today, another fire burned down another piece of infrastructure; this time, it was the signalling station in Brussels North. The fire itself occurred around 16:30, and from 17:30 onwards, not a single train could enter or leave Brussels anymore. Right now, more than 7 hours later, it is still impossible to get from or to Brussels. Even here, in Mechelen, it seems impossible to get to Antwerp—the opposite site, but because almost all trains to Antwerp come from Brussels, well...

And of course, the NMBS website mentions none of this. The only thing it mentions is the fact that there are "extra trains to the coast", because of the hot weather. As if anyone would be interested in taking the train right now...

Huge companies. A PITA, that's what they are.

09:48pm

Erich Schubert

Consequences of the SSH/SSL weakness

Let me just point out, that the consequences affect all users of SSH. Therefore IMHO all other Linux and BSD distributions need to release a security update to OpenSSH as well, to prevent the use of insecure (too common) keys, because it threatens the security of their systems as well!

Apparently, there are only about 2^15 different keys generated by the SSH versions shipped with Debian for 2 years. It's really surprising that noone noticed this earler. This is just about 32767 different keys. (For each type, size and endianess, but that still makes this number much much much too low) The weakness is caused by a bad random number generator in the Debian package.

Hackers have already generated all these 32767 different keys, for two key lengths and types. In a few hours, they'll also have generated all the 4096 bit keys that could have been generated. Other key lengths are uncommon and sometimes might even be unsupported. Most people use keys with length 1024 or 2048.

So we now have about 32767 keys which are used by lots of Debian and Ubuntu users. That's not very much. Now you have to realize how the keys are used:

The key is used to log into a system without a password. Sometimes a key is protected with a passphrase (you really should do that), but this doesn't help here, because an unencrypted clone of the key was already generated.

Sometimes (or let me even claim 'often') one such key is also used to login as root into a server. This is equivalent to just 32767 different passwords being used as root passwords. So with about this number of tries, an attacker might be able to log into your server as 'root'!

Now the weakness is 'distributed' by the users, it's not just a server-side vulnerability. If your server is running e.g. RedHat, it doesn't mean it is secure!.

In fact, if your server is running Debian and you installed the Debian security update for openssh, it will be much more secure than the RedHat server. Because the Debian server has a blacklist of keys that are too common. The other-Linux server who doesn't have this blacklist doesn't know that a certain 'weak' key is not trustworthy.

Fixing the bad key-generation is just half of the deal. "Recalling" all the keys in use out there is the big challenge, that affects all systems using SSH (and to a different extend, SSL). The most reliable way is if all other distributions would release a security update as well, which refuses to accept the keys that were generated by vulnerable Debian systems.

Let me just repeat it in other words: Any Linux/Unix/*BSD system is vulnerable that grants access to a key that was generated on an affected Debian or Ubuntu system. (Until the system has a reliable detection method of such weak keys.) Keys are usually generated on the users workstation, so if any of your users is or was potentially running Debian or Ubuntu ... you get the idea.

Note that if you are not careful, you might lock yourself out from your server. If you don't have or remember the password, installing the security update might disable your login key. So if your key is bad, make sure to generate a new, secure key and distribute it ASAP. Also remove any vulnerable key ASAP; remember that hackers now have a list of all possible keys and could use that to brute-force login.

(This is mostly based on from what I heard from others. Still you should take the warnings seriously, I guess ...)

09:43pm

Michal Čihař

Everything bad is good for something

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

08:53pm by Michal Čihař

MJ Ray

Strategy on Strategies

[SNR Event Welcome Slide]
Anyone seen this before?

Today, I went to an event about the Sub-National Review Consultation (as a substitute for someone else AIUI).

I'd not heard about this before, but if you're in England and you've any interest in our regional planning system (which I think you should, if you have your main home here or run a business here), you have six weeks left to comment on the UK Government's suggested changes.

As I understand it, it will move the second-highest tier of planning control from democratically-accountable regional bodies to the business-led Regional Development Agencies, with some oversight by MPs and the very- indirectly-accountable council leaders. I've posted more detail on Co-opNet.

When I asked about local involvement and cooperatives, I was directed towards Local Strategic Partnerships, but I'm pessimistic about how easy it will be to influence regional planning through those: a few weeks ago, I was at the launch of the North Somerset Partnership Sustainable Community Strategy for 2008-2026.

It's a 72-page A4 glossy book which I've still not found time to read properly. I think the size says something about its sustainability. I've posted a little more detail on WsMForum.

I'll try to answer questions about either of them on this blog or those forums...

07:58pm

Romain Francoise

The drunk fox (in London)

Gablé (the incredible indie no-longer-one-man band/art collective from back home) have released their new video: “Drunk Fox in London”. As you might have guessed it features an intoxicated fox, which I like to think has a passing resemblance to Firefox's mascot. Check it out!

07:38pm by Romain Francoise (noreply@blogger.com)

Mike Hommey

Irony

How do you see this message in python2.5 changelog:

* Add README.db4 describing the db4.6 -> db4.5 change (Steve Greenland). Closes: #469770.

when apt-listchanges has been broken by the db4.6 -> db4.5 change ?

07:25pm by glandium (Comments)

Wouter Verhelst

Referer logs

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.

05:33pm

Steinar H. Gunderson

Some maths

Others have written all about the recent Debian OpenSSL security vulnerability; I have nothing intelligent to add about who did what or who should have done what or did not, so I'll refrain.

However, I noticed that several sources mention that DSA is trivial to break given access to a signature made by a bad randomness generator. For instance, Applied Cryptography (Schneier) says (thanks to Peter Palfrader for digging up the quote): Each signature requires a new value of k, and that value most be chosen randomly. If Eve ever recovers a k that Alice used to sign a message, perhaps by exploiting some properties of the random number generator that generated k, she can recover Alice's private key, x. If Ever ever gets two messages signed using the same k, even if she doesn't know what it is, she can recover x. And with x, Eve can generate undetectable forgeries of Alice's signature. In any implementation of the DSA a good random-number generateor is essential to the system's security.

I couldn't find out exactly how, though, so I decided to work it out myself -- it is indeed pretty easy. You don't require much maths either -- although DSA can in principle work over any commutative ring (look Ma, I know fancy algebra words! =) ), simple modular arithmetic is what's usually used, and it's also the easiest to understand.

DSA has a public key consisting of the integers (p, q, g), and a private key consisting of another integer (x). (There are some limitations on them apart from that they are integers, of course, but that's not so important for the algorithm.) The DSA signature of a message m (having the hash value H(m)) consists of two integers r and s, calculated as follows:

r = (gk mod p) mod q
s = (k-1 (H(m) + xr)) mod q

where k is the infamous secret random integer (0 < k < q). (k-1 is the multiplicative inverse of k -- you can think of it as roughly equivalent to 1/k over the real numbers. (I'm deliberately being sloppy with the terminology here :-) ))

Attack 1: If you can guess k, you can also find the secret key x. It's actually quite trivial; take s, multiplied by k:

sk mod q = (H(m) + xr) mod q

subtract H(m):

(sk - H(m)) mod q = xr mod q

multiply by r-1:

((sk - H(m)r-1) mod q = x

and voila. (x is between 0 and q, so we can drop the mod on the right-hand side.)

Attack 2: If you have two messages (let's call them m1 and m2) encoded with the same k, you can also find the secret key x. The trick is to first realize that r in the two messages will be the same (it depends only on g, k, p and q, and all but k are part of the public key), so what you essentially have is:

s1 = (k-1 (H(m1) + xr)) mod q
s2 = (k-1 (H(m2) + xr)) mod q

Now subtract the second equation from the first and the fixed xr term vanishes:

s1 - s2 = (k-1 (H(m1) - H(m2)) mod q

Now finally multiply by (H(m1) - H(m2))-1:

(s1 - s2)(H(m1) - H(m2))-1 = k-1 mod q

and you have the used k, which can be used in attack 1 above.

No MathML was harmed during the making of this blog entry. Does anyone have a TeX plugin for pyblosxom, please?

04:21pm

Nico Golde

nitrogen uploaded to Debian

nitrogen
I usually don't blog about uploads to the Debian archive but since I don't know any similar software in Debian I do in this case.
nitrogen is a wallpaper selection and setting tool with both a graphical (with image preview) and text based frontend to set wallpapers and restore them later.
That's nothing special, there are some tools doing that.
But nitrogen also provides great multihead and xinerama support and is the only tool in the archive I know that is able to set different wallpapers to different monitors!

From the description:
nitrogen is a graphical wallpaper utility that can be used in two
modes, browser and recall.
Some of the things to look for in nitrogen are:
.
- Multihead and Xinerama support (setting different wallpapers for each monitor)
- Recall mode to restore wallpapers via startup script
- Uses freedesktop.org standard for thumbnails
- Can set GNOME background
- Command line set modes for script usage
- Inotify monitoring of browsed directories
Check it out

04:02pm by blog@ngolde.de (Nico Golde) (Comments)

Julien Blache

Of course it’s far worse. Did I tell otherwise?

Dear Daniel,

It looks like you are referring to my post, though you got my name wrong so that wasn’t immediately obvious.

Of course this is far worse than the 2003 compromise in terms of the direct, known and quantifiable impact it has on our users. I don’t think I stated otherwise, so I hardly see why your post starts with “I disagree”.

02:55pm by jblache (Comments)

Biella Coleman

Map it: NNDB

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

01:10pm by Biella (Comments)

Steve Kemp

I still don't know why I'm here

I wasn't going to comment on the recent openssl security update, because too many people have already done so.

Personally I thought that Aigars Mahinovs made the best writeup I've seen so far.

However I would like to say that having 20+ people all mailing security[at]debian.org to say the webpage we referenced in the security advisory is currently blank is not useful, or ask for details already released in the advisory they replied to, or ask for even more details is not so much fun.

Having people immediately start mailing questions like "Huh? What can I do" is only natural, but you can't expect a response when things are as hectic as they have been recently. Ideally people would sit on their hands and bite their tongues. Realistically that isn't going to happen, and realistically this post will make no difference either...

Had the issue not leaked to unstable so quickly (and inappropriately IMHO) then we'd have had a little more time. But once an issue is reported you need to coordinate with other distributions, and etc. Handling something as severe as this is not fun, and random mails from users are a distraction, and a resource-hog.

I should say I was not in any way involved in the discovery, the reporting, the preparation of the fix(es), or the releasing of the update. I knew it was coming, but everybody else seemed to have it well in hand. When there are mails going back and forth for 5+ days with ever-growing Cc: lists, and mailing lists being involved I figure one more cook wouldn't be useful.

So in conclusion:

a. Bad hole.

b. Fixing this will take years, probably.

c. 50+ mails to the security team within an hour of the advisory going public complaining of missing information is not helpful, not useful, and quite irritating. (Albeit understandable).

d. People who don't know the details of an attack, or issue, shouldn't speculate and start panic, fear, and confusion. Esp. when details are a little vague.

e. I still like pies.

Once again thanks to everybody who was involved and put in an insane amount of work. Yes this is only the start - our users have to suffer the pain of regenerating everything - but we did good.

Really. Debian did good.

It might not look like it right now, but it could have been so much worse, and Debian did do good.

ObQuote: X-Men: The Last Stand

12:59pm

Zak B. Elep

Where's the Open?

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

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

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

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

11:31am

John Goerzen

Thoughtfulness on the OpenSSL bug

By now, I'm sure you all have read about the OpenSSL bug discovered in Debian.

There's a lot being written about it. There's a lot of misinformation floating about, too. First thing to do is read this post, which should clear up some of that.

Now then, I'd like to think a little about a few things people have been saying.

People shouldn't try to fix bugs they don't understand.

At first, that sounds like a fine guideline. But when I thought about it a bit, I think it's actually more along the lines of useless.

First of all, there is this problem: how do you know whether or not you understand it? Obviously, sometimes you know you don't understand code well. But there are times when you think you do, but don't. Especially when we're talking about C and its associated manual memory management and manual error handling. I'd say that, for a C program of any given size, very few people really understand it. Especially since you may be dealing with functions that call other functions 5 deep, and one of those functions modifies what you thought was an input-only parameter in certain rare cases. Maybe it's documented to do that, maybe not, but of course documentation cannot always be trusted either.

I'd say it's more useful to say that people should get peer review of code whenever possible. Which, by the way, did occur here.

The Debian maintainer of this package {is an idiot, should be fired, should be banned}

I happen to know that the Debian programmer that made this patch is a very sharp individual. I have worked with him on several occasions and I would say that kicking him out of maintaining OpenSSL would be a quite stupid thing to do.

He is, like the rest of us, human. We might find that other people are considerably less perfect than he.

Nobody that isn't running Debian or Ubuntu has any need to worry. This is all Debian's fault.

I guess you missed the part of the advisory that mentioned that it also fixed an OpenSSL upstream bug (that *everyone* is vulnerable to) that permitted arbitrary code execution in a certain little-used protocol? OpenSSL has a history of security bugs over the years.

Of course, the big keygen bug is a Debian-specific thing.

Debian should send patches upstream

This is general practice in Debian. It happens so often, in fact, that the Debian bug-tracking system has had -- for probably more than a decade -- a feature that lets a Debian developer record that a bug reported to Debian has been forwarded to an upstream developer or bug-tracking system.

It is routine to send both bug reports and patches upstream. Some Debian developers are more closely aligned with upstream than others. In some cases, Debian developers are part of the upstream team. In others, upstream may be friendly and responsive enough that Debian developers run any potential patches to upstream code by them before committing them to Debian. (I tend to do this for Bacula). In some cases, upstream is busy and doesn't respond fast or reliably or helpfully enough to permit Debian to make security updates or other important fixes in a timely manner. And sometimes, upstream is plain AWOL.

Of course, it benefits Debian developers to send patches upstream, because then they have a smaller diff to maintain when each new version comes out.

In this particular case, communication with upstream happened, but the end result just fell through the cracks.

Debian shouldn't patch security-related stuff itself, ever

Well, that's not a very realistic viewpoint. Every Linux distribution does this, for several reasons. First, a given stable release of a distribution may be older than the current state of the art upstream software, and some upstreams are not interested in patching old versions, while the new upstream versions introduce changes too significant to go into a security update. Secondly, some upstreams do not respond in a timely manner, and Debian wants to protect its users ASAP. Finally, some upstreams are simply bad at security, and having smart folks from Debian -- and other distributions -- write security patches is a benefit to the community.

10:48am by nospam@example.com (John Goerzen)

Aigars Mahinovs

Too similar to be different

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.

03:56am by aigarius

Kapil Paranjape

Adding comments to the blog

The configuration of this blog has been explained earlier. There was one thing still missing from this blog --- comments.

The comments plugin that comes in the contrib tarball from the pyblosxom web site is well-documented and easy enough to install. One modification I made is to remove all the javascript stuff since I don't understand the latter.

After all this one still needs some sort of authentication to prevent complete rubbish from cluttering the comments section. The natural candidate was openid which is supported by a plugin from snarfed.org.

This seemed easy enough to configure except that there is no version of these libraries in Debian "etch" (which is what people.imsc.res.in runs). So I downloaded the latest 2.x.x version of these libraries. Since I rarely install my own python libraries, it took me a while to figure out that I need to run

python setup.py install --home $HOME

in order to install it in my home directory. This also needed the codebase variable to be set in config.py.

Unfortunately, this still did not work. The plugin comments_openid.py actually uses the API from the older 2.0.x version of the python-openid libraries.

Some error messages from our web server led me onto a completely different track and I thought that the rewrite rules from the .htaccess file were in error. This was a McGuffin and I had to revert to the comment-free version in order to clean-up the mess. Thank goodness for git!

The plugin currently works with the 2.0.x version of the libraries which may be mildly worse than the 2.1.x version.

Some other things which are not working are e-mail/rdf notification of comments. I don't know if I will bother to fix that.

03:19am

James Morrison

Out of the hospital

I woke up saturday morning with a pain around my stomach, and rather nauseous. After puking for a number of rounds and passing out each round of puking, I decided to stop by the emergency room to see why I would be passing out.

Well, I finally got out of the hospital today. I ended up having my appendix removed since it was causing problems and seemed to be why I was puking on saturday. To verify that I was doing well enough to go home from the hospital I had to do two things:
1) Fart
2) Take a dump

Now, if this could be the exit criteria for other things in life, then life would be very good. The other part of this is that I get to feel proud of myself for every fart this week!

03:53am by Jim (noreply@blogger.com)

Russell Coker

Smoke from the PSU

Yesterday I received two new machines from DOLA on-line auctions [1]. I decided to use the first to replace the hardware for my SE Linux Play Machine [2]. The previous machine I had used for that purpose was a white-box 1.1GHz Celeron and I replaced it with an 800MHz Pentium3 system (which uses only 35W when slightly active and only 28W when the hard disk spins down [3]).

The next step was to get the machine in question ready for it’s next purpose, I was planning to give it to a friend of a friend. A machine of those specs which was made by Compaq would be very useful to me, but when it’s a white-box I’ll just give it away. So I installed new RAM and a new hard drive in it (both of which had been used in another machine a few hours earlier and seemed to be OK) and turned it on. Nothing happened, I was just checking that it was plugged in correctly when I noticed smoke coming from the PSU… It seems strange that the machine in question had run 24*7 for about 6 months and then suddenly started smoking after being moved to a different room and being turned off overnight.

It is possible that the hard drive was broken and shorted out the PSU (the power cables going to the hard drive are thick enough that it could damage the PSU if it had a short-circuit). What I might do in the future is keep an old and otherwise useless machine on hand for testing hard drives so that if something like that happens then it won’t destroy a machine that is useful. Another possibility is that the dust in the PSU contained some metal fragments and that moving the machine to another room caused them to short something out, but there’s not much I can do with that when I get old machines. I might put an air filter in each room that I use for running computers 24*7 to stop such problems getting worse in future though.

I recently watched the TED lecture “5 dangerous things you should let your kids do” [4], so I’m going to offer the broken machine to some of my neighbors if they want to let their children take it apart.

Share This

02:47am by etbe (Comments)

Erich Schubert

The Debian OpenSSL disaster

I've read some more about this and especially had a look at some of the source code, so I've completely revised this blog post.

There is no doubt that the Debian Maintainer who added this patch screwed up, seriously. But he's not the only one to blame:

  • OpenSSL isn't valgrind-clean. It should be made, since valgrind is a very important debugging tool; the bad patch was introduced to make OpenSSL better in this respect due to the request by the users.
  • The OpenSSL source code could be better documented in these places.
  • There are two instances of this line in OpenSSL which can both generate the 'using uninitialized data' warning. One is safe to remove (it's supposed to fill the buffer with random data, and just uses the existing contents as additional source of randomness), the other is not (it's used to feed randomness coming from e.g. /dev/random into the pool).
  • The Debian maintainer received the reply "if it helps with debugging, I'm in favour of removing them" by one of the current OpenSSL devs on the openssl-dev mailing list. Probably just referring to the 'safe one' of the two locations where this occurs, though?
  • Nobody noticed the severity of this change for more than 2 years. We're all to blame.

I'm really sick of hearing comments like "Still, whoever took out the entire initialization should not be trusted with security intensive code." (guest comment on LWN). Yes, he screwed up there. But you bet he's going to be a lot more careful with any change in the future: he has learned his lesson. Better than having someone else screw up in a similar way again. And actually he didn't do this change half as easy-hearted as many people suggest, if you look at the discussions on the bug report and mailing lists. He was trying to fix the valgrind bug, and he talked to several people on how to do it properly.

The best way the bug could have been avoided was if the OpenSSL upstream developers had cared more about the valgrind issue themselves. (E.g. by teaching valgrind to ignore the issue, documenting in the source code why this is intentional and not an issue, ...)

P.S. in the previous version of this blog post I had asked why OpenSSL apparently relies on uninitialized data for security. It doesn't; the same lines exist in two places, and it's the other change that caused the problems. One place will 'usually' generate the warning, and it's not important (that's the place where you could just remove the line). The other place will generate the same warning when someone passes uninitialized data into the RNG. As long as the RNG is sufficiently seeded with other random data that isn't much of a problem. So if you take a buffer of 1024 bytes and fill it with 1000 bytes of good random data (e.g. from a hardware randomness source) and feed the whole buffer to the RNG, it will be seeded quite well, but the warning will be generated. The 24 uninitizialized bytes won't take the entropy away.

(This blog does intentionally not have a comment function. Sorry.)

02:16am

Matthew Garrett

As noted in the comments here, one reason to forcibly slow down the CPU on a system (and waste power in the long run) is to deal with cases where failing to do so can result in the machine overheating. Part of the problem is that Linux still tends to be less power efficient than Windows, and so various components will be generating more heat than when the machine was tested. The ACPI spec includes support for passive cooling of processors, which allows the system to reduce heat generation by slowing the CPU down. The problem is that not all vendors include a passive trip point in their firmware, and in the absence of one Linux will happily let the temperature rise until it hits a critical level and the machine shuts down.

I've written a patch that generates a passive cooling trip point if your firmware doesn't provide one. Since there won't be a firmware event when the temperature crosses the trip point, it also forcibly enables polling (the spec actually requires this, so I've no idea why Linux doesn't do it anyway). The default polling interval is quite long - you can adjust it in /proc/acpi/thermal_zone/*/polling by just echoing in a value in seconds. I've gone for a long delay in order to reduce any possible power consumption issues caused by this, but in the long run I'd like it to reduce the polling interval if the temperature trend is upwards and increase it again if the trend is downwards.

The patch makes the assumption that you're never going to get within 5 degrees of the critical temperature in normal use, which I think is pretty reasonable. The probability that the machine will reach equilibrium at that point is fairly small, so if you get that close you'll almost certainly end up with a powered down machine unless we do something about it (like forcibly downclocking your CPU). I don't have any affected machines, so I've only been able to test it by artificially lowering the trip point - if people find that it still lets the processor get over temperature without attempting to slow it down first, then I'll probably need to implement the more advanced polling policy.

In any case, I'm interested in feedback.

01:27am (Comments)

Daniel Leidert

[DSA 1571-1] New openssl packages fix predictable random number generator

Ok, shit sometimes also happens to Debian users.

Now I read a lot of FUD, flames, arrogant claims and much more bad things, including blaming of downstream in general.

Well, Debian maintainers are NOT upstream authors. Maintainers often care about a lot more than just 1 package. Now I wonder if one can really expect, that maintainers know the source code of their packages as good as upstream authors do? Is this, what the user or the Debian project expects from a package maintainer? I agree, that this would be the ideal situation. But how realistic is it, if one maintains 10, 20 or more packages?

Normally users report us issues. We take a look at the source, try to catch the issue, track it down and fix it. And IMHO in almost all cases this is enough and it lets us handle several packages. And maybe this is also, what happened here. The maintainer got a report, tracked it down and tried to fix it. It seems, he posted it to the openssl-dev list, which is to my reading considered for such questions, and got a positive response. And with fixing it, he made a horrible mistake. But apparently it also seems, that the question had been discussed earlier more than just once (I wish, the OpenSSL guys would have created the FAQ entry earlier).

I don’t want to blame the maintainer for doing this mistake. We are humans. But do we need another instance, that (periodically) checks (probably only Debian-specific) patches/changes to security relevent software or do we need different requirements for maintainers of such software [1] or should we simply archive this under “Shit sometimes happens … even to Debian users”?

[1] Consider gnupg which is currently almost unmaintained. It also has Debian specific patches applied and I wonder, which skills the new maintainer should or must(?) have (IIRC this question was raised in the linked threads too)?

12:19am by Daniel Leidert (Comments)

May 13, 2008

Craig Sanders

Howard’s Child Protection Babies

See this article, Baby boom link to rise in child-welfare cases at The Age web site.

What a great legacy for John Howard - his “baby bonus”, a grubby and cynical vote-buying exercise for the 2004 Federal Election has resulted in a mini- baby-boom.

It has also resulted in a more than 66% increase in interventions by the Child Protection Agency (from 600 in 2000-2001 to over 1000 last financial year). And that’s just from the first few batches of baby-bonus babies.

Perhaps the people who think a $3000 “bonus” (as introduced in 2004, now increased to $5000) is a good reason to have a baby are precisely the kind of people who shouldn’t be having babies.

“Cool, $5000 if i have a baby”. or worse, “Cool, $5000 if i make my girlfriend have a baby”. Great reasons to have a baby. Thank you, Mr Howard.

At least we now all know the answer to the question “How many abused and neglected babies is a vote worth”?

Syndicated from Craig Sanders' Errata: Tech Notes and Miscellaneous Thoughts

Howard’s Child Protection Babies

11:08pm by cas (Comments)

Biella Coleman

Massive FUD: twisting science for the sake of profit

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.

10:51pm by Biella (Comments)

Enrico Zini

How to generate bootable USB keys with simple-cdd

How to generate bootable USB keys with simple-cdd

simple-cdd is a lovely piece of software that builds a custom D-I image with the package selection and preseeding of your choice.

Today I was asked to build a bootable USB key with the simple-cdd image. Here is how; the general case is described in the d-i manual:

General USB key preparation:

  1. download vmlinuz and initrd.img from hd-media
  2. apt-get install syslinux mtools mbr
  3. Partition the USB key as needed (from now on, I'll assume the usb key is in the device /dev/sdb1)
  4. Format it as FAT: mkdosfs /dev/sdb1
  5. Put the boot loader in it: syslinux /dev/sdb1
  6. Put the MBR in it: install-mbr /dev/sdb
  7. Mount it: mount /dev/sdb1 /mnt
  8. Copy kernel and initrd: cp vmlinuz initrd.img /mnt/

simple-cdd specific part:

  1. Run build-simple-cdd as usual
  2. Copy the ISO file generated by build-simple-cdd in the USB key. Any name will do, as long as it ends in .iso the installer will find it
  3. Configure the boot loader, fetching the kernel command line out of the cdrom boot loader generated by simple-cdd:
    • echo default vmlinuz > /mnt/syslinux.cfg
    • grep append tmp/cd-build/etch/boot1/isolinux/isolinux.cfg | head -1 | sed -e 's/^\t//' -e 's/ initrd=[^ ]*/ initrd=initrd.gz/' >> /mnt/syslinux.cfg

This is it, it works nicely, perfectly scriptable, tested today.

10:40pm

Setting environment variables at X login

Setting environment variables at X login

I've been asked how to set a variable after gdm has done login. ~/.bashrc is not an option, as it's only run by shells, but we want the variable to be set in every X application that is started.

The answer is:

  • ~/.profile for text and graphical sessions
  • ~/.xprofile for graphical sessions only

Forget about ~/.xinitrc. ~/.xsession and ~/.Xsession: at least in gnome-session, they do not work.

Update: * On IRC, I've been told that ~/.xsessionrc should be used since xorg 1:7.3+9

10:22pm

Biella Coleman

What Sorts of People Should There Be?

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.

09:01pm by Biella (Comments)

Lucas Nussbaum

No, we don’t need a new openssl maintainer

DSA-1571 is totally embarrassing. But I disagree with Julien BLACHE: we don’t need a new openssl maintainer. Mistakes sometimes happen to people who do things. That sucks, but it’s unavoidable, no matter how many levels of checking you add. Kurt has done a lot of excellent work on Debian in the past years, and I’m sure he will continue.

Of course, it’s a lot easier and less risky to write tons of stupid blog posts.

By the way, Julien, there’s an RFH bug for openssl open for more than 2 years. What about getting involved and helping Kurt yourself?

On a more constructive side: it’s not the first time that a Debian-specific change broke something (I can think of a recent grep change …). It might be useful to provide a simpler way to review those changes (reading the diff.gz files is not really user-friendly). We could have something like http://patches.ubuntu.com/ (or even something nicer :-).

07:58pm by lucas (Comments)

Kai Hendry

Regenerate your .ssh/id_rsa key Debian users

Whoa, this security bug exposed by Luciano Bello (Ola!) is one of the worst I’ve ever seen.

Time to regenerate your key with the updated openssl 0.9.8c packages.

This seems to be Debian specific patch that caused this bug.

Further instructions should be posted on a special Debian key rollover page.

07:24pm by hendry

Fathi Boudra

a look at KDE 4 and Debian

So far, if you want to use KDE 4 under Debian, you need to install them from experimental. Under the ground, we prepared up-to-date packages from trunk (soon uploaded) and I took a snapshot of my current desktop:

desktop

We didn’t know yet if Lenny will be shipped with KDE 4 but we hope it will be in good shape to have it. Everyday, improvements are done and the desktop is enough stable/solid to be used on a day to day basis.

On other side, I reported a bug on plasma panel alignment isn’t saved and some hours later, Marco Martin (mart) fixed the issue \o/

Tips: if you want to have a transparent panel, you need to enable compositing.

06:14pm by admin (Comments)

Luciano Bello

cryptographic apocalypse

Well, maybe I was a little noisy with my first DSA. I will try to be quieter next time :)

I think that many people are being very unfair with the OpenSSL’s maintainers. They made (and are making) a really good job. Was an accident, that things happens.

What we need is a real auditory process of the Debian specific patches. It’s hard, but it’s necessary.

06:10pm (Comments)

Frank Lichtenheld

Introducing archive.debian.net

Just the other day I was wondering about what release of Debian a specific version of a package was in, and I knew it was older than oldstable. But searching the Packages files of archive.debian.org was tedious and I thought that there has to be better way. So I quickly set up a packages.debian.org instance for archive.debian.org at archive.debian.net

I guess this isn't really interesting for the day-to-day use, but maybe someone can ocassionally profit from it.

Caveats:

  • There are no binary files on archive.d.o for rex and buzz, so currently no information is available about them.
  • There are no Sources files available for rex, buzz and bo, only Packages, so no information about the source packages can be presented.
  • The two above point of course mean together that there is no usable information at all about rex and buzz. If someone would create the missing indices and convince the ftp-masters to put them on archive.debian.org, I will gladly configure archive.debian.net to use them.
  • Changelogs and copyright files are currently only available for pool-using releases, since the extraction script has some assumptions that depend on that. On archive.debian.org, the only release that uses pool/ is woody.

Feel free to help me improve that site, preferably by sending patches against the archive-master branch of git://git.debian.org/git/webwml/packages.git.

04:39pm

Zak B. Elep

OpenSSL Ouch

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

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

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

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

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

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

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

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

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

04:32pm

Julien Blache

Making code valgrind-clean …

NOT.

Also see #363516.

Genius.

Now regenerating every single SSH key, SSL certificate and whatever else I can identify that’s been produced by one of the Valgrind-clean openssl. Also expiring and changing every single password I’ve ever typed in a vulnerable SSH session (be it at login or in the session).

Updating the packages on the machines was fun already.

Worst Debian day ever since the 2003 compromise. And that was a BAD one.

I guess we need a new openssl maintainer, we obviously cannot trust the current one(s).

03:11pm by jblache (Comments)

David Welton

Restaurants, immigrants, and the popularity of various cuisines

A little off-topic exercise conducted in the "eye of the storm", when Ilenia and Helen were still in the hospital:

A post on Seth Robert's blog brings up the idea that many Chinese restaurants were opened as a way to go into business without competing with native male workers. The post made the rounds of several other online journals.

That was the push I needed to get up and go collect a few statistics of my own, regarding an idea I've been kicking around for a while. My theory is that the number of restaurants of a given type, divided by the number of immigrants from that country might be an interesting way of guaging the popularity of the cuisine in question.

In order to simplify things just a bit, I actually used data from Italy, for the following reasons:

  • Most immigration to Italy is pretty recent, so it's not necessary to account for the length of time different immigrant groups have been present, and the effects that may have had on the diffusion of a given cuisine.

  • Immigration statistics were readily available: http://demo.istat.it/str2006/index.html

  • Italian the language almost completely corresponds to Italy the country (outside of a chunk of Switzerland, San Marino, and the Vatican), something that makes things that much easier.

  • I speak Italian, so it was easy to find out all the information I needed

Unfortunately, finding out the number of restaurants of various types is far from an exact measurement, and since this is a quick fun project, I just went for Yahoo search (they deserve credit for keeping their search API open when Google's was closed) results on terms like "Ristorante Turco" (Turkish), "Ristorante Messicano" (Mexican), and so on. This was the most expedient means of gathering information quickly, but this approach does present a number of obvious problems, listed here in the hope that someone without diapers to change and a business to run might come up with some good answers:

  • Some hits likely come from people talking about a restaurant that happens to be in a country, like "ristorante americano". "Nel tipico ristorante americano, ...." or in other words, "In a typical American restaurant", rather than an American-style restaurant in Italy, which is what we were looking for in the first place. This is probably also true of countries close to Italy, where people go on vacation and thus have occasion to write about their experiences in a "ristorante tedesco" (German), rather than going to eat in a German restaurant in Italy. Perhaps the search query could be improved in an attempt to eliminate this sort of false positive.

  • Some restaurants probably are not known as, nor brand themselves with a country name, but instead utilize titles like "Middle Eastern", "Arab", "South American", "African", or others that do not correspond with any one country in particular. It would be possible to group countries together with other adjectives, and get statistics for these clusters as well.

  • Measuring hits is measuring what people are talking about, rather than simply restaurants that exist, so if restaurants from a certain country are more talked about than others, that would muddy the statistics a bit. However, it seems reasonable that people would mostly talk about restaurants in proportion to their popularity, and I don't see a particular reason why there would be more talk of Vietnamese restaurants, say, than Thai restaurants, compared to the actual numbers.

That said, for a quick project, this approach seemed to work out ok, and the results appear credible. Obviously, the results also reflect people discussing certain cuisines, rather than an actual number of restaurants, but since it does reflect interest, we'll use the number in any case.

Since the number of restaurants/interest in a type of restaurant was clearly not correlated directly with the number of immigrants, other factors must come into play. For instance, "ristorante giapponese" turns up 125,000 hits, but the stats say only 6873 Japanese nationals live in Italy. As above, hits don't mean actual restaurants, but clearly Japanese cuisine is not being popularized through immigration.

Here's my guess: these statistics show, to some degree, what people in the host country actually like to eat. Food that tastes good means more restaurants. Things that aren't that popular mean few restaurants, even if there are many immigrants. To pick on one country, there are many Philippino immigrants in Italy, but very few search hits - and anecdotally, I've never seen a Philippino restaurant in Italy either, whereas even smaller towns like Padova have Chinese, Mexican (well, it's called that, even if it's a shadow of the real thing), Japanese, various Arab and middle eastern restaurants, and even a few less common things like Eritrean. And I know that many native and foreign restaurants employ Philippino cooks.

Below is the chart I whipped up showing the number of Yahoo hits per immigrant. The Italian names shouldn't be too hard to figure out. A few tricky ones: Giordano-Jordanian, Giamaicano-Jamaican, Spagnolo-Spanish. If you're interested in numbers or source code, contact me.

Immigrants and Restaurants

02:34pm by David N. Welton

John Goerzen

Imagine 1

Imagine, for a moment, that you are a young man in your 20s, trying to make your way in the world. You are married and have a young daughter, just old enough to start to talk. You live in a run-down neighborhood, long passed-over by any economic advances. What schools you had access to barely taught anyone much. The few jobs you can reach have fierce competition, even though the pay is low. You worry about your health, but even more about that of your wife and child. Finding food is a constant concern. Although you are still healthy now, and you are willing and able to be a hard worker, there is simply nobody hiring people in your area. Not to mention the gunfights that erupt between gangs or drug dealers. Oh, and did I mention that your wife is 4 months pregnant?

Your top priority is to do your best to keep your family safe. You're afraid that your whole family will starve, or be killed by an errant bullet. You've tried for a long time -- it seems like forever -- to do everything you can think of, with no success. Finally, you decide that the only way you can have the hope for a better life is to move somewhere where the economy is better, and the drug dealers are fewer.

But moving hundreds or thousands of miles away is no easy task when you have no money to move. Somehow, with some luck, ingenuity, and tenacity, you have finally managed to find a way. You have no job offer in your new town, but conditions are so bleak at home that you just can't risk staying there. So the three of you move 1500 miles away.

You arrive with no money, no apartment, and don't know anybody. But you're a hard worker, and have talked yourself into a job. It pays what passes for minimum wage in your new home, but it's a fortune compared to what you made before. It's backbreaking work, and you work long hours. But soon you can afford a cramped apartment, and keep your refrigerator stocked with food. What a luxury!

Pretty soon your new baby son is born. You can afford to feed him, your daughter, your wife, and yourself, every day. When you're really lucky, you even have some money left over to send to your brother back home, who is still struggling to make ends meet there. You seem to have climbed the first rung on the American Dream ladder.

Years pass. Your old home becomes a memory; your daily life revolves around new struggles now. Your oldest child is in school, your wife finds part-time work sometimes too, cleaning houses for rich people. You've been laid off several times, your income isn't guaranteed, and the others in your new home don't take kindly to strangers -- and they still think you're one. But it's better than flying bullets and never knowing where your next meal will come from.

Then one day, while you are at work, federal agents show up. You are arrested and taken to jail. Agents show up at home, too, arresting your wife. It turns out that they realized you entered the country illegally from Ecuador those years ago. Meanwhile, your wife wonders what will happen to your son that was playing in a neighbor's yard while she was arrested, or to your daugther that was at school.

After months in jail, with little contact with each other, and poor medical care, the government decides to deport you to Mexico. Why Mexico? Well, it's cheaper, and there's no documentation showing where you came from. Apparently you "look" Mexican, and they don't believe your story.

After months in jail with no income, you are once again bankrupt. A government bus takes you to Mexico and drops you down someplace there, with your wife and your oldest child. Your younger child was born in the United States, and so is an American citizen and can't be deported. But the government isn't going to give him a free ride on a prison bus (and Mexico wouldn't take him anyway, since everyone knows he's American). You have no idea where he is. You have no idea how you're going to find food in Mexico, no idea how to find your son, no idea where to find refuge from the ever more prevalent drug dealers. Meanwhile, the Americans think you're scum because you wanted to protect your family, and it's going to be much more difficult to get back in to try to reunite your family.

This story is based on true events.

It's truly easy to demonize illegal immigrants, isn't it? Easy to round them up by the thousands, easy to build a bigger fence, easy to lock them away.

Sometimes it seems like this nation built on freedom, supposedly on Christian values, has lost sight of compassion for the lowly. In this country, we would throw in jail parents that didn't do everything humanly possible to find food for their children. We also throw in jail parents that grew up in other countries that are just doing the same.

How sad that we have people going on TV, suggesting we round up millions of Americans that happened to come here illegally, breaking up millions of families, creating an immense foster child problem, a human tragedy on a mass scale. How incredible that some of these people on TV wear the title "senator" or "candidate for president". How stupid do they think we are, suggesting that a poor South American family would somehow be able to navigate the arcane American immigration system and wait the 15 years to get here legally, if they manage to come up with all the necessary money somehow?

Politicians have been pushing our buttons for too long. We aren't a nation of selfish hoarders; we came together through tough times, survived the Depression, put in place the Berlin Airlift that saved countless lives in West Berlin. But the thought of someone with darkish skin coming to this country and building highways is enough to send some people looking for a rifle.

I hope that we will someday do better.

11:45am by nospam@example.com (John Goerzen)

Kartik Mistry

[VAC] Till I get Debian machine!


* I have no longer pure Debian machine access available to me for unknown time :( So, obviously, I will not able to update my packages (most packages need no update and migrated into testing already, some are waiting for sponsor to uploads). All are under LowThresholdNmu. Feel free to do NMU without asking me, if RC/RG bug appears :) I will have IRC/Mail etc access though.

Enjoy Madi!

Meanwhile, I am enjoying beer, movies, learning Python and finishing readinglong pending books.

11:34am by Kartik Mistry

John Goerzen

Jacob Update

It's been awhile since I wrote about Jacob, who is 1.5 years old now.

He loves to give hugs lately. He'll walk up to one of us, wrap his arms around our legs, and go "Awww." Jacob's hugs always have sound effects, and it's always "Awww". He also hugs his stuffed animals, other people, or even a book with a picture of a dog on it.

He also has really gotten into saying "hi" and "bye". He likes to wave goodbye to me when I leave in the morning, and sometimes gets a big smile and says "bye" along with it. Yesterday he was picking dandelions from our lawn, and carrying them around. Finally he dropped them on the ground, and said "bye" and waved goodbye to them.

Jacob also really wishes he could jump by himself. He likes it when I hold him and jump. He tries to jump, but just can't quite get the hang of it yet.

10:32am by nospam@example.com (John Goerzen)

Russell Coker