Download raw body.
RFC: secrets for gotd
On Sun, Aug 25, 2024 at 07:46:01PM +0200, Omar Polo wrote:
> Currently gotd.conf holds some sensible data for http notifications in
> plain. Furthermore gotd.conf has to be world-readable to not break
> gotsh(1).
gitwrapper, not gotsh
> So, here's a proposal to break out the secrets in a separate config file
> which can (and must) be owned by root and not world-readable. When
> parsing the files for gotsh(1) or similar purpose we can skip the
> "include".
>
> It's mostly about syntax and taste, hence an RFC instead of a diff.
> Let's bikeshed a bit and once we reach a consensus I'll start working on
> it.
>
> While here I couldn't help but also try to move "insecure" before "url",
> because otherwise I would read it as "insecure auth", which could also be
> fine, or "insecure hmac" which is... curious :)
I agree that moving the insecure keyword to the front makes sense.
> # /etc/gotd.secrets.conf
> auth "xyz" {
> username "flan"
> password "flan123!"
> }
>
> hmac "abc" {
> secret "o0wgEB5QyRRKUwHlobeVX1JguCvkTBBohhQnINbxaOs="
> }
>
>
> # /etc/gotd.conf
> include secret "/etc/gotd.secrets.conf" # root-owned; skipped by gotsh
I would prefer "include secrets" since the file can contain multiple
secrets.
> repository "src.git" {
> path "/var/git/src.git"
> permit rw :developers
> permit ro anonymous
>
> notify {
> branch "main"
>
> insecure url "http://some.other.host:8080/foo" auth "xyz"
> # or
> insecure url "http://..." hmac "abc"
> # or even both
> }
> }
>
>
> Using for `url "..." auth' an undefined label or an hmac value will
> produce an error. Likewise for `url "..." hmac'.
>
>
> Opinions?
I like this proposal. I don't see a problem with implementing this.
Is there any specific reason you didn't copy the smtpd table-based design?
I was thinking we could probably just steal code from there.
RFC: secrets for gotd