Match environment input to mirror Gitea's

[kousu]

See the individual commits!

And probably rebase not squash this!

[kousu]

I like the names GITEA_ROOT_URL and GITEA_TOKEN because I think the terminology is easier to follow when you're cross-referencing the Gitea docs, but I'm having second thoughts about GITEA_PUBLIC_URL.

If we allow configuring GITEA_PUBLIC_PATH then we have to allow configuring GITEA_PUBLIC_URL, because it could be anywhere: maybe we stick it on a different partition and set up an nginx location /bids-validator-results { root /path/to/other/partition } to glue in that path; maybe we use something like s3fs to stick it up on a CDN and then have to set GITEA_PUBLIC_URL=https://our-bucket.s3.amazonaws.com/bids-validator.

On the other hand, maybe we don't need to allow configuring GITEA_PUBLIC_PATH either. Instead we can set GITEA_WORK_DIR (see ref) and derive GITEA_PUBLIC_PATH from that; we need that anyway, because part of why #5 is still drafted is it needs some way to compute GITEA_REPOSITORY_PATH, which is easy to do from GITEA_WORK_DIR but less reliable to do from GITEA_PUBLIC_PATH.

EDIT: I went with adding GITEA_CUSTOM, which is something Gitea itself reads, and generating the output directory based on that. This assumes that your custom/ will always be, which I think is true unless you're doing some weird nginx/apache hacks. And I think we're okay (are we?) assuming that the servers we're aiming at are not going to grow so large to need anything like that.

[kousu]

This is awkward!

In our deployments, this will be /srv/gitea/gitea. On my dev machine I have ~/src/gitea/ and ~/src/bids-hook.

I don't know. Maybe this should be a mandatory input? But then again, if you on a server where you're explicitly setting GITEA_CUSTOM for gitea, you can also set it for bids-hook and then GITEA_APP_PATH is irrelevant.

[mguaypaq]

I realize now that I didn't mention this before, but: the start script is meant to disappear from the repo at some point! It's just scaffolding for manual, local testing on my own machine (or yours!) while we develop a v1. Hence all the hardcoded values and dummy secret and token.

So actual deployment situations are out of scope for this file.

[kousu]

That makes sense. In that case, the part that mirrors Gitea's defaults logic should probably make its way into Go instead of shell. I could probably copy it straight out of their codebase.

And the environment variables that remain would migrate to a systemd .service file? Is it weird to put credentials in a .service file?

[mguaypaq]

It looks like systemd has a whole system in place for credentials. According to System and Service Credentials:

Within unit files, there are four settings to configure service credentials.

1. LoadCredential= may be used to load a credential from disk, from an AF_UNIX socket, or propagate them from a system credential.
2. SetCredential= may be used to set a credential to a literal string encoded in the unit file. Because unit files are world-readable (both on disk and via D-Bus), this should only be used for credentials that aren’t sensitive, i.e. public keys/certificates – but not private keys.
3. LoadCredentialEncrypted= is similar to LoadCredential= but will load an encrypted credential, and decrypt it before passing it to the service. For details on credential encryption, see below.
4. SetCredentialEncrypted= is similar to SetCredential= but expects an encrypted credential to be specified literally. Unlike SetCredential= it is thus safe to be used even for sensitive information, because even though unit files are world readable, the ciphertext included in them cannot be decoded unless access to TPM2/encryption key is available.

So, systemd wants to make credentials available as files, and currently bids-hook wants to accept credentials as environment variables. I guess I can change the environment variable to contain a path to the secret, rather than the secret itself, and that should be sufficiently flexible for manual testing and also for systemd-controlled execution.

[mguaypaq]

Looks good, thanks! As you said, for a first version it's definitely ok to assume that we're not doing fancy nginx stuff. I don't think it would be hard to support if/when we feel the need, so let's ignore it for now.