Struct names and members for secrets.conf

[Russ Allbery]

Julien ÉLIE <julien at trigofacile.com> 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 (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.