Some films

Encounters At The End Of The World. A charming ramble around Antarctica. Does include the odd penguin despite the early disclaimer. Recommended.

How To Lose Friends And Alienate People: Simon Pegg goes across the Atlantic in an adaptation of Toby Young's book. Funny and merciless.

A Quantum Of Solace: I quite like Daniel Craig's Bond, but I think this film was let down by a weak plot (by Bond standards, granting that Bold films at their best are not the most sophisticated things on celluloid) and a rather wet villain.

xXx 2: The Next Level: a poor sequel to a mindlessly entertaining action film. Don't bother.

Shrek The Third. Not quite as strong as its predecessors but should still be worth watching if you liked them.

Madagascar. OK at what it does but nothing special. Funny penguins.

One Flew Over The Cuckoo's Nest. Well done, Jack Nicholson sensibly cast as Jack Nicholson, intensely depressing.

The Last King Of Scotland. That Idi Amin was a real piece of work.

Looks familiar?

Freecycle

1. It's very high volume. Fortunately I was warned of this in advance and set up filtering arrangements pre-emptively.

2. You have to mess around with Yahoo's web interface just to subscribe. I know there's a lot of poor mailing list interfaces out there but you can certainly do better than this.

3. The (global) member FAQ suggests combining multiple items into one email (s11). Based on my experience I don't believe this is good advice.

Firstly, some of the responses are at best vague on which items they wanted. In practice this meant I favoured the people making more specific requests and wasn't in the end left with excessive vagueness to guess at, but still, life would have been rather easier without that step.

(When one is giving away useful things for free I don't think it's unreasonable to expect the requester to make some effort to be specific!)

Secondly I'm not convinced that it achieves the intended effect of saving the readers' time. It's stated as cutting down the number of emails but of course message count is only a proxy for the real scarce resource here: human lifetime. Certainly a worthwhile goal, given there's thousands of readers, but only good advice if it actually succeeds.

If all the items offered (among a group of messages) are in the subject lines then you can read them straight off the list of subject lines and carry out bulk deletion: I can read N lines and perform a single UI action to delete them all.

But for each messages where the subject line says "various items" you have to specifically select that message and read the individual line items. That's an extra UI action to select the message, and a pair of visual shifts (from subjects to body and back) for each such message.

So if there are N items and and M "various item" messages, you've got N+M+1 UI actions (including the bulk delete at the end) and 2M visual shifts to process the lot. N's a given, so to minimize reader time and and effort spent all you can do is minimize M.

My immediate personal experience, theorizing aside, was that I quickly started ignoring 'OFFERED: various items' rather than digging into the details of what they were. That doesn't help anyone.

4. You can give away things I thought were unshiftable - my old monitors went out the door last night.

5. It really helps if you get your own address right.

Online billing done badly

0. You get an email from Virgin Media saying your statement's ready.

1. You click on the URL in the email.

2. It wants to know what your provider was called before it was called Virgin Media. You pick one of 'NTL', 'Telewest' or 'virgin.net'. In fact when I started this account it was already called 'Virgin Media'.

I happen to know that this used to be an NTL area, so I click on that and it seems to work, but if you weren't a dedicated follower of pointless branding churn among phone companies you might well not know this.

3. Click on the 'sign in' button. It takes AGES to load the next page.

4. I'm an existing user, so I click on the 'sign in' button. It takes AGES to load the next page and eventually times out.

4a) Hit reload. It works immediately this time.

(Yes, my internet connection is working fine, as loading other sites while waiting quickly demonstrated. It's Virgin Media that is broken here.)

5. Enter email address and PIN and click 'sign in'. This one's quick quick.

6. Click 'show me this bill'. Again quite slow although not as bad as steps 3 and 4.

There's no reason for steps 2, 3 and 4 to exist: the computer sending the email knows who you are (has to, so it can find your email address). So the link in the email could take you straight to step 5 and prefill your email address. Instead users are required to include three totally pointless steps.

Since the PIN's only 4 digits anyway you might as well include that in the URL in the email too actually and eliminate step 5 too. 10000 combinations isn't enough to deter a mildly dedicated attacker from breaking in and, er, maliciously paying your phone bill.

(Maybe it itemizes the longer phone calls, in which case the security of this system is of more interest. Personally my main uses of VM are TCP/IP and television.)

E.ON (a power company) do a bit better. But really any of plain text, HTML or PDF in an email would have been much better (PGP'd if they're worried about confidentiality).

Regarding DSA 1571

I wrote this a while ago but never got round to posting it. The dust has since settled but it might be interesting to some nonetheless.

1) I try to use valgrind on something that involved OpenSSL. I can't even remember what. The exercise is significantly hampered by numerous false positives.

