On 11/03, Jeff King wrote:
> On Thu, Nov 03, 2016 at 11:45:38AM -0700, Brandon Williams wrote:
>
> > On 11/03, Jeff King wrote:
> > >
> > > So this seems like a reasonable direction to me. It obviously needs
> > > documentation and tests. Arguably there should be a fallback "allow"
> > > value wh
On Thu, Nov 03, 2016 at 11:45:38AM -0700, Brandon Williams wrote:
> On 11/03, Jeff King wrote:
> >
> > So this seems like a reasonable direction to me. It obviously needs
> > documentation and tests. Arguably there should be a fallback "allow"
> > value when a protocol is not mentioned in the con
On 11/03, Jeff King wrote:
>
> So this seems like a reasonable direction to me. It obviously needs
> documentation and tests. Arguably there should be a fallback "allow"
> value when a protocol is not mentioned in the config so that you could
> convert the default from "user" to "never" if you wan
On Thu, Nov 03, 2016 at 11:19:54AM -0700, Brandon Williams wrote:
> On 11/03, Jeff King wrote:
> > +
> > + /* unknown; let them be used only directly by the user */
> > + return PROTOCOL_ALLOW_USER_ONLY;
> > +}
> > +
> > int is_transport_allowed(const char *type)
> > {
> > - const struct s
On Thu, Nov 03, 2016 at 01:53:27PM -0400, Jeff King wrote:
> I'd design the new system from scratch, and have it kick in _only_ when
> GIT_ALLOW_PROTOCOL is not set. That lets existing callers continue to
> have the safe behavior until they are ready to move to the new format.
>
> Something like
On 11/03, Jeff King wrote:
> +
> + /* unknown; let them be used only directly by the user */
> + return PROTOCOL_ALLOW_USER_ONLY;
> +}
> +
> int is_transport_allowed(const char *type)
> {
> - const struct string_list *allowed = protocol_whitelist();
> - return !allowed || string_l
On 11/03, Jeff King wrote:
> On Thu, Nov 03, 2016 at 10:51:31AM -0700, Brandon Williams wrote:
>
> > > > I don't know if I'm sold on a 'user' state just yet, perhaps that's just
> > > > because I view a whitelist or blacklist as well black and white and
> > > > having this user state adds in a gra
On Thu, Nov 03, 2016 at 10:51:31AM -0700, Brandon Williams wrote:
> > > I don't know if I'm sold on a 'user' state just yet, perhaps that's just
> > > because I view a whitelist or blacklist as well black and white and
> > > having this user state adds in a gray area.
> >
> > Well the "user" stat
On Thu, Nov 03, 2016 at 10:39:35AM -0700, Stefan Beller wrote:
> >> protocol.X.allow = always | user | never
> >
> > It sounds like there is interest for this sort of behavior, it would
> > definitely require a larger change than what I initially proposed. One
> > problem I see though is that w
On Thu, Nov 03, 2016 at 10:25:15AM -0700, Brandon Williams wrote:
> > So I think this probably needs to be a separate parallel system where
> > each protocol can be white- or black-listed in a context-specific way.
> > Like:
> >
> > protocol.X.allow = always | user | never
>
> It sounds like t
On 11/03, Stefan Beller wrote:
> >> protocol.X.allow = always | user | never
> >
> > It sounds like there is interest for this sort of behavior, it would
> > definitely require a larger change than what I initially proposed. One
> > problem I see though is that with this we have support for both
>> protocol.X.allow = always | user | never
>
> It sounds like there is interest for this sort of behavior, it would
> definitely require a larger change than what I initially proposed. One
> problem I see though is that with this we have support for both a
> blacklist and a whitelist. Which wi
On 11/03, Jeff King wrote:
> On Wed, Nov 02, 2016 at 05:22:25PM -0700, Jonathan Nieder wrote:
>
> > Another difficulty with setting GIT_ALLOW_PROTOCOL globally is that it
> > requires copy/pasting the default value from upstream and then adding
> > the values I want. There's no straightforward wa
On Wed, Nov 02, 2016 at 05:22:25PM -0700, Jonathan Nieder wrote:
> Another difficulty with setting GIT_ALLOW_PROTOCOL globally is that it
> requires copy/pasting the default value from upstream and then adding
> the values I want. There's no straightforward way to get the current
> value and add
Jonathan Nieder writes:
> That is, would it be possible to use something like
>
> [protocol "sso"]
> allow = always
>
> instead of
>
> [core]
> allowProtocol = file:git:http:https::sso
>
> ?
That sounds like quite a large usability improvement to me.
Thanks for CCing me.
I haven't looked at this implementation in detail, but it would be
good to move this configuration into the config system because I think
we can more easily provide a default safe configuration.
It would be nice to use this to introduce a default list of
whitelisted protocols
(+peff and bburky, who introduced GIT_ALLOW_PROTOCOL)
Brandon Williams wrote:
> Add configuration option 'core.allowProtocol' to allow users to create a
> whitelist of allowed protocols for fetch/push/clone in their gitconfig.
Ooh.
This would be especially useful at $DAYJOB, where there is a cus
On Wed, Nov 02, 2016 at 04:46:13PM -0700, Brandon Williams wrote:
> > > 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:
>
> > > 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_
On 11/02, Jeff King wrote:
> On Wed, Nov 02, 2016 at 07:05:39PM -0400, Jeff King wrote:
>
> > > +core.allowProtocol::
> > > + Provide a colon-separated list of protocols which are allowed to be
> > > + used with fetch/push/clone. This is useful to restrict recursive
> > > + submodule initializatio
On 11/02, Jeff King wrote:
> On Wed, Nov 02, 2016 at 03:20:47PM -0700, Brandon Williams wrote:
>
> > Add configuration option 'core.allowProtocol' to allow users to create a
> > whitelist of allowed protocols for fetch/push/clone in their gitconfig.
> >
> > For git-submodule.sh, fallback to defau
On Wed, Nov 02, 2016 at 07:05:39PM -0400, Jeff King wrote:
> > +core.allowProtocol::
> > + Provide a colon-separated list of protocols which are allowed to be
> > + used with fetch/push/clone. This is useful to restrict recursive
> > + submodule initialization from an untrusted repository. A
On Wed, Nov 02, 2016 at 03:20:47PM -0700, Brandon Williams wrote:
> Add configuration option 'core.allowProtocol' to allow users to create a
> whitelist of allowed protocols for fetch/push/clone in their gitconfig.
>
> For git-submodule.sh, fallback to default whitelist only if the user
> hasn't
On 11/02, Stefan Beller wrote:
> > This is useful to restrict recursive
> > + submodule initialization from an untrusted repository.
>
> ok. Though as a user submodules may not spring to mind immediately here.
> I think this is generally useful, too. e.g. an admin could put this in
> the sy
On Wed, Nov 2, 2016 at 3:20 PM, Brandon Williams wrote:
> Add configuration option 'core.allowProtocol' to allow users to create a
> whitelist of allowed protocols for fetch/push/clone in their gitconfig.
>
> For git-submodule.sh, fallback to default whitelist only if the user
> hasn't explicitly
Add configuration option 'core.allowProtocol' to allow users to create a
whitelist of allowed protocols for fetch/push/clone in their gitconfig.
For git-submodule.sh, fallback to default whitelist only if the user
hasn't explicitly set `GIT_ALLOW_PROTOCOL` or doesn't have a whitelist
in their gitc
26 matches
Mail list logo
