Years of bingo for elementary schoolteachers talking, but I'd include two lines of explanation for "How do I know if I'm on an affected system?" It is not difficult to imagine situations in corporate environments where the person reading this will not have off-the-cuff knowledge of every OS version deployed in their server fleet. There's presumably a command line that can unambiguously resolve this -- might as well make it copy/pastable.

I'd also probably mention that this affects very few Tarsnap users earlier. First sentence early.

"Although most Tarsnap users are not affected, those who generated keys on machines running an experimental version of FreeBSD must immediately rotate their keys to prevent disclosure of their encrypted files."

Otherwise, this is the model press release for a third-party security issue.

It's actually surprisingly awkward to figure out if a system is affected; the best I can come up with is

    SVNVER=`uname -v | cut -f 4 -d ' ' | cut -c 2-7`
    if [ $SVNVER -ge 273872 ] && [ $SVNVER -lt 278907 ]; then
        echo buggy RNG
    fi

But even that doesn't answer the important question -- what matters is not whether you are on a buggy system but rather whether your keys were generated on a buggy system. And there's no practical way to figure that out programmatically.

I'd also probably mention that this affects very few Tarsnap users earlier. First sentence early.

Fair enough. I'm good at memory dumps, not so good at figuring out which bits are most important.

The FreeBSD bug has already been discussed here, of course (https://news.ycombinator.com/item?id=9063884), but I thought people might be interested in a "case study" of how it affects a particular application.

Awesome! I think it’s very good for the customers to hear it from you directly since there are probably lots of them who happily use Tarsnap, but are not deeply familiar with the source code.