Status update March 2020

I didn’t get much done during March due to, well, global pandemic, but still I have some updates.

GitHub Actions in Cute Chess

I submitted an initial version of the GitHub Actions workflow manifest for Cute Chess. The workflow builds and tests the code in Windows, macOS and Ubuntu Linux using different Qt versions. It’s run for all pushes and pull requests. The current manifest file is quite verbose and lacks the support for build artifacts.

One difference I noticed compared Travis CI is that GitHub Actions fail fast by default. The builds are run in parallel according to the build matrix. If there’s an error in one of the builds, the other are immediately canceled. This behavior can be controlled with the fail-fast option.

There’s also difference how Qt is installed: there doesn’t seem to be officially supported way to install Qt to be used in GitHub Actions so a third-party solution must be used. Currently, our workflow is configured to use jurplel/install-qt-action. While you can “pin” the version of the third-party workflow, the workflow itself pulls the actual (unofficial) installer from pip. I would like to see the Qt company provide an officially supported mechanism to install Qt for use in GitHub Actions.

Rolling your own CA

I’ve been thinking about client-side certificate based authentication / authorization for my home network. In short, I would run my own certificate authority (CA) and assign certificates to devices for authentication. There may be more than one network to authenticate to (think home and summer house). There would be only a few applications (usually one) a user could get access to. Nginx would act as a TLS terminating reverse proxy.

There are at least two ways I think how the CA could work:

1. One CA that signs certificates for all networks. Access is determined by nginx configuration.

2. One root CA and an intermediate CA for each network. Access is determined whether the intermediate has signed the certificate.

Conceptually, the option 2 sounds appealing: for a given device to get access to a network, only the intermediate CA signing the certificate signing request is required. There’s no need to update any nginx configuration. However, running multiple CAs is more complex and error prone. Additionally, a device with access to multiple networks requires multiple certificates to be installed. I bounced both ideas to several people and decided to go with option 1 for its simplicity.

Here are some resources I’ve found useful while investigating this topic:

• OpenSSL Certificate Authority: A guide that demonstrates how to act as your own CA using OpenSSL.
• CN-based client authentication with nginx: An example nginx configuration for performing CN based client-side certificate authentication.

That’s all I have for this month, see you in the next one!