> > > diff --git a/transport.c b/transport.c
> > > index d57e8de..b1098cd 100644
> > > --- a/transport.c
> > > +++ b/transport.c
> > > @@ -652,7 +652,7 @@ static const struct string_list *protocol_whitelist(void)
> > >
> > > if (enabled < 0) {
> > > const char *v = getenv("GIT_ALLOW_PROTOCOL");
> > > - if (v) {
> > > + if (v || !git_config_get_value("core.allowProtocol", &v)) {
> > > string_list_split(&allowed, v, ':', -1);
> > > string_list_sort(&allowed);
> > > enabled = 1;
> >
> > I thought at first we'd have to deal with leaking "v", but "get_value"
> > is the "raw" version that gives you the uninterpreted value. I think
> > that means it may give you NULL, though if we see an implicit bool like:
> >
> > [core]
> > allowProtocol
> >
> > That's nonsense, of course, but we would still segfault. I
> > think the easiest way to test is:
> >
> > git -c core.allowProtocol fetch
> >
> > which seems to segfault for me with this patch.
>
> what is the desired behavior when a user provides a config in a way that
> isn't intended?
oh...I can just drop in git_config_get_string_const() instead.
--
Brandon Williams