|
|
|
RSS / Twitter |
Daemonic Dispatches
|
Musings from Colin Percival
|
-
Tarsnap: No heartbleed here
By now I assume everyone is aware of the
"Heartbleed" bug in OpenSSL. I wasn't
planning on commenting on this, but considering how many emails I've received
about this I've decided that I need to make a public statement:
Tarsnap is not affected by this
vulnerability.
-
Tarsnap price cut
On Tuesday of last week, Google
cut
prices for their Google Cloud Platform services. Not to be outdone,
less than 24 hours later, Amazon responded by
cutting
prices on several Amazon Web Services offerings, including the
Simple Storage Service where
Tarsnap stores customer data. Now it's my turn: Effective April 1st
(I nearly announced this yesterday, but decided to wait until the April
Fools' jokes were out of the way) I'm cutting
Tarsnap's bandwidth and
monthly storage pricing from $0.30/GB to $0.25/GB.
-
Tarsnap now accepts Bitcoin
A year and a half ago, I
announced that
Tarsnap was gaining support
for credit card payments, as one of the first companies in Canada to
use Stripe's newly internationalized
payment processing services. This satisfied a long-standing request
from Tarsnap customers — until that point, Tarsnap was only
accepting payments via PayPal, a service which for a variety of reasons
many people did not want to use. Today I'm happy to announce that
Tarsnap is satisfying another frequent request, again with help
from Stripe: Tarsnap is the first user of
Stripe's support for Bitcoin
payments.
-
How to build FreeBSD/EC2 images
I have been building
FreeBSD/EC2 images
for the past three years, and based on the email I have been receiving, most
people have been either using these images directly or modifying them to
create images which suit their needs. However, there are some people who
want to build their own images ab initio — most often, companies
which have products built on "customized" versions of FreeBSD — and
while I have helped a few people do this, it's better if my help is not needed.
To this end, earlier today I
published
my code for building FreeBSD AMIs. At its core, this process has two steps:
First, building a disk image; and second, turning it into an AMI.
-
Email delivery headaches
Email delivery used to be easy. Server A connects to Server B over SMTP,
states that it has a message for Bob from Alice, then sends the message
text ("We meet at midnight"). This worked fine until spam came along;
to cope with a deluge of spam, an extra step was added, namely "Server B
decides whether it trusts Server A to provide email from Alice for Bob".
Even then, it wasn't too bad; sure, wide swaths of IPv4 address space
were blacklisted, but if you had a server at a reputable ISP, you would
probably not be on any of those lists. Then cloud computing happened.
-
Dear Google Recruiting...
We dated briefly in 2006. You flew me down to visit you in Mountain View,
and I had a good time. A few weeks later you proposed to me, but I decided
that you weren't really what I was looking for, and I rejected you. I know
it's hard to accept, but I really think it's time you moved on.
-
Thoughts on the Tarsnap logo contest
Coming as I do from the worlds of academia and open source software, it was
only natural that when I decided that my
online backup service needed a logo, I
turned to the "crowd" with a
$500
contest. While I considered using one of the many
logo-design-competition sites, I decided to run the contest myself for a
simple reason: Tarsnap isn't exactly like most commercial products, but it
has an enthusiastic user community who understand the mindset behind it.
Tarsnap is not just "online backups for the truly paranoid";
it's also very much unix software, in the sense of "do one thing well",
"keep it simple (stupid)", and "tools, not policy". Running the contest
myself and announcing it via the tarsnap-users mailing list might
have decreased the number of graphic designers participating, but I'm
sure it increased the number of people who knew something about
Tarsnap. (I did, however, keep one such site in mind as a backup plan
in case I didn't like any of the submitted logos.)
-
Introducing configinit
I have been working on bringing
FreeBSD to the
Amazon EC2 platform since 2006,
and for the past three years I've been blogging about my progress: First
FreeBSD on t1.micro instances,
then cluster compute
instances, then
"m1" and "m2"
family large and xlarge instances, and finally in early 2012,
FreeBSD
could finally run on all EC2 instance types. Once I had a hacked-up
version of FreeBSD which ran smoothly, I turned my attention towards
polishing it: First
moving
my EC2 scripts into the ports tree, then
using binaries from the
release ISOs for the FreeBSD world, and finally in early October
(with FreeBSD 10.0-ALPHA4) all the necessary bits had been merged to
make it possible for me to build EC2 images completely (including the
kernel) with "straight off the ISO" binaries. Next on my agenda was
taking my images from "pure FreeBSD" to "FreeBSD set up to be used in
the cloud", and for that I'm happy to now announce that starting from
10.0-RC1, my FreeBSD
AMIs have a new feature: configinit.
-
Automated FreeBSD panic reporting
It is now very common for software to have built-in mechanisms for
reporting crashes. Windows, OS X, Ubuntu, Android, KDE, Mozilla... there
are few large codebases which don't have any such functionality.
Until a few days ago, FreeBSD was an exception: The instructions on
Kernel
Debugging are hidden away in the "Developer's Handbook", and for users
who are not in a position to diagnose the cause of a kernel panic themselves,
all that could be done is to submit a bug report via the "send-pr" utility
— at which point it would join the other 500+ panic reports sitting in
FreeBSD's mostly-ignored GNATS repository. A couple of weeks ago, I decided
it was time to do something about this.
-
Don't trust me: I might be a spook
Shortly after the Snowden papers started to be published, I was invited to
write an op-ed about PRISM and its implications for privacy and online
security. I initially agreed, but after spending a few hours putting some
thoughts together I changed my mind: I really had nothing useful to say.
Yes, the NSA is spying on us, listening to our phone calls, and reading our
email — but we already knew that, and a few powerpoint slides of
confirmation really doesn't change anything. When the first revelations
about BULLRUN — the fact that the NSA can read a lot of encrypted data
on the internet — appeared, I was similarly unimpressed: If you can
find a weakness in an implementation of a cryptographic system, you
can often bypass the cryptography, and the US government, via defense
contractors, has hundreds of open job postings for exploit writers with Top
Secret clearances. If the NSA can break 2048-bit RSA, it would be a Big
Deal; if they can break OpenSSL, not so much.
But the latest revelations scare me. It's one thing to find and exploit
vulnerabilities in software; there's a lot of software out there which was
written by developers with very little understanding of cryptography or
software security, and it shows. If you care about security, we reasoned,
stick to software written by people who know what they're doing —
indeed, when I talk to users of Tarsnap, my
online backup service,
one of the most common things I hear is "you're good at security, so we know
your code will keep our data safe". That reasoning is now clearly flawed:
We now have evidence that the NSA is deliberately sabotaging online
security — influencing (and weakening) cryptographic standards,
bribing companies to insert "back doors" into their software, and even
sending developers to "accidentally" insert bugs into products. It's not
enough to trust that I know what I'm doing: You have to trust that I'm not
secretly working for the NSA.
|
|
|
|
|