"GOT", but the "O" is a cute, smiling pufferfish. Index | Thread | Search

From:
Stefan Sperling <stsp@stsp.name>
Subject:
Re: RFC: secrets for gotd
To:
Omar Polo <op@omarpolo.com>
Cc:
gameoftrees@openbsd.org
Date:
Sun, 25 Aug 2024 20:31:37 +0200

Download raw body.

Thread
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.