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 (Julien ?LIE)
2. Re: Struct names and members for secrets.conf (Russ Allbery)
----------------------------------------------------------------------
Message: 1
Date: Sun, 26 Dec 2021 14:12:34 +0100
From: Julien ?LIE <[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; format=flowed
Hi Russ,
>> 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.
OK for "secrets" instead of "secretsconf".
> We could even wrap that in a small library to
> make it easier to use everywhere in the source tree.
Like innconfval does for instance?
A secretsval program that would give the secrets when executed? (so that
they can be retrieved from Perl, Python and shell scripts)
Yet, we may probably want a general program for that, and not a
dedicated one for each configuration file...
Why not add a -f flag (for "file") to innconfval? Default value is
"inn.conf", and it can be set to other file names (like "secrets.conf").
innconfval -f secrets.conf canlockadmin
would then return the list of canlock admin secrets.
>> 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.).
Yes, that's a nice advantage.
>> 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.
Not all secrets are strings. Here, for canlockadmin, it is a vector.
So maybe we need get_secret_list(secrets, "cancels", "canlockadmin") and
another get_secret_string() function for future string secrets?
A drawback of these getter functions is that we'll have to parse the
config_group tree each time we need a secret. That's pretty quick
though, and we do not need them continuously but only for a few actions
(like posting or initial authentication against a peer), contrary to
parameters like inn.conf timeout, wireformat and like.
So it seems probably fine to query the secret in the config_group tree.
>> 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.
Oh yes, I understand the principle.
We'll see for the config_find_group_by_tag() later if need be (not
useful for Cancel-Lock).
--
Julien ?LIE
??Only wimps use tape backup: _real_ men just upload their important
stuff on ftp, and let the rest of the world mirror it?;)?? (Linus
Torvalds, 1996)
------------------------------
Message: 2
Date: Sun, 26 Dec 2021 19:23:16 -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:
>> We could even wrap that in a small library to
>> make it easier to use everywhere in the source tree.
> Like innconfval does for instance?
> A secretsval program that would give the secrets when executed? (so that
> they can be retrieved from Perl, Python and shell scripts)
I hadn't been thinking of that, but that's also a good point. Although we
could wait on the program until we have our first use case for it.
> Yet, we may probably want a general program for that, and not a dedicated
> one for each configuration file...
> Why not add a -f flag (for "file") to innconfval? Default value is
> "inn.conf", and it can be set to other file names (like "secrets.conf").
That's a good idea!
> Not all secrets are strings. Here, for canlockadmin, it is a vector.
> So maybe we need get_secret_list(secrets, "cancels", "canlockadmin") and
> another get_secret_string() function for future string secrets?
Oh, good point, I hadn't thought about that. I'm not entirely sure the
additional complexity is worth it (your approach looked fine). We can
always wait and see if that would be a simplification.
> A drawback of these getter functions is that we'll have to parse the
> config_group tree each time we need a secret. That's pretty quick
> though, and we do not need them continuously but only for a few actions
> (like posting or initial authentication against a peer), contrary to
> parameters like inn.conf timeout, wireformat and like.
> So it seems probably fine to query the secret in the config_group tree.
Yes, all that stuff should be quite fast. I would be very surprised if a
benchmark showed it as significant. The configuration is already parsed
and in memory, so it's just some string comparisons.
--
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 9
*******************************************
