Hi,

On Mon, Jan 14, 2019 at 11:20 AM Daniel Stenberg <daniel_at_haxx.se> wrote:
>
> On Mon, 14 Jan 2019, Mischa Salle via curl-library wrote:
>
> > Hmm, not sure this would add very much, but on the other hand could indeed
> > as Ray points out break things in unexpected ways and make life in general
> > more complicated.
>
> Sure, users who'd decide to restrict curl would probably get it "more
> complicated" in some ways but that's by choice and that also saves them from
> using applications/scripts in ways they don't approve of. A complication that
> brings benefits.
> If you don't care (which I assume most people won't), you don't set anything
> and then there's nothing extra!

Assuming it's only the user setting it directly, then yes, it's
probably not so much of a complication. I was wondering about other
parties setting it, for example in nested scripts or in global bash
settings.

> > If you want to add policies, I think you will be needing more than a simple
> > env variable, i.e. something like a config file.
>
> The problem with a config file is that it then becomes set for all curl
> invokes and not just the one from a specific shell, which an environment
> variable would do.

I see your point. For simple occasional debugging purposes, I agree
that a shell variable is fine, but the type of restrictions that have
been proposed in this thread seemed to me too complicated for that.

> I would also imagine that restricting curl like this would
> be something often done to test and experiment first and then you really don't
> want to affect any other scripts than the particular one you want to try out
> right now.
>
> Also suggested a environment variable because it is easy to play with from a
> user's stand-point.

Sure, if that's the only use, and for the simple scenarios, then yes
indeed that's fine.

> > In any case you need the cooperation of the script/program calling
> > curl as it would be trivial to circumvent (declare -r doesn't help).
>
> Why would a script/application author actively work against this? I don't
> understand what motivations such developers would have. I mean the typical
> well-meaning ones, not the rare malicious or misinformed developers who I of
> course acknowledge exist but I think is a very small minority.
>
> A developer who wants a script or program to run and use an insecure protocol
> for example, they do that for a reason as they perhaps only have access to a
> service over that protocol. Why would they try to trick their users into
> believing they're not using those insecure protocols?

Perhaps I misunderstood your typical scenario. In my experience, when
something doesn't work, developers find a way around it and not per se
for malicious reasons, but just to make it work. Which in this case
would be quite trivial. I'd argue it's more hinting at what you want
the application to do than actually inhibiting it. That's fine of
course, but people shouldn't start thinking it's actually a secure
mechanism to reliably restrict the available protocols.

> Maybe I'm just too much of an optimist! =)

Nothing wrong with that (-;
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2019-01-14