2) I identify OpenSSL's practice of passing uninitialized data to its RNG as part of the problem. This happens in two places.

(i) When RAND_poll (in crypto/rand/rand_unix.c) collects entropy from /dev/urandom (or an EGD) , it reads data into a buffer called tmp_buf. It might not fill this buffer, but it nonetheless passes the whole buffer into the RNG. The balance of the buffer is uninitialized and valgrind warnings result.

I spotted this one, and my fix was to zero out the buffer before filling it. This may not be entirely obvious from the patch in the bug report but if you read it in context then it is plainly harmless.

(ii)When you ask for a random number, ssleay_rand_bytes adds the output buffer you're going to use for the answer into its calculation of new random data. I didn't spot this one. This is where the PURIFY ifdef can be found.

My fix for (i) was perfectly safe. Also, it does not cost you anything: if you were analyzing the security of OpenSSL you would have to ignore any contribution to entropy from the uninitialized part of the buffer; its uninitialized state means the compiler and language standard don't make any promises, it does not mean its unpredictable on a given implementation. (Early in a program it is relatively likely to be all 0s for instance). So this change would not have removed any security guarantee worth the name.

Since I apparently didn't spot (ii) I didn't make any changes there, though if I had that would have been safe too for the same reason.

3) I send my patch for (i) to Debian. I am after all using a Debian system.

4) Debian's OpenSSL maintainer spots (ii) as well but misunderstands (i), apparently concluding that the problem is not RAND_poll passing (partially) uninitialized data but in ssleay_rand_add reading that data at all. In other words, they've assigned the blame for the valgrind warning to the code that performs the read, rather than the code that fails to do a write.

5) Kurt then mails openssl-dev about it, and gets a positive reaction a member of the development team. openssl-dev is the address the README told you to use:

Development is coordinated on the openssl-dev mailing list (see
http://www.openssl.org for information on subscribing). If you
would like to submit a patch, send it to openssl-dev@openssl.org with
the string "[PATCH]" in the subject. Please be sure to include a
textual explanation of what your patch does.

6) Kurt makes his proposed changes and uploads the new package.

Henceforth anyone who installs this tainted OpenSSL suffers two problems. Firstly there is no longer adequate diversity of keys generated with it. Secondly if they make any DSA signatures, they risk exposing the value of the private key.

(You might want to rethink how much you rely on DSA in the light of this; requiring a source of cryptographic-strength random numbers for key generation is fair enough but additionally requiring it for every signature if you don't want to expose your private key seems a little on the risky side!)

7) Luciano Bello spots the problem. The bug gets fixed and a DSA is issued. There's a great deal of informed and uninformed comment online. A number of people blame me, assuming that the only patch that appears in the bug report is the faulty one, and not bothering to check either what it does or what the actual change was. Obviously this does not make me happy.

(There's a lot of great work done by various people to clean up the mess, too.)

8) Ben Laurie complains that vendors are bad for security.

There's some truth in there: people should indeed not try to change code they don't understand, and coordinating with the people who maintain it is an obvious way to avoid pitfalls. However, Kurt did mail the advertized address, and did get a response from a member of the OpenSSL development team, so even though he screwed up, this safety net failed dismally too.

---

Some people have criticized the original motivation for any change as putting debugging ahead of security. Not only is this not true - the original change had no impact on security - but it is completely wrong-headed: in general software that is harder to debug is software that is harder to secure, and in particular the kind of bugs valgrind is good at spotting are just the kind that may turn out to be security holes.

Lots of yellow

I got my 135mm lens back, now with working autofocus, so I had to take lots of pictures with it. Total cost was £154, of which £10 was paid up front to get a quote. The whole process took about a month and a half; I just took it to Campkins and they sent it Canon. I like this approach because I didn't have to mess around with packaging, couriers etc, and would use Campkins again for it as they gave a good explanation when it turned out to be taking longer than expected; gave an accurate estimate of when it would finally be back; and called back when they said they would.

( More )