Papers We Love San Diego is having their first meeting later this month, which unfortunately I won’t be able to attend. I was somewhat intimidated about reading Computer Science papers because of my lack of formal training, but Martin Kleppmann’s paper is very approachable. I found the paper very interesting and insightful and found that I was familiar with most of the concepts on which the paper is based. I’m looking forward to the next meeting.
A few hops away from a story in Hacker News, I found this whimsical introduction to Zero-Knowledge protocols, which I was ignorant of. If the topic piques your interested, read another introductory article.
Salary negotiation can be uncomfortable. It’s a skill that we usually get to practice only once every few years. In the first part of a series, Haseeb gives out practical advice on how and why to negotiate your salary. I found the part about exploding offers particularly interesting. As it happens, I last year I received an exploding job offer that was good until the end of the day!. I played my cards pretty much as the author suggests: The company never relented. They would not give me any more time. I walked away without any regrets. That particular company’s high pressure tactics, more than anything else, tells me that I would not have been a good fit.
AkitaOnRails write on his perspective on Crystal – a new programming language that aims to be type-checked, compile to native code and have a syntax similar to Ruby. I have played with Crystal myself recently and found the discussion thoughtful and interesting. Lately, it seems that Crystal is gathering some steam, especially since Mike Perham ported Sidekiq and has been tweeting about it.
Erik Dietrich lays down his requirements that companies must meet for him to consider working for them. My list would certainly be different, but that is the point. There is high demand for Software Engineers. It might now hold for other industries, where people don’t have much choice but to take what is offered. Instead of taking the first option that is presented, let’s be more mindful of what we want from an employer.
Notwithstanding the cliché title, this articles shows how easy it is to get security wrong. The tragic part is that the security flaws come from a Certificate Authority, StartCom. As it happens, it’s the CA used for the certificate of this very blog (at the time of writing). I’ll have to re-consider that decision soon. Also clear from the story, is that Let’s Encrypt is putting some pressure on CAs – which functionality StartCom was trying to replicate. Some CAs are even trying to steal their brand.
Unix tools have been around for a long time and haven’t changed much. Joey Hess took it upon himself to evaluate new simple tools that he thought are missing (and rejected some ideas in the process). I downloaded moreutils as soon as I read the descriptions. I am sure they will come in handy very soon. Kudos.
I spend a lot of time on the command line, working with Unix commands. (If you don’t, you can check out my talk Practical Unix for Ruby and Rails). Over the years, I have configured and tweaked my shell to my liking. Most unix configuration is done in “dotfiles”, which are configuration files read by Unix utilities, usually residing in you home directory and named with a . in front, from which their name is derived.
I keep my dotfiles in a github repository. This let’s me track my changes in a familiar way and sync more than one computer. It is especially helpful when setting up a new machine: I check out the repository and link the files. See rcm for a handy utility to manage the linking.
Most dotfiles contain preferences that can be shared publicly to the whole world, like .git, .zshrc, .bash_profile, etc. However, some are sensitive - like .netrc or .ssh - and should NOT be kept in a public repository, even though many people do. Until today, I used to keep those in a safe place separately and copy them manually to new machines.
git-crypt enabled transparent encryption and decryption of files inside a git repository. It leverages git filter mechanisms and gpg, a free implementation of OpenPGP standard, which provides public-private key cryptography. After following the rest of the instructions, you can keep an encrypted version of sensitive files into a public repository, without divulging any secrets AND work seamlessly with those files in your local machine.
The ins and outs of GPG are beyond the scope of this post. On my Mac I use GPGTools, which make setting up a private key very easy. Be sure to understand how to manage your keys: If you loose you private key or don’t know the password, you won’t be able to get any encrypted information back.
git-crypt is available on most package managers. In my case:
$ brew install git-crypt
Configure git repository
Inside the git repository where you want to add the protected files, start by initializing git-crypt:
$ git-crypt init
Edit the .gitattributes file. In it, you will direct git to use git-crypt as a filter for specific files (or pattern of files). Make sure that you do this before committing the sensitive files into git.
Next, give access to specific users. This is where the interaction with gpg comes in. Proceed to add yourself and any other user that you want to have access to the encrypted files (you will need to have their gpg public key in your keyring).
$ git-crypt add-gpg-user USERID
USERID is a key fingerprint or email.
After this, you can continue with business as usual. Use git as usual to stage, commit or diff your files. Locally, the files appear to be in plaintext, but when pushed to a remote repository they are encrypted binaries.
At any time, you can lock the repository, like so:
$ git-crypt lock
Which will leave it in the same state that it would be when checking out by another user (or yourself on another machine). All files will be encrypted and unreadable. To unlock:
$ git-crypt unlock
I am very happy with the new setup: I can work with my dotfiles in a single repository and keep sensitive information secure with strong encryption. As always, security requires some diligence on the user’s part. git-crypt reduced the amount of inconvenience to a minimum and takes only a few minutes to setup, assuming you already know how to use gpg.
Steven Leiva writes a supervisor from scratch. I find these king of pieces very useful. They de-mystify some of the technologies, explore what is under the hood and end up enhancing my understanding, making future use much easier.
Last month, I mentioned another article by Richard Schneeman. Now, he is back with another in-depth, nuanced post about how to handle deprecations in libraries. Especially useful for library authors and mantainers, but good knowledge in general. The whole community gains when there are clear conventions around versioning, deprecation, support, etc. @schneems is doing a great service with his recent articles.
Richard Schneeman, writes a well though out post on library versioning. He previously wrote about Semver and now continues on that vein with how it applies in practice for library authors and users. The key take-away is that adhering to Semver and the widespread use of optimistic locking can alleviate a great deal of the pain of maintaining and upgrading dependencies for projects.
Internet security is fascinating. I have read advise that before using curl to download a file and piping directly to bash, you must ensure that you know what you are downloading. However, as this post proves, looking at the URL in your browser is not enough. By using a clever trick to detect how data is being pulled from a server, an attacker can present different content when URL is being downloaded and piped to bash. Security is hard. Really Hard.