On Fri, 7 Apr 2017, VMnIgP5yDWURkomdpGjx via curl-users wrote:

> Deprecate the short "-k" option in favour of requiring the longer form
> "--insecure".

We work *really* hard at not breaking compatibility/existing functionality and
this is quite the opposite: breaking it on purpose.

I'm not convinced that a lot of users of -k are likely to have done it by
mistake and that forcing them to use --insecure will save large amounts. A few
sure, but I think the majority of the ones who use it when they shouldn't, do
it because they've copied an instruction from somewhere or run a script they
didn't write themselves. And the mistake of using the option while testing and
letting it slip into production feels like it is still as possible to happen
as it hardly happens because of the option names but more about not changing
the command lines when moving them.

We could discuss adding a warning output, but I know from previous discussions
that people feel strongly about even such annoyances. Not to mention how a
warning like that risk causing a "fatique" that causes users get used to
seeing the warning when -k is used for testing so users won't react anyway
when the warning then appears where it shouldn't, in production.

> It would be interesting to know the prevalance in open-source software of
> curl scripts using "-k" or "--insecure", like Google did for the Mad Gadget
> vulnerability
> https://opensource.googleblog.com/2017/03/operation-rosehub.html

Only that it isn't that straight-forward to actually figure out when -k /
--insecure is used "wrongly" or not just based on scripts/command lines. At
least it would require some sort of definition or classification that I
haven't figured out how it would work, to make the outcome actually useful.

-- 
  / daniel.haxx.se
-----------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-users
Etiquette:   https://curl.haxx.se/mail/etiquette.html