Heartbleed Reaction Part 2

A particularly relavent statement from http://heartbleed.org (server side):

"Fortunately many large consumer sites are saved by their conservative choice of SSL/TLS termination equipment and software. Ironically smaller and more progressive services or those who have upgraded to latest and best encryption will be affected most."

There doesn't appear to be any up-to-the-minute current registry that I could find of sites that are affected on the server.  The scan posted on github is fairly out of date at this point, and from what I can tell only takes the homepage into consideration, not sites that only forward to https for things like login / checkout.

Here is the best one-off checker I could find (server side):
- https://www.ssllabs.com/ssltest/

Also, it may not be necessary to update Chrome/Firefox, based on the following language on the security stackexchange site:
- http://security.stackexchange.com/questions/55119/does-the-heartbleed-vulnerability-affect-clients-as-severely

"Chrome (all platforms except Android): Probably unaffected (uses NSS)"
"Chrome on Android: 4.1.1 may be affected (uses OpenSSL). Source. 4.1.2 should be unaffected, as it is compiled with heartbeats disabled."
"Mozilla products (e.g. Firefox, Thunderbird, SeaMonkey, Fennec): Probably unaffected, all use NSS"

The potential vulnerability of clients is discussed here:
- http://security.stackexchange.com/questions/55119/does-the-heartbleed-vulnerability-affect-clients-as-severely
- https://www.openssl.org/news/secadv_20140407.txt (language: "client or server")
- http://heartbleed.com

"Furthermore you might have client side software on your computer that could expose the data from your computer if you connect to compromised services."

My guess is that curl going to an https site would be affected, or other programs that use OpenSSL.  Maybe a chat client or if programs are downloading their own "auto-updates" over SSL.  Those are the only kinds of things that come to mind right now.

Reacting to Heartbleed

It's 2:37am and I can't sleep.  It feels like the internet fell down around my ears.

What I am doing:

1. Got educated at http://heartbleed.com
2. Updated Chrome to the 34.x version manually (promoted to stable yesterday)
• look at https://support.google.com/chrome/answer/95414 and search for "Check for update manually"
3. Checked for vulnerability in sites I use
• dnsimple.com (patched as of 8 Apr 14:22 GMT)
• github.com (patched and sessions invalidated somewhere between 8 Apr 18:34 GMT and 9 Apr 01:08 GMT, based on atom feed post timestamps)
• familysearch.org (not vulnerable as of 8 Apr around 16:00 GMT)
• amazon.com (not vulnerable as of 8 Apr around 16:00 GMT)
4. Completely clearing cookies and cache on ALL my computers, family & work, including phones
5. Installing LastPass and resetting ALL my passwords as I become confident that each site is patched
• I am assuming that all my user/passwords are either already known at this point, or can be discovered by anyone who recorded SSL traffic in the past 2 years
6. Wondering what will happen because of this

UPDATE: Chrome update seems to be not strictly necessary as stated here.  But I'm upgrading anyway, because the Chrome stable release on 8 Apr. 2014 has a lot of other security fixes in it.

UPDATE: More details that I've learned are here in a follow-up post.

Google Fiber in Provo, UT

This makes me want to move to Provo:

https://fiber.google.com/cities/provo/

That's something my wife thought she'd never hear! :)

Dystopia - Fallacies Conquered

Dystopia - from NetflixOSS's Adrian Cockcroft:

We have spent years striving to build perfect apps running on perfect kernels on perfect CPUs connected by perfect networks, but this utopia hasn't really arrived.

Instead we live in a dystopian world of buggy apps changing several times a day running on JVMs running on an old version of Linux running on Xen running on something I can't see, that only exists for a few hours, connected by a network of unknown topology and operated by many layers of automation.

Reminds me of Fallacies of Distributed Computing, but from the perspective of people who have actually vanquished the beast with weapons that are usable by others.

Unicode Support Better Now in Ruby

Unicode support in Ruby has historically been one of Ruby's major problems for me.

With the advent of Ruby 1.9 of course, Unicode support started being added to the language.  However, it's not as straightforward as Java, which supported some version of Unicode from the beginning.

Even though it's been a rough decade, things are finally looking up.  In fact, I actually like the way things got factored after all of the mess.

The thing I like is that the minimal amount of support is included in the standard library, and it's easy to compose things in non-standard ways for weird scenarios or data in improperly encoded formats.

The core library has support for strings of codepoints and bytes and a flexible set of encoding facilities.

In addition, there are two libraries of interest:

