fix: unquote quoted URL's to avoid libcurl errors

[therealdwright]

This commit will unquote URL's allowing them to be supported by
libcurl and eliminate any errors when a valid (quoted) URL is supplied
by a user.

Closes #2579

Signed-off-by: Daniel Wright danielwright@bitgo.com

What type of PR is this?

/kind bug

Any specific area of the project related to this PR?

/area engine

What this PR does / why we need it:
As mentioned in the associated issue, I was setting up some
values which contained special character as the URL had a
secret token in it, and wanted to quote to avoid any ambiguity
or issues when adding to a manifest. I encountered a libcurl
error that my valid (quoted) string was invalid.

Which issue(s) this PR fixes:
Fixes #2579

Special notes for your reviewer:
N/A

Does this PR introduce a user-facing change?:
N/A

fix: unquote quoted URL's to avoid libcurl errors

[FedeDP]

/approve

[poiana]

LGTM label has been added.

Git tree hash: f4393031fc317e391c48d351ca5add9d2ed975ef

[FedeDP]

Thank you! This is a nice and small fix :)
/milestone 0.35.0

[leogr]

I believe this workaround should be ok in most cases. However, the root issue is the command line flag parsers instead of here.

That being said, I'm ok to merge this, but we should add a TODO somewhere to fix the root cause properly.

cc @jasondellaluce

[therealdwright]

the root issue is the command line flag parsers

I thought this was the best place to fix as the issue is really with libcurl and I have this issue if I use the yaml OR the command line parser hence this approach. LMK if you still want a TODO added.

[jasondellaluce]

I see what you're doing here. So, in my opinion this is something we should support properly with the -o option as well, and perhaps being consistent with what happens in falco.yaml. I understand that doing a more general solution that involves proper string escaping in the config and command line is not something that we can do easily few days before releasing Falco, so in this case I would be ok on doing having a workaround like this.

With my suggestion, the workaround should not break future developments because it will just become "protective", in the sense that it will attempt unescaping the string in case it was not unescaped before (which hopefully we'll do from -o and falco.yaml for the next release).

I will leave the rest of the reviewers and the release managers the decision on whether include this or not for 0.35! cc @leogr @FedeDP

[FedeDP]

/approve

[poiana]

LGTM label has been added.

Git tree hash: ccf3c9295007ec3faaf82fc312ebca242aefeb09

[leogr]

LGTM, now! 👍

[poiana]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: FedeDP, leogr, therealdwright

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [FedeDP,leogr]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment