Wandering Thoughts archives

A quick trick: using Go structs to create namespaces

Suppose, not entirely hypothetically, that you have a bunch of expvar statistics variables in your program that you're registering yourself in order to create good names for them in the exposed JSON. Implemented normally, this probably leaves you with a bunch of global variables for various things that your program is tracking. Just like any other jumble of global variables, this is unaesthetic and it would be nice if we could do better.

Well, we can, due to Go's support for unnamed struct types. We can use this to basically create a namespace for a collection of variables:

var events struct {
   connections, messages  expvar.Int
   tlsconns, tlserrors    expvar.Int
}

In our code we can now refer to events.connections and so on, instead of having to have more awkward or more ambiguous names.

We aren't restricted to doing this at the global level, either. You can fence off any set of names inside such a namespacing struct. One example is counters embedded into another structure:

type ipMap struct {
   sync.Mutex
   ips   map[string]int
   stats struct {
       Size, Adds, Lookups, Dels  int
   }
}

For obvious reasons, this works best for variable types that don't need to be initialized; otherwise things get at least a least a little bit awkward with how you have to set up the initialization.

This is probably not to everyone's tastes and I don't know if it's considered good Go practice. My personal view is that I would rather fence off variable names with 'prefix.' than with say 'prefix_', even at the cost of introducing such an artificial unnamed struct, but other people probably differ here. It does feel a bit like a hack even to me, but maybe it's a legitimate one.

(For statistics counters specifically, this can also give you a convenient way of exposing them all.)

Out of curiosity I did a quick scan of the current development Go compiler and standard library and turned up a few things here and there that might be this pattern. There are variations and it's not all that common, so the most I'm going to say based on looking is that this doesn't seem like a completely outrageous and unsupported idea.

Discovering my personal limit on how much I care about security

Sometimes finding out about hardware and software cause you to find out things about yourself too. In my case, discovering and reading up on two-factor authentication tokens that you can use to hold your SSH keys (as I more or less want) led me to discover the limits of how much I care about my personal security.

To be specific, it turns out that I don't care enough to pay for a 2FA token for personal use (cf). It's not that they're particularly expensive (although you may not want a current generation Yubikey), but even that modest expense is enough that my inaction shows that I've passively decided that I don't care that much.

Part of this is certainly that I don't think it would get me that much more security or convenience. In security, I already hold my personal SSH keys encrypted and load them into ssh-agent instead of using them directly in ssh; in convenience, well, I make them accessible in ssh-agent, so as long as I'm actively using one of my primary machines I can ssh to other machines without any challenges being involved. Putting SSH keypairs in a physical token of some sort would make them less accessible to an attacker who could compromise my workstation, but in practice if an attacker compromises my workstation I've already lost.

But that's only part of it, because if I was given a 2FA device I'd certainly go to the effort of setting it up and using it (and I'd be happy if work bought one or more to experiment with). I just don't care enough to spend any of my own money on improving my security. So that's the limit of how much I care about my security right now; free is fine, money is out.

(I'm aware that 2FA tokens can increasingly be used for things like Github and other websites in addition to just SSH logins, but I don't care enough about them either. If anything I care less about Github than I do about SSH logins, because of what I consider my Github account to be about (which is another entry entirely). Possibly I should care more and maybe someday I will, but not at the moment. I'd probably have to write something that people came to value and depend on before that happened.)

Sidebar: My view on 2FA token usage on untrusted machines

One nominal usage case for 2FA tokens is when you want to log in to your account from a machine that you don't trust enough to use a regular password from. My view there is that I don't trust other machines enough to expose a login session to them, because basically anything that I do or see in one is potentially sensitive. If I don't trust your machine not to be keylogging my password, I don't trust it to not be logging my entire SSH session.

(And ditto for things like IMAP access or using a sensitive website, although we have a few websites that I might trust a machine enough to do one time operations on. Fortunately this doesn't come up in the work that I do in specific, because I don't really have to interact with other people's machines to do things like get them on the network.)