/dev/otmar

Newspapers often enough publish graphs which give wrong impressions on what the numbers behind the diagram actually mean. The usual culprit is a y-axis which does not start with 0, thus visually inflating any trend/changes in the data.

This week I stumbled upon something else:

The article was all about “Do we have to expect more extreme weather in the future thanks to global warming?”. The expert they interviewed kind of rejected the premise that we can deduce anything from one year’s weather. But they wanted to have a scary graph in the article, so they came up with this one.

So what’s wrong? If you compare the temperature and precipitation graphs of one year with the long-term averages, then it’s almost a given that the current year will look more extreme than the averages.

The comparison might make sense if you argue that 2009 is colder/warmer/wetter/dryer than the average year, but for comparing weather variance, this is completely worthless.

This might be of broader interest to users or RT:

I recently hacked up a small Scrip that tries to merge new tickets generated by mail bounces into the original ticket.

This is similar to what RtBounceHandler is doing, just that it’s implemented as a scrip and not as an external program which runs on incoming mail.

I’ve added my code to the RT wiki.

Um sein Geschäft mit X.509 Zertifikaten anzukurbeln, schreibt er eine Pressemeldung, die auch prompt von der Fuzo übernommen wird.

Es scheint um X.509 Zertifikate für SMTP/STARTTLS zu gehen, also die Verschlüsselung des Transportweges beim Mailversand.

Was ist da dran alles falsch?

(more…)

The idea for this one was to build a spiral and then use the bridges to connect the ends together.

I’m usually a quite peaceful guy, but whenever I need to interact with an A-trust product or their website, I get this urge to kick someone.

Hard.

In this case I wanted to send an encrypted mail to an user of the Austrian Citizen Card. For that, I need the X.509 cert for that person.

The first obstacle was the non-graceful degradation of the a-trust website if you have disabled javascript (or, in my case, use NoScript in Firefox). Okay, once I cleared that hurdle, I got a list of 6 or 8 keys for my recipient. The list doesn’t show which keys are ECC and which are RSA, and trying to download them gave me:

for single certs and

for chains.

Good work, folks.

Sometimes, I just make simple ones like this:

The company laptop (Windows XP) of my wife came with the Broadcom software for controlling the Wifi settings.

I’ve already had so many troubles getting that box to talk WPA to my local WLAN at home (an OpenWrt Kamikaze running on an Alix box) that I switched back to WEP.

Last week I tried to get the Broadcom junk to talk WPA to the Linksys ADSL/WLAN CPE at my mother’s place. No go. Just once, for a few seconds it managed to get the TKIP key. Most of the time it failed to negotiate an AES key. Whatever.

I’m so glad I convinced her tech department to give us local admin rights. That way I finally just nuked that dysfunctional piece of sh*** and went back to the default Windows WLAN configuration tool.

That just worked.

Instantly. No hassle at all.

Today, slashdot features yet another article concerning the non-security of SSN as an authenticator. A good number of comments already discussed the stupidity of basing security on the secrecy of the SSN.

Actually, I think there is just one simple solution to keep companies from relying on the SSN as a way to authenticate people:

Publish them all.

In reality, everybody who actually uses SSNs to authenticate people needs to have access to the DB of SSNs. Anybody who handles forms which contained SSN learns them. It’s a shared secret. And it’s used so widely that the circle of people who know them is so large that the secrecy is impossible to maintain.

They may be a secret, but they are a pretty open secret. That’s not security, that’s just a marginally plausible veneer of security.

In order to get something secure in place, you need to convince people that the current scheme is broken beyond repair. So just publish them. All 300 million of them. Get over it.

At work, we installed swatch to have a look at our combined logfiles. (see techrepublic or linsec for a swatch intro.)

But contrary to most of the examples, we’re using swatch not to check for known events, but to look out for unexpected entries. So basically our config is “ignore the known, send mail for the rest”:

ignore=/…/
ignore=/…/

watchfor=/./
mail=…..

This has one severe drawback: every single unexpected line in a logfile will send one mail. This just doesn’t scale.

The threshold feature won’t really help us, as it rejects notifications over its limit, whereas for email notifications it’s better to collect more messages into a single email.

So I dived into the code and added a ratelimit feature for the mail Action.

Apply the patch in Actions.pm.diff and then you can write:

watchfor=/./
mail=addresses=joe\@example.com,subject=”swatch alert”,ratelimit=600,ratetag=foo

and joe will get no more than one mail per 10 mins, without missing a single message.

As written, this config has one problem: I need to flush the messages I held back once I’m allowed to send mail again. In theory, I should have added some sort of timer-based event-handling to swatch, but I considered that to be overkill. Especially if you have multiple mail statements with different rate-limits. So I added another option to the mail Action that tells it just to flush spooled messages and do nothing more. You should trigger that option frequently, e.g. with a stanza like this at the top of your config-file:

watchfor=/./
mail=addresses=joe\@example.com,subject=”swatch alert”,ratelimit=600,ratetag=foo,rateflush=1
continue

ignore=/ /
ignore=/…/

watchfor=/./
mail=addresses=joe\@example.com,subject=”swatch alert”,ratelimit=600,ratetag=foo