Security

Overview Despite best efforts to train, educate, warn developers to always capture and handle function results, one still can manage to forget and get burned in the process. Let’s say you have this piece of code that deals with critical process: int critical_func() { return 1234; } It’s far too common for folks to use critical_func() in this manner: int use_critical_func() { critical_func(); return 0; } The values returned from critical_func() could mean anything: Cannot connect to a service, balance is empty, rocket is faulty, … Failure to capture and act based on those return values could result in any undefined/undesired behaviour: Memory leak, crash, silent failures, … Let’s see how we can enforce developers to use return value from mission critical functions.

A couple of years ago I installed gitolite to self-host Git and access it via SSH. All was well until recently I discovered a problem: I could not access some repositories: $ git clone git@simpleit.us:apache2-config.git Cloning into 'apache2-config'... R access for apache2-config DENIED to gitadmin (Or there may be no repository at the given path. Did you spell it correctly?) fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.

Recently I ran gpg --gen-key and had problems with lack of randomness (entropy). If you are running a virtual server and have little traffic coming your way, you will not have enough entropy for security/cryptographic applications. To address this problem, you could use rng-tools and Haveged packages. This tutorial will show how to add more entropy for Ubuntu/Debian. You can do the same for other Linux distros. Guide rng-tools Install rng-tools:

Nowadays getting HTTPS is no longer expensive. GitHub provides free HTTPS for your GitHub pages and you can choose to enable in the Settings for each of your repository: The benefits of this is multi-fold: Better security for your readers Better SEO for your pages Styles will not degrade because when loading from HTTPS, no insecure HTTP styles and scripts are allowed. You can however load scripts and styles served via HTTPS on your HTTP pages If you are using a blogging engine like Hugo, remember to change our baseURL to HTTPS or your readers will moan and groan about ugly face of your page without make ups from CSS & Javascript: