The electrum bitcoin wallet seems to use SSL insecurely. Here are two bug reports I filed about it:
ignores invalid ssl certs with CERT_NONE, allowing MITM
fails to verify
ssl cert hostname for cached certs
(update: Seems I was wrong about this bug)
One full month after I filed these, there's been no activity, so I thought I'd make this a little more widely known. It's too hard to get CVEs assigned, and resgistering a snarky domain name is passe.
I'm not actually using electrum myself currently, as I own no bitcoins. I only noticed these vulnerabilities when idly perusing the code. I have not tried to actually exploit them, and some of the higher levels of the SPV blockchain verification make them difficult to exploit. Or perhaps there are open wifi networks where all electrum connections get intercepted by a rogue server that successfully uses these security holes to pretend to be the entire electrum server network.
I'm not particularly surprised to find code that's supposed to be securing a connection with SSL but actually fails to verify the SSL certificate. That's the common failure mode of SSL libraries.
It is a bit surprising to find such mistakes in a bitcoin wallet though. And, electrum seems to go out of its way to complicate its SSL certificate handling, which directly led to these security holes. Kind of makes me wonder about the security of the rest of it.
Five years ago I built this, and it's worked well, but is old and falling down now.
 |
The replacement is more minimalist and like any second system tries to improve on the design of the first. No wood to rot away, fully adjustable height. It's basically a shower swing, suspended from a tree branch.
 |
Probably will turn out to have its own new problems, as second systems do.
I'm forty years old. I've been developing free software for twenty years.
A decade ago, I wrote a series of posts about my first ten years of free software, looking back over projects I'd developed. These retrospectives seem even more valuable in retrospect; there are things in the old posts that jog my memory, and other details I've forgotten by now.
So, I'm doing it again. Over the next two weeks (with a week off in the middle for summer vacation), I'll be writing one post each day about a free software project I've developed in the past decade.
We begin with Ikiwiki. I started it 10 years ago, and still use it to this day; it's the engine that builds this website, and nearly all my other websites, as well as wikis and websites belonging to tons and tons of other projects, like NetBSD, X.org, Freedesktop.org, FreedomBox and many other users.
Indeed I'm often reading a website and find myself wondering "hey.. is this using Ikiwiki?", and glance at the html and find that yes, it is. So, Ikiwiki is a reasonably successful and widely used peice of software, at least in its niche.
More important to me, it was a static site generator before we knew what those were. It wasn't the first, but it broke plenty of new ground. I'm particularly proud of the way it combines a wiki with blogging support seamlessly, and the incremental updating of the static pages including updating wikilinks and backlinks. Some of these and other features are still pretty unique to Ikiwiki despite the glut of other static site generators available now.
Ikiwiki is written in Perl, which was great for getting lots of other contributions (including many of its 113 plugins), but has also held it back some lately. There are less Perl programmers these days. And over the past decade, concurrency has become very important, but Ikiwiki's implementation is stubbornly single threaded, and multithreading such a Perl program is a losing propoisition. I occasionally threaten to rewrite it in Haskell, but I doubt I will.
Ikiwiki has several developers now, and I'm the least active of them. I stepped back because I can't write Perl very well anymore, and am mostly very happy with how Ikiwiki works, so only pop up now and then when something annoys me.
etckeeper was a sleeper success for me. I created it, wrote one blog post about it, installed it on all my computers, and mostly forgot about it, except when I needed to look something up in the git history of /etc it helpfully maintains. It's a minor project.
Then I started getting patches porting it to many other version control systems, and other linux distributions, and fixing problems, and adding features. Mountains and mountains of patches over time.
And then I started hearing about distributions that install it by default. (Though Debian for some reason never did so I keep having to install it everywhere by hand.)
Writing this blog post, I noticed etckeeper had accumulated enough patches from other people to warrant a new release. That happens pretty regularly.
So it's still a minor project as far as I'm concerned, but quite a few people seem to be finding it useful. So it goes with free software.
myrepos is kind of just an elaborated foreach (@myrepos) loop, but
its configuration and extension in a sort of hybrid between an .ini file
and shell script is quite nice and plenty of other people have found it
useful.
I had to write myrepos when I switched from subversion to git, because git's submodules are too limited to meet my needs, and I needed a tool to check out and update many repositories, not necessarily all using the same version control system.
It was called "mr" originally, but I renamed the package because it's impossible to google for "mr". This is the only software I've ever renamed.
Next: twenty years of free software -- part 4 ikiwiki-hosting
ikiwiki-hosting is a spin-off from ikiwiki. I wrote it to manage many ikiwiki instances for Branchable, and made it free software out of principle.
While Branchable has not reached the point of providing much income, it's still running after 6 years. Ikiwiki-hosting makes it pretty easy to maintain it, and I host all of my websites there.
A couple of other people have also found ikiwiki-hosting useful, which is not only nice, but led to some big improvements to it. Mostly though, releasing the software behind the business as free software caused us to avoid shortcuts and build things well.
I've written retrospectively about pristine-tar before, when I stopped maintaining it. So, I'll quote part of that here:
[...] a little bit about the reason I wrote pristine-tar in the
first place. There were two reasons:
1. I was once in a talk where someone mentioned that Ubuntu had/was
developing something that involved regenerating orig tarballs
from version control.
I asked the obvious question: How could that possibly be done
technically?
The (slightly hung over) presenter did not have a satesfactory
response, so my curiosity was piqued to find a way to do it.
(I later heard that Ubuntu has been using pristine-tar..)
2. Sometimes code can be subversive. It can change people's perspective
on a topic, nudging discourse in a different direction. It can even
point out absurdities in the way things are done. I may or may not
have accomplished the subversive part of my goals with pristine-tar.
Code can also escape its original intention. Many current uses of
pristine-tar fall into that category. So it seems likely that some
people will want it to continue to work even if it's met the two goals
above already.
For me, the best part of building pristine-tar was finding an answer to the question "How could that possibly be done technically?" It was also pretty cool to be able to use every tarball in Debian as the test suite for pristine-tar.
I'm afraid I kind of left Debian in the lurch when I stopped maintaining pristine-tar.
"Debian has probably hundreds, if not thousands of git repositories using pristine-tar. We all rely now on an unmaintained, orphaned, and buggy piece of software." -- Norbert Preining
So I was relieved when it finally got a new maintainer just recently.
Still, I don't expect I'll ever use pristine-tar again. It's the only software I've built in the past ten years that I can say that about.