On the last day of AsiaBSDCon, George Neville-Neil gave the keynote talk, Security Fantasies and Realities. Some of it was good and some of it was bad. One of the central points is that the ioshitsunami is coming and in order to save humanity we need to do more of the good security and less of the bad security. One of the, or perhaps just the, good security things to do is hardware root of trust, which I will call TPM, although it has a few brand names.

more...

My phone decided it didn’t like my face and wouldn’t let me log in. Unusually, instead of giving me some retries, it immediately locked me out, requiring a passcode. At first I thought this might be a security measure, but I’m pretty sure it was just a glitch. However, it’s an interesting possibility for an authorization system. Fast lockout after a near match.

more...

Some thoughts on cowboys vs conservatorships after reading De-facto closed source: the case for understandable software. I can’t say I disagree with anything there. Software is too complicated and should be simpler. There is, however, an angle which wasn’t examined. Or at least an alternative that wasn’t fully explored, which is to trust authors in a way which works.

The original problem (or one of them) is the result of a fiercely independent code slinging cowboy distribution model. You write some code, toss it on the tubes, people use it, and then... you move on and hand your star over to somebody else. The de jure maintainer has changed. There’s no continuity.

Another model is to place the code in a conservatorship. Like a curated list of awesome, except actually curated. When the original author steps away, nothing changes. The de jure maintainer is the same. Continuity.

There are many examples of such conservatorships, although we rarely use the term. We might consider the OpenBSD project. Some time ago, Sylvestre wrote and contributed a fuse implementation. Then life moves on, as it does, and so did he, leaving the code without a direct maintainer. But OpenBSD didn’t just hand the code over to somebody else. It’s still ours, even if we could be doing a better job improving it. To be completely honest, although it gets the occasional commit, it may be close to de facto unmaintained. The important fact, however, is that it’s de jure maintained. Users of the fuse code can trust that it won’t get randocoined.

This isn’t an all or nothing proposition. Handing over maintenance doesn’t require assigning copyright. The code is still open, it can be forked out of the conservatorship at any time. And in exchange, there are other people to help fix bugs and answer questions when you go on vacation. You’re not trapped working on a project you’ve lost interest in out of a sense of duty because there’s a succession plan.

See also: Towards a more collaborative OSS model.

When comparing two things, it’s easy to make a claim relating them. This one is longer. This one is stronger. This one is older. This one is bolder. (This one sounds like Dr. Seuss.)

But are we correct? Do people believe us? Would you believe me if I told you William Shatner is older than John McCain? Maybe that’s just a thing I heard. What happens if you ask me how old they are? If I don’t know, that’s a bad sign. If I know that Shatner was born in 1931 and McCain in 1936, that’s a good sign.

If a claim can be quantified, it should be. It’s very easy to do. If it’s not easy, consider why.

The first thing one can do is to ask how much when reading. Any unquantified comparisons stand out as starting points for fact checking.

The second thing one can do is to ask how much when writing. I try to fact check most claims before clicking the big red send it to the internet button, but it can be difficult to know exactly what needs checking. I don’t need to check the things I’m sure about. Alas, my certainty is also sometimes mistaken.

Which is bigger, Central Park in New York or Golden Gate Park in San Francisco? No spoilers, but I’ve heard both answers stated confidently. However, if I followup by asking how many acres is this park and how many acres is that park, confidence drops precipitously. Somehow these high level derived facts become lodged in our heads long after we’ve forgotten the underlying facts, if we ever knew them. We don’t realize this happens until somebody asks what’s underneath.

Unfortunately these high level facts don’t have a lot of error correction builtin. It’s only a single bit, and if it flops, you’ll never know. A numeric fact is more likely (how much more likely?) to degrade to uncertainty than some other value. A builtin parity check of sorts.

Everybody loves numbers. Include them when you write something. You readers might learn something. You might learn something, too.

Fifty years ago today, Burt Munro rode a motorcycle really really fast. Setting a world record that has stood for fifty years, working by himself on an ancient machine, required quite a bit of dedication. There’s a movie version of the story, The World’s Fastest Indian, which is perhaps a bit simplistic and of course dramatic, though still more or less accurately capturing the idea of perseverance. Real life Munro was apparently quite a bit more difficult than the ever cheerful Hopkins, but I suspect that helped too.

It’s a good reminder of what’s possible for someone who keeps working away at a problem. He didn’t have access to extravagant funding or other resources, but he found his niche and kept at it. Incremental progress over lots of time results in lots of progress. Try to make one thing a little bit better everyday.

A few thoughts after reading Are all BSDs created equally? by Ilja van Sprundel. Theo says OpenBSD is the best, Ilja fact checks.

more...

The time has finally come to switch everything to https. Actually, I’ve been using https for a while, but now it’s time to inflict, er invite, everyone else along for the ride.

more...

How big is the ideal team? How do we organize it?

more...

Moving on, getting in to some good stuff.

more...

I wanted to read, or reread, some books, but couldn’t decide which ones, so figured reading all of them at once would be the best solution. In particular, I’d read Coders at Work about the time it came out, and liked it, then skimmed it again recently. The second time through I still liked it, but I noticed new things. I should reread the whole thing. And what about these other books I’m always certain to install on each Kindle but never quite read? My favorite unread books.

more...