Provide curl options in curl command#7343
Provide curl options in curl command#7343qiluo-msft merged 1 commit intosonic-net:masterfrom VenkatCisco:VenkatCisco/PR6_no_proxy_curl
Conversation
VenkatCisco
changed the title
|
@xumia, can you check this one. does this have impact to reproducible build? |
Why the sonic image repo as an open source is depended on an external resource with user/password required? Why not upload to the packages public accessible without password required? The command itself should not be impacted, but if the user/password in the command line, then it has impact. |
--user is one such example, i was narrating. Curl options have various other to leverage from. https://man7.org/linux/man-pages/man1/curl.1.html The following page also captures the list of options very well (one very good option is handling files) https://gist.github.com/eneko/dc2d8edd9a4b25c5b0725dd123f98b10
|
|
@VenkatCisco , you means that the options -n, --user are only examples? If adding some common options, then it is good, without any impact on reproducible build. It would be better if you can give an example. Because we have a web proxy service implemented by the Azure Storage, so the command line options may not be the same, in case of some of the options not be supported very well. |
@xumia, thanks for the input. There are relevant commands: HttpClient$new(headers = list(User-Agent= "foobar")) Why use this? This is set by default in a http request, as you can see in the first example above for user agent. Some web APIs require that you set a specific user agent. For example, the GitHub API requires that you include a user agent string in the header of each request that is your username or the name of your application so they can contact you if there is a problem. Ofcourse --user is another option but like you mentioned but one has to know the usage. As such adding curl_option to the slave.mk file should not cause any collateral to the build itself. Please suggest. |
If only add some common options, it will work. The user/password is not good. |
@xumia, Thank you for the input. We wanted a specific request to be used instead of a standard GET via the HTTP. The purpose is to facilitate sonic build with curl options for some common use cases which we see deemed necessary for our internal development. curl was first typed on a command line about 20 years back. Since then several options were added. We add options as we go along and almost every new release of curl has one or a few new options that allow users to modify certain aspects of its operation. With the curl project's rather speedy release chain with a new release shipping every eight weeks, it is almost inevitable that you are at least not always using the latest released version of curl. Sometimes you may even use a curl version that is a few years old. So ensuring the ability to support curl_options in curl command facilitates SONiC engineers with additional capabilities. This helps faster developmental cycle. Ofcourse embedding username/password is harmful. If there is no collateral for reproducible builds, please help approve this PR. |
|
@xumia please let me know there is anything additionally that we need to followup on this PR. Else appreciate if this can be merged soon. |
|
HI @xumia - please review and approve asap, this is needed for Cisco image building. |
#### Why I did it
Provide possibility to specify curl options as the present curl support provided in Azure/sonic does not extend capability for options like --user which some of the cisco artifacts are requiring.
#### How I did it
Add extensions to the slave.mk file to include curl options as follows:
$($*_CURL_OPTIONS)
#### How to verify it
Option 1) use curl -u, and environment variables
it with --user <user:password> curl_options. Ex: --user foo:'bar!'
curl -u ${BASIC_AUTH_HEADER} https://foo.bar
This works to obscure password/credential in a terminal session that someone else might see directly or via screen share.
Option 2) Option 1: use curl -n
If you run linux, create a ~/.netrc file and insert your creds there, and use curl -n.
chmod the file to 400. curl knows how to extract your creds from the file silently. You never have to type creds on the command line again.
If you run Windows, and use curl, you must name the file _netrc . As on *nix, the file should be in your home directory, and should have appropriate permissions.
For Administrative APIs , my .netrc file looks like this:
machine foobar-linux
login foo
password bar
#### Why I did it
Provide possibility to specify curl options as the present curl support provided in Azure/sonic does not extend capability for options like --user which some of the cisco artifacts are requiring.
#### How I did it
Add extensions to the slave.mk file to include curl options as follows:
$($*_CURL_OPTIONS)
#### How to verify it
Option 1) use curl -u, and environment variables
it with --user <user:password> curl_options. Ex: --user foo:'bar!'
curl -u ${BASIC_AUTH_HEADER} https://foo.bar
This works to obscure password/credential in a terminal session that someone else might see directly or via screen share.
Option 2) Option 1: use curl -n
If you run linux, create a ~/.netrc file and insert your creds there, and use curl -n.
chmod the file to 400. curl knows how to extract your creds from the file silently. You never have to type creds on the command line again.
If you run Windows, and use curl, you must name the file _netrc . As on *nix, the file should be in your home directory, and should have appropriate permissions.
For Administrative APIs , my .netrc file looks like this:
machine foobar-linux
login foo
password bar
5 participants
Why I did it
Provide possibility to specify curl options as the present curl support provided in Azure/sonic does not extend capability for options like --user which some of the cisco artifacts are requiring.
How I did it
Add extensions to the slave.mk file to include curl options as follows:
How to verify it
Option 1) use curl -u, and environment variables
it with --user user:password curl_options. Ex: --user foo:'bar!'
curl -u ${BASIC_AUTH_HEADER} https://foo.bar
This works to obscure password/credential in a terminal session that someone else might see directly or via screen share.
Option 2) Option 1: use curl -n
If you run linux, create a ~/.netrc file and insert your creds there, and use curl -n.
chmod the file to 400. curl knows how to extract your creds from the file silently. You never have to type creds on the command line again.
If you run Windows, and use curl, you must name the file _netrc . As on *nix, the file should be in your home directory, and should have appropriate permissions.
For Administrative APIs , my .netrc file looks like this:
machine foobar-linux
login foo
password bar
Which release branch to backport (provide reason below if selected)
Description for the changelog
A picture of a cute animal (not mandatory but encouraged)