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