Forem: Czar Pino

Installing Composer Programmatically

Czar Pino — Mon, 15 Oct 2018 16:40:17 +0000

I have found it quite concerning that people usually setup up a programmatic Composer installation incorrectly. I feel since Composer's download page describes the download process using a script, people take it as the programmatic way of installing. This is, of course, an incorrect assumption which can be inferred from the hard coded installer SHA used in the sample script.

After recently dealing with build failures caused by an outdated installer hash, I wanted to address this issue correctly instead of simply kicking it down the road.

Updating the installer hash

Before talking about the proper solution, I want to highlight the improper but quick solution: updating the installer hash. If you urgently need to get something done and want to address the installer issue separately, it is helpful in the short term to simply update the installer SHA hash.

# Replace "93b54496392c062774670ac18b134c3b3a95e5a5e5c8f1a9f115f203b75bf9a129d5daa8ba6a13e2cc8a1da0806388a8"
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php -r "if (hash_file('SHA384', 'composer-setup.php') === '93b54496392c062774670ac18b134c3b3a95e5a5e5c8f1a9f115f203b75bf9a129d5daa8ba6a13e2cc8a1da0806388a8') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
php composer-setup.php
php -r "unlink('composer-setup.php');"

If you visit Composer's download page, you will quickly see the latest hash in the sample script. Alternatively, you can also check via the command line:

# via wget
wget -q -O - https://composer.github.io/installer.sig

# or via cURL
curl https://composer.github.io/installer.sig

Programmatic installation

The proper way to programmatically install Composer is to not rely on a hard coded hash. Looking a little closer, Composer download documentation actually links to the programmatic way of installing.

#!/bin/sh

EXPECTED_SIGNATURE="$(wget -q -O - https://composer.github.io/installer.sig)"
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
ACTUAL_SIGNATURE="$(php -r "echo hash_file('SHA384', 'composer-setup.php');")"

if [ "$EXPECTED_SIGNATURE" != "$ACTUAL_SIGNATURE" ]
then
    >&2 echo 'ERROR: Invalid installer signature'
    rm composer-setup.php
    exit 1
fi

php composer-setup.php --quiet
RESULT=$?
rm composer-setup.php
exit $RESULT

This script downloads the installer, verifies the hashes, then installs Composer. It checks the installer SHA against the latest hash obtained from https://composer.github.io/installer.sig whose value is automatically updated when a new release is made. This way, no hard coded hash is used within the script and you automatically get the latest version of Composer.

You have now future proofed programmatic Composer installation!

Originally published at https://plog.czarpino.com/install-composer-programmatically/

PHP Pseudo Random String

Czar Pino — Tue, 02 Oct 2018 14:21:36 +0000

When writing a random string generator in PHP, you must first consider whether or not you need a generator for a throwaway string ( e.g. placeholder or sample username) or a sensitive data (like a default password, application token, or salt). If you are generating for the latter, this article is for you.

Arbitrary length strings

Generating a random string in PHP involves two main steps:

First is generating a cryptographically secure set of random bytes
and second is encoding the bytes into a string of printable characters

For generating random bytes, there are two main approaches depending on PHP version. The pre-PHP7 approach uses openssl_random_pseudo_bytes while the PHP7 approach prefers random_bytes. An advantage of the latter is that it is native and does not need additional modules installed. If needed, openssl_random_pseudo_bytes is still available in PHP7 as an extension. But as both functions are considered cryptographically secure generators anyway, random_bytes is the recommended function.

For encoding the bytes into printable characters, there are also a couple of viable approaches. Most popular of these are base64_encode and bin2hex. You generally can't go wrong with either of these although bin2hex does have the advantage of being more predictable in length while base64_encode produces a shorter string with more variety in characters used.

Concretely, here is how you can generate a cryptographically secure random string :

// Pre PHP7
$numOfBytes = 10;
$randomBytes = openssl_random_pseudo_bytes($numOfBytes);
$randomString = base64_encode($randomBytes);

/// PHP7+
$numOfBytes = 10;
$randomBytes = random_bytes($numOfBytes);
$randomString = base64_encode($randomBytes);

If you need some predictability such as generating string with a specific length, encoding bytes using bin2hex will be more suitable despite being limited to even length strings only.

// Need to generate string with length 20!

// First generate 10 random bytes
$randomBytes = random_bytes(10);

// Now encode to get a 20 character string
$randomString = bin2hex($randomBytes);

Exact length strings

If you want complete control on the length of the random string generated, it would be more suitable to use PHP7's random_int function. And if your system is on PHP5, you can use a polyfill library called random_compat.

// Generate a 20 character string
$randomStr = '';
$allowedCharacters='0123456789abcdef';
for (
    $i = 0, $allowedMaxIdx = mb_strlen($allowedCharacters) - 1;
    $i < 20;
    $i ++
) {
    $randomStr .= $allowedCharacters[random_int(0, $allowedMaxIdx)];
}