• unicode_utils - includes implementations of word-break functionality, grapheme boundaries, etc.
• jcode (if you're stuck on ruby 1.8.x)

This series of posts gives you a full understanding of the topic.  Highly recommended!

This post gives a high-level view of where things were at around 2006, much of which is valuable background.

This post has a good summary of unicode-related resources, as does this stackoverflow question.

Semantic Versioning

After having skimmed the semantic versioning proposal/spec, I really like it, and I'm going back for a deep read.

The most notable violator of this that has bit me in the past has been the jersey framework, and maybe earlier versions of commons-collections.

srev-taming: Migrating Subversion to Git

After reading about Mediawiki's pending svn => git migration, it sounded very familiar to me, because I was proposing such a conversion at work about a year ago.

Mass svn => git migration tooling doesn't really exist in the way I wish.

The most popular tool is probably svn2git.  But even with all the conversion goodies baked into it, it's still based on git-svn.

Anything based on git-svn means that for an svn repo that has multiple projects in it, you have to take N passes over the repository, which is a huge hit for repos in the 20,000+ commit range.

The most performant conversion tool is svn-fe, but it doesn't do much more than just import at the repo boundary: 1 svn repo => 1 git repo.  And it doesn't even begin to deal with the situation of multiple svn histories as we have migrated from one repo to another.

The closest thing that exists is a set of scripts posted as part of this thread.

Here is a rough cut of a project I wish existed:

"srev-taming" ~~ "svn-migrate"
(anagram, in the spirit of "snerp-vortex" ~~ "svn-exporter")

• scan of SVN dump for projects & codelines => annotated projects & branches list
• easy invocation of svn-fe for mass-import => generate me a command-line
• editable auto-detected project tags & codelines => language that easily expresses projects, codelines & grafts
• easy clone/filter-branch invocation to extract & stitch codelines together (based on projects & branches list and configured grafts)
• post-import filter for author fixup, SVN & migration artifact removal => generation of starting author list & svn URL minifier

Unless I get explicitly assigned to do the migration, I guess it's not going to prioritize high enough for me to do anything about it.  At least svn-fe is being maintained and enhanced.

But I'm posting it here to see if anything exists that I don't know about -- or in case it sparks some ideas for someone to create this thing.

Flesh pots & Resistance to change

I was reading the account of Moses leading the Isrealites out of Egypt. After all of the miracles that accompanied the exodus comes the account of the net sum response of the Isrealites (Exodus 16:2-3):

2 And the whole congregation of the children of Israel murmered against Moses and Aaron in the wilderness:

3 And the children of Israel said unto them, Would to God we had died by the hand of the Lord in the land of Egypt, when we sat by the flesh pots, and when we did eat bread to the full; for ye have brought us forth into this wilderness, to kill this whole assembly with hunger.

I'm sure that my response to inspired leadership has sometimes sounded like this. And I'm very much willing to both admit that and abandon that position.

In stark contrast, is the message contained in Pres. Henry B. Eyring's conference talk, Trust in God, Then Go and Do. In particular, another scripture comes to mind (1 Nephi 3:7):

7 And it came to pass that I, Nephi, said unto my father: I will go and do the things which the Lord hath commanded, for I know that the Lord giveth no commandments unto the children of men, save he shall prepare a way for them that they may accomplish the thing which he commandeth them.

Willingness to move forward and change and follow inspired leadership is a quality that I value, and that I seek to emulate & encourage.

Published with Blogger-droid v1.6.7

Developing Organization Change Skill

When I was trying to describe what it takes to do a good rollout of something new across a larger software development organization, I came up with a chant that made a lot of sense:

Here's the old

Here's the new

Here's the difference

Here's what you can do

Yesterday, I was faced with frustration that came from feeling incapable of doing the rollout tasks that were my lot. And I wanted other people to be capable of rolling new stuff across the development organization, too.

I asked myself:

How am I going to get other people to be capable of rolling new stuff out?

That is when the idea came.

So I think that a successful rollout formula is:

1. presenting all 4 things in sequence, and
2. making it easy for people who are affected by the rollout to take the next step

Published with Blogger-droid v1.6.5

Refreshing Take on OS Upgrade

I'm typically a laggard when it comes to upgrading my OS. I like for things to be stable -- I don't like to waste time fiddling with things unrelated to what I've got to get done for whatever project I'm working on.

So now in July, I'm upgrading to Ubuntu 9.04 (released in April). To state how much of a laggard I usually am, I think this is the most up-to-date I've ever been on an OS upgrade.

I decided to use the standard "upgrade to 9.04" feature exposed in "Update Manager". So when I saw a screen like this:


then I felt happy. I felt like I knew what was going to happen, and that I was in control of the process to some degree. This freed my mind up and let me think about what I could do to minimize any upgrade risk.

In the past, because of the helpless feeling of being out of control of what's going to happen and what I can expect, I've avoided upgrading until the pain became great enough to justify a full backup/reorg of all my files that I for sure wanted to keep.