I’ve been on a bit of a mission lately. I’ve undertaken to learn to use some of the tools that I initially paid only minor attention to, as they were introduced to solve certain problems (sometimes long) after I (or in some cases, colleagues and I) solved the same using custom in-house tools. See also my earlier insight on late adoption of popular tools.

Case in point: Version Control

As a system administrator / analyst, one finds oneself frequently adjusting or creating configuration files, scripts used to automate some tasks, or even application code. But you always want to be able to roll back to a known previous state, in case your update doesn’t perform as intended or expected. That’s what version control systems help manage.

Version control systems of various flavours have existed for decades, and certainly for longer than I have managed Unix and Linux systems professionally. But for the simplest environments, the early revision control systems just seemed to be overkill.

My colleagues at a former employer and I developed a very simple discipline of ensuring that a file to be edited was first backed-up in a known location relative to where the file is found. The backups add a date-based extension, (this later evolved to include date and time, as some files undergo sometimes complex changes multiple times in the same day), so it’s always easy to compare to the “real” file to identify what has been changed, or to undo a change that isn’t behaving as intended. The mechanism is very easily automated with some simple scripting, or in the simplest case, even a shell alias. This makes it easy to adhere to, even when one is forced into a situation where the usual tools are unavailable (such as when working in a “rescue” mode that didn’t mount all filesystems).

More recently, as yet another example of my catching up on using tools that have grown from appearing be just the latest fad to actually having proved their value and simply being the tool to use for certain tasks, I’ve been deepening my knowledge of Git and Github. These are tools that I took some time to learn about some years ago, but never really worked into my usual workflow. It turns out, I should have, not because I’ve run into any problems with how I have approached version control and collaboration with others in the past, but simply because these are the tools that are now recognized for those tasks.

… and I’m nowhere near being an expert on using them.

So in my quest to improve my knowledge of these tools, I ran into a news article, at FreeCodeCamp.org, that explains a particular vulnerability that exists in an environment where people’s work is openly shared and collaborated with, and how to protect ourselves from attacks attempting to exploit that vulnerability.

I wanted to point to the article from my own website, because I happen to take data security and integrity very seriously, and I found that the article clearly explains the problem and offers practical suggestions on how to avoid falling victim to such an attack.