Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: Struct names and members for secrets.conf (Russ Allbery)
----------------------------------------------------------------------
Message: 1
Date: Sat, 25 Dec 2021 19:57:00 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: Struct names and members for secrets.conf
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> 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 ([email protected]) <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.
------------------------------
Subject: Digest Footer
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
End of inn-workers Digest, Vol 136, Issue 8
*******************************************
