Struct names and members for secrets.conf

[Russ Allbery]

Julien ÉLIE <julien at trigofacile.com> writes:

> When using secretsconf->canlockadminsec to access it, I'm wondering
> whether it should not just be:

> cancels {
>     canlockadmin: [ "password" ]
>     canlockuser: [ "anotherpassword" ]
> }

> and we just call secretsconf->canlockadmin.
> When we have dozens of secrets in secrets.conf, it will be weird to always
> add "sec" in the parameter name, won't it?

Agreed.  I kind of like the idea of having a secretsconf (or even just
secrets) variable that holds the secret configuration and retrieving all
the secrets from there.  We could even wrap that in a small library to
make it easier to use everywhere in the source tree.

> That's why it populates secretsconf->canlockadmin(sec).
> Would it be better to have instead:
> - secretsconf->cancels->canlockadmin
> - cancels->canlockadmin
> - cancels_secrets->canlockadmin
> ?

> Maybe the first (secretsconf->cancels->canlockadmin) is better but we
> may also create as many simpler structs as group types in secrets.conf.
> Just asking in case you have a preference or another better idea.

The first has the nice advantage that it's super-obvious in the source
code that you're retrieving a secret, which you should then be careful
with (not log, etc.).

> With the first proposal, I'll probably have to add a
> secretsconf_get_cancels() function to retrieve the cancels groups in the
> secretsconf struct (and then use the result as if it were one of the
> last 2 proposals in fact).

Yeah, I wonder if we could have some sort of API that looks like:

    canlockadmin = get_secret(secrets, "cancels", "canlockadmin");

where get_secret() takes the secrets config_group and then a variable
number of arguments, all strings, that represent the hierarchical path
down to the key that we want.  It would just be a convenience wrapper
around the config_find_group(secrets, "cancels") and then
config_param_string(cancels, "canlockadmin", &data) call.

> If we have something like that in the future in secrets.conf:

> feed news.server.com {
>     login: "login"
>     password : "pass"
> }

> feed news.server2.com {
>     login: "login2"
>     password : "pass2"
> }

> We would have secretsconf->feed being a chained list of structs:

> struct feed {
>     char *tag;
>     char *login;
>     char *password;
>     struct feed *next;  /* next would be for "news.server2.com" tag */
> };

> (assuming we don't use nested groups inside them).

The intent of the config API was that you wouldn't take the config file
and turn it into a chained list up front, but instead you'd iterate
through it each time you needed something with

    feed = config_find_group(secrets, "feed");

and then config_next_group(feed) to get the next.  If that becomes tedious
we could add some config_find_group_by_tag() function that takes both the
group type and the tag.

-- 
Russ Allbery (eagle at eyrie.org)             <https://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <https://www.eyrie.org/~eagle/faqs/questions.html> explains why.