modules: introduce mkcert (development certification authority)

[blaggacao]

mkcert module allows to temporarily install a development certificate authority per project

to dynamically create a (local) certificate authority on first entry — a little more secure

[mkcert]
enable = true

or (predefined, if that is of circumstantial relevance to the project)

[mkcert]
enable = true
root-ca.key = """
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----
"""
root-ca.cert = """
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
"""

What we get:

$ nix develop
[mkcert] Install development CA into the system stores...
[mkcert] The local CA is already installed in the system trust store! 👍
[mkcert] root CA directory: /nix/store/skw9isvhcacmwzpl7fxdlc81vq0gcdcm-rootCA
🔨 Welcome to devshell

[certs]

  mkcert        - A simple tool for making locally-trusted development certificates

[formatters]

  nixpkgs-fmt   - Nix code formatter for nixpkgs

[general commands]

  hello         - prints hello
  menu          - prints this menu

[linters]

  golangci-lint - golang linter

[utilites]

  hub           - github utility

$ [devshell]$ mkcert -CAROOT
/nix/store/skw9isvhcacmwzpl7fxdlc81vq0gcdcm-rootCA

$ [devshell]$ mkcert example.org

Created a new certificate valid for the following names 📜
 - "example.org"

The certificate is at "./example.org.pem" and the key at "./example.org-key.pem" ✅

It will expire on 27 April 2023 🗓

$ [devshell]$ git status
On branch da/mkcert-mod
Your branch is up to date with 'origin/da/mkcert-mod'.

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	example.org-key.pem
	example.org.pem

nothing added to commit but untracked files present (use "git add" to track)

[blaggacao]

There is, however, showstopper remaining ...

(a part from whether it shall be eligible or not for numtide/devshell)

[blaggacao]

This is not, unfortunately, not working, see #72

[zimbatm]

Something I feel quite strongly about is that devshell modules should be self-contained and not touch files outside of the project root. I am historically bad at testing and don't want to be responsible for rm -rf /$variable where $variable is empty :)

It doesn't mean I don't understand the need for such a module. In its current design, it could be added to a ./contrib folder with enough caveats added to it. And also making sure to prompt the user before doing any changes to the system.

Or, we could come up with a self-contained design.

OpenSSL can be pointed to SSL_CERT_FILE to find what CAs are available. I'm thinking, the project could generate a private/public key-pair in Nix. Then generate a new CA bundle that includes the defaults + the public key. And finally, expose both through environment variables. Have you thought about that approach yet?

[zimbatm]

PS: Browsers are moving in the direction of marking localhost connections as secure by default so the whole localhost SSL might become moot.

[blaggacao]

Or, we could come up with a self-contained design.

On the horizon, that could be feasible, indeed.
As far as hostnames are concerned, there is even an dead simple, yet exploratory, implementation of the underlying C library looking for a environment host file.

As for udev, I think also udev rules can have a runtime configuration at /run/..

OpenSSL can be pointed to SSL_CERT_FILE to find what CAs are available. I'm thinking, the project could generate a private/public key-pair in Nix. Then generate a new CA bundle that includes the defaults + the public key. And finally, expose both through environment variables. Have you thought about that approach yet?

I was prompted about it in the past, once. If we check a couple of libraries (openssl/wolfssl/mbedssl/etc) and see what environment variables they do observe, then it might actually become a lot cleaner, indeed.

We need to make sure those do not override the system ones, but complement them.

EDIT: We still could use mkcert for it's ease of use to generate host certificates. Just without -install flag.

[zimbatm]

In the context of a webapp, another thing you might do is start a reverse-proxy in front of the app that acts as the "load-balancer".
In the README, add a table that maps HTTP prefixes to ports for each backend. The browser then can hit a single end-point which makes things easier to manage.

Things get a bit trickier with IPC if the backends start talking to each-other.

[blaggacao]

Things get a bit trickier with IPC if the backends start talking to each-other.

Effectively, although not the most common scenario, some projects require to have properly set dns (for mTLS, I guess), even for local testing. One example is: github.com/openintegrationhub.

[zimbatm]

Do you think this PR is worth pursuing? I would need some tests.