curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

Setting CURLOPT_SSLENGINE to tpm2tss

From: Winnie Poon via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 11 Aug 2022 17:18:29 +0000

Hi,
I'm trying to set CURLOPT_SSLENGINE to "tpm2tss" and it comes back with:

"A requested feature, protocol or option was not found built-in in this libcurl due to a build-time decision."

May i get some pointers how to build libcurl to support this on ubuntu?

Many thanks! 🙏

Regards,
Winnie

________________________________
From: curl-library <curl-library-bounces_at_lists.haxx.se> on behalf of Timothe Litt via curl-library <curl-library_at_lists.haxx.se>
Sent: August 11, 2022 9:38 AM
To: curl-library_at_lists.haxx.se <curl-library_at_lists.haxx.se>
Cc: Timothe Litt <litt_at_acm.org>
Subject: Re: [Discussion] Have curl honor OpenSSH configurations


On 11-Aug-22 10:23, Randall via curl-library wrote:

Was https://github.com/curl/curl/issues/9285

Originally opened by Ben Voris. The request was to have curl support OpenSSH
config specifications. I am opening a discussion on this subject from the
above case. The ask is whether it would make sense to have an option to
allow curl to honor ~/.ssh/config while attempting to connect?

Ben Voris has a significant usability point in the case, including: " I had
hoped that because curl libssh and libssh uses OpenSSH, it would honor the
config file and so allow curl to behave like OpenSSH clients."

Many software projects other than OpenSSH honor ~/.ssh/config. An option in
curl like --use-ssh-config might be something of value even if not the
default.

Regards,
Randall

--
Brief whoami: NonStop&UNIX developer since approximately
UNIX(421664400)
NonStop(211288444200000000)
-- In real life, I talk too much.





This seems like the wrong way to approach the original request (stated on github) for several reasons.

Reading other commands' config files creates unmanaged dependencies on those projects - formats, options, and/or defaults may or may not be stable. Which commands deserve this treatment is also unbounded - should curl read ~/.ftp? .mx? .freepopsd? .firefox? .gopher? .tftp? .telnet? ... Besides reading the config files in ~, what about /etc/sysconfig (or /etc/default)? And the commands that scan a .d directory for additional config files? Really, this gets out of hand really, really fast.

It seems more reasonable to have a --default-port option, then put it in ~/.curlrc or use --config. E.g.

curl --config $(HOST).curl.ssh.cfg

where example.net.curl.ssh.cfg might contain

default-port 65534

(and any other useful options - perhaps proxy to use, --compressed-ssh, etc).

Or simply (with no change required to curl)

url = "sftp://someuser_at_example.net/file.ext"<mailto:sftp://someuser_at_example.net/file.ext>

Or have the makefile extract the port number from your HOST variable when generating the ssh command. Or have the makefile generate a suitable --config as a temporary file.

Or (more generally useful) extend the curl config file syntax to have per-host options, e.g. perhaps

[altport.example.net]

default-port 65534

[otherport.example.net]

default-port 43556

[*.example.net]

compressed-ssh

There are other reasonable solutions, but reading other commands config files isn't one of them.

Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.


-- 
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html
Received on 2022-08-11