And that's how you generate secure random strings in PHP. Happy coding!

Originally published at https://plog.czarpino.com/php-pseudorandom-string/

Manage Multiple SSH Logins

Czar Pino — Sat, 15 Sep 2018 03:14:38 +0000

It can be quite cumbersome when you have a lot of remote servers to log into. If they support SSH access or if you can configure them to do so, managing access to multiple servers can be pleasantly manageable.

What most programmers don't seem to know is that SSH can use a configuration file in ~/.ssh/config to create an alias of sorts for SSH hosts. If you use aliases in Bash then you can think of this as an alias for creating an SSH connection to a server.

# Without config
ssh -i ~/.ssh/linode01.id_rsa czar.pino@120.111.122.123

# With config
ssh cp.linode01

By using the ~/.ssh/config file, it no longer becomes necessary to provide all of the connection parameters every time you want to connect. All information needed to connect to a host can just be defined in a host entry inside the config file.

Host cp.linode01
    Hostname 120.111.122.123
    User czar.pino
    IdentityFile ~/.ssh/linode01.id_rsa

Another side benefit to this is that you also automatically have a document of all SSH servers you can connect to. No need to maintain an easily outdated spreadsheet which has to be updated separately.

Host cp.linode01
    Hostname 120.111.122.123
    User czar.pino
    IdentityFile ~/.ssh/linode01.id_rsa

Host cp.linode02
    Hostname 120.111.122.124
    User czar.pino
    IdentityFile ~/.ssh/linode02.id_rsa

Host cp.ec2-01
    Hostname 121.111.122.123
    User ec2-user
    IdentityFile ~/.ssh/ec2-01.id_rsa

Host cp.ec2-02
    Hostname 121.111.122.124
    User ec2-user
    IdentityFile ~/.ssh/ec2-02.id_rsa

Originally published at https://plog.czarpino.com/storing-database-backups/

Storing Database Backups

Czar Pino — Sat, 08 Sep 2018 15:32:05 +0000

Where to store database backups has been a long recurring conversation in most teams I've worked with. This comes as no surprise as it is undoubtedly necessary to backup data. Data loss is a serious risk and any server admin worth his salt takes backing up seriously.

The short version of the advice I often give is to use S3 or an S3-like service (e.g. Glacier, Archival). The reason being, these services promise the two most important factors of a backup storage: durability and security.

Storage must be durable

Since a backup is typically a worst-case fallback, the storage medium must be very durable. This means, the storage itself must be highly resistant to data loss. The last thing you want is a corrupted backup when trying to recover lost data.

Storage concerns regarding durability are important because there are typically no recovery mechanisms for lost backups. It is therefore important to focus on preventative measures to ensure there is zero data loss in backup data. This means accounting for hardware failure, human error, and natural data degradation.

Storage must be secure

Another important characteristic of a good backup storage is security. This is pretty intuitive considering backups typically contain sensitive data of both the business and it's customers. It is, therefore, important to ensure data is encrypted during transit and at rest: this means using TLS and storage encryption. An intermediate node in the network and someone with physical access to the backup's machine should both be unable to view the data in plain text.

Convenience and reliability

Ensuring the durability and security of backup storage requires significant effort. The second reason for recommending S3-like services, which closely follows the first, is convenience and reliability. Services like S3 already have solid infrastructures in place which address durability and security concerns. Extensively documented SDKs for programmatically interfacing with the service are also provided. These conveniences are possible largely because storage and retrieval of data is the core of their business.

While it is entirely possible to build your own durable and secure storage server, it will not be without significant effort. Achieving a level of reliability 3rd party services provide will require resources better spent building your actual product.

Using a regular server instance and configuring it yourself is a common and naive recommendation. Unfortunately, it is not only inferior in every aspect but is also more expensive. Utilizing S3 or a similar service is the most prudent choice unless you have an unusually special situation.

Summary

There are a few key considerations for a reliable backup storage including durability and security. Trying to achieve this yourself can easily side track you from the core operations of your business while still ending up with an inferior storage solution. The most prudent way to store backups is by employing specialized and reputable services such as Amazon S3, Glacier, or Google Archival. All excellent choices considering the convenience and reliability they have over building your own.

Originally published in https://plog.czarpino.com/storing-database-backups/

Show current git branch

Czar Pino — Thu, 06 Sep 2018 15:05:29 +0000

During development, it can be quite convenient to always know which branch you are on without having to do a git status. Most developers use unnecessarily sophisticated bash scripts to modify the prompt string 1 (PS1) variable of their shell. As embarrassing as it is, I was most developers (I even had my own repo with a "performance" focused approach). Now, I simply use a one-liner. In fact, I just visit this article and copy paste the following into my ~/.bash_profile:

# Show current git branch when entering a git repository
export PS1="\W \[\e[0;36m\]\$(git rev-parse --abbrev-ref HEAD 2> /dev/null)\[\e[0m\]\$ "

Originally published in https://plog.czarpino.com/show-current-git-branch/