Mental Models: Mattering. (Still.)

07/23/2013

Friend and colleague @bear recently wrote up a post1 discussing “magic tricks” developers have started using to store their deploy secrets in git.

Apparently it involves putting data directly into git using “the plumbing,” and encrypting it somehow? The post doesn’t reference specific techniques; if readers have pointers to those, I’d love to read them.

Bear has some thoughts on why this is an idea that will work out poorly for you, and I totally agree with them; you should go take a gander at his thoughts.

I will just add a couple of other thoughts:

  • This is a perfect example of people solving problems that were solely created by a new tool, i.e. git. In other words, securely storing secret data (whether it be deploy keys or software signing keys, or what have you) has been a solved problem with tools like Subversion, Perforce, and even CVS for decades.

    A lot of people might come back with “Yah, but those systems suck and git is so much better.” And that’s a conversation we could have, but it’s ancillary to my point, which is: Git has no solution for this problem, and their developers don’t seem interested in solving this class of problem2,3, because it’s not a class of problem the Linux Kernel maintainers have. So they don’t care about solving it in a way that takes into account the body of configuration management engineering knowledge that exists on that particular topic, leaving everyone to reimplement it4 themselves.

    I am often harangued as a “git hater” but I will admit: this is one thing that I am unimpressed by git: its (developers’?) answers for so many classes of totally-valid SCM problems is “Don’t do that (because our tool doesn’t support it).”

    (It’s worth noting that a lot of the Subversion SCM patterns were based upon what The Subversion Book ™ told you to do; it often recommended you “don’t do that,” but the tool itself still supported the work flow if you did want to do that; I haven’t quite figured out why those who are head over heels for git give it a pass on this particular issue, but will not give any other tool in the history of ever the same “courtesy.”)

  • Bear mentions the following as a reason to not “do magic” with your deploy secrets/app signing assets, but it’s worth reiterating because I think it’s so important: throwing important “secret” data in with the rest of the code, and managing it the same way breaks the mental model those utilizing that data should have about how it’s managed, stored, and used. As bear puts it: “Usage of secret data should have a separate method of retrieval that makes you think about the fact that you are pulling secret data.”

    In other words, this is yet another case where the “mental model” matters, in a very critical way.

    If you want to scale code, teams, and organizations and do so safely, you must care about the “fuzzy” human factors “stuff”; if you don’t, it will bite you.

    It’s not a matter of “if”; it’s a matter of “when.” And it’s interesting the contortions that people who don’t believe human factors matter will go through to ascribe a failure to something else.

The moral of the story: ignore mental models and human factors at your own peril… and “neat-o magic” is probably not the most sustainable way to treat/handle critical business or intellectual property assets.

__________    
  1. Which, I hate to admit, I’d had sitting in a tab for a couple of weeks, before having had time to read it!
  2. Assuming you buy that it’s even solvable at all
  3. Git would really have to solve the (centralized) identity problem first, I think…
  4. Usually poorly