Andrew Snare wrote:
>Hi All,
>
>With digest authentication currently broken for repositories due to a
>problem with Apache's authentication of subrequests, I recently switched
>to using basic authentication over SSL.
>
>While trying to configure Subversion to accept my private CA, I
>encountered a problem whereby my .subversion configuration files
>are shared across several machines but my home directory is not
>always the same. This means that the ssl-authority-files and
>ssl-client-cert-file configuration directives are useless for me.
>While originally I hoped that relative paths may be treated relative
>to the configuration file, this turns out not to be the case: the
>values get passed as-is to neon, which in turn simply uses fopen()
>on the path provided.
>
>
[...]
>This got me thinking, and it occurred that env-variable expansion
>in the configuration file would solve the problem.
>
>
I think using environment variables is dangerous, in general, because it
makes it so hard to track down problems. However,
>The ConfigParser module from python doesn't support this feature,
>so there is no obvious guidance in terms of syntax. However, I
>imagine something like Unix-shell expansion is unambiguous, relatively
>simple and should not break many existing configuration files.
>
>
We already have a syntax for expanding variables. If people really,
really want env var expansion, I'd use the standard "%(NAME)s" syntax,
but expand from environment variables _only_ in the [DEFAULT] section.
>Since the parser (in config_file.c) is fairly simple, I've created
>the attached patch which implements the following rules:
>
> * Expansion is of the form ${ENV} where ENV is the name of the
> environment variable being inserted.
> * A non-existent environment variable expands as nothing (it's
> not an error).
>
>
This is wrong. Silently ignoring invalid entries in the config file is a
recipe for disaster.
> * To insert a $ symbol, $$ is used. I think that this is preferable
> to ignoring $ if it's not followed by a { since then something
> even fancier would be required for the corner case where a ${
> sequence is wanted.
> * Anything other use of $ is an error (which will ensure that most
> existing files which use $ are not silently interpreted incorrectly).
>
>Comments, etc, would be welcome.
>
>
[...]
>@@ -96,17 +164,27 @@
> /* Read the first line of the value */
> svn_stringbuf_setempty (ctx->value);
> for (ch = getc (ctx->fd); /* last ch seen was ':' or '=' in parse_option. */
>- ch != EOF && ch != '\n';
>+ err == SVN_NO_ERROR && ch != EOF && ch != '\n';
> ch = getc (ctx->fd))
> {
>- const char char_from_int = ch;
>- svn_stringbuf_appendbytes (ctx->value, &char_from_int, 1);
>+ char char_from_int;
>+ switch(ch)
>+ {
>+ case '$':
>+ /* This indicates an environment variable needs to be expanded. */
>+ err = parse_expand_env_in_value (ctx);
>+ break;
>+
>+ default:
>+ char_from_int = ch;
>+ svn_stringbuf_appendbytes (ctx->value, &char_from_int, 1);
>+ }
> }
> /* Leading and trailing whitespace is ignored. */
> svn_stringbuf_strip_whitespace (ctx->value);
>
>
And what happens if the loop exited with an error? You should just use
SVN_ERR above. acually, looking at this function, we could do away with
the "err" variable completely...
--
Brane ÄŒibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 27 13:24:01 2003