miyako/4d-plugin-curl-v3

cURL ftp: CURLSSH_AUTH_KEYBOARD not working

joerg-eyring opened this issue · 66 comments

Hi Keisuke,

we need to connect to a SFTP-server that provides "keyboard-interactive" as SSH authentication method. We always get "Authentication failure" with cURL error 67.

Yes, we set $options.SSH_AUTH_TYPES:=1<<3 (CURLSSH_AUTH_KEYBOARD).

What other option do we have set to make a successful connection?

Thanks and regards, Jörg

NB: Connecting with Filezilla works fine, and your "old" cURL-FTP-Plugin worked as well!

as written in the source

//disable these
SSH_AUTH_TYPES &= ~(CURLSSH_AUTH_KEYBOARD|CURLSSH_AUTH_AGENT);  

Hi Keisuke,

thank you. Is there a reason why this is disabled by default? If not, would you please enable this in future builds?

Jörg

it is disabled because it requires implementing libssh2 callback which curl does not have by default.

if you could find public libcurl+libssh2 C code that does the job I could try to integrate.

but I am currently not in a position to do more than that (for free).

it is disabled because it requires implementing libssh2 callback which curl does not have by default.

But why did it work in the "old" cURL-FTP-plugin, which was programmed by you, too? Just wondering. That's what I said above.

which option did you use?

maybe it won't crash.

Hi,

nothing special - it just worked. Please see attached screen shot. It was working correctly with cURL FTP Plugin version 3.9.3.

image

image

thank you. Is there a reason why this is disabled by default? If not, would you please enable this in future builds?

I can't quite remember but I presume it was causing issues, at least in some cases.

as a test, I have allowed CURLSSH_AUTH_AGENT but not CURLSSH_AUTH_KEYBOARD in 4.4.2.

Hi Keisuke,

the "old" cURL-FTP-Plugin was working absolutely fine with CURLSSH_AUTH_KEYBOARD - as you might see in my posted screen shots. Since we migrated to cURL-Plugin (version 4.0 and newer) customers report that they can't connect to that specific SFTP-server anymore. They always get cURL error 67.

So there must be something which was working in cURL-FTP-Plugin (3.9.3) which has been "dropped" in cURL-Plugin (> 4.0) - maybe accidentially.

CURLSSH_AUTH_AGENT doesn't seem to work - that SFTP server only allows CURLSSH_AUTH_KEYBOARD, as you might see in the log:

Hostname in DNS cache was stale, zapped
Trying 149.239.221.118:22...
Connected to ebibkom.deutschepost.de (149.239.221.118) port 22 (#18)
SSH MD5 fingerprint: c06bccbfbeee465bfb0394fd0daa9979
SSH authentication methods available: keyboard-interactive
Authentication failure
Closing connection 18

Regards, Jörg

in that case I can reverse the code and allow keyboard, disallow agent.

you might see in my posted screen shots

I am really bad at reading code in screenshots. sorry about that. text would be nice.

it's done in 4.4.3

maybe accidentally

no accident. it was explicitly disabled in the source code.

Hi Keisuke,

it's very late in Germany (about 5 am in the morning) - I'll get a nap now and test it later.
If success - thanks very much for your effort!

I'll give you a feedback anyway!

Have a nice day (it's 1 pm in Japan I guess ;-))

Regards, Jörg

Hi Keisuke,

thanks for your effort to bring back a functionality into cURL-Plugin which was working before in cURL-FTP-Plugin :-)

On Windows CURLSSH_AUTH_KEYBOARD is working now and I can connect to that specific SFTP-server!
But - sad to say - on macOS the same call crashes. For your convenience, I'll include an extract of the crash log in my post. Hope, this helps! If you need more information, please drop me a note!

Regards, Jörg

==================================================================

Process: 4D [3993]
Path: /Volumes/VOLUME/*/4D v18R4 258676.app/Contents/MacOS/4D
Identifier: com.4d.4d
Version: 18 R4 build 18R4.258676 (18.4.0)
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: 4D [3993]
User ID: 501

Date/Time: 2022-01-23 21:22:34.282 +0100
OS Version: Mac OS X 10.14.6 (18G9323)
Report Version: 12
Anonymous UUID: 00E6AC24-C236-34FF-3A1A-3A4C0BDEB085

Time Awake Since Boot: 180000 seconds

System Integrity Protection: enabled

Crashed Thread: 35 P_2 (id = -7)

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY

Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [3993]

VM Regions Near 0:
-->
__TEXT 00000001088ce000-00000001094f4000 [ 12.1M] r-x/r-x SM=COW /Volumes/VOLUME/*/4D v18R4 258676.app/Contents/MacOS/4D



Thread 35 Crashed:: P_2 (id = -7)
0 libsystem_platform.dylib 0x00007fff590d56f2 _platform_strlen + 18
1 libsystem_c.dylib 0x00007fff58f8fbf6 strdup + 18
2 com.4D.cURL 0x0000000127464fc0 kbd_callback + 40
3 com.4D.cURL 0x00000001274f8d8e userauth_keyboard_interactive + 3070
4 com.4D.cURL 0x00000001274f8138 libssh2_userauth_keyboard_interactive_ex + 56
5 com.4D.cURL 0x00000001274611fd ssh_statemach_act + 2082
6 com.4D.cURL 0x000000012746087f ssh_multi_statemach + 39
7 com.4D.cURL 0x0000000127438c7b multi_runsingle + 1079
8 com.4D.cURL 0x0000000127438746 curl_multi_perform + 129
9 com.4D.cURL 0x0000000127208c06 curl_perform_non_atomic(void*, void*, std::__1::basic_string<unsigned short, std::__1::char_traits, std::__1::allocator >&, C_TEXT&, void*) + 1305
10 com.4D.cURL 0x0000000127203c76 cURL_FTP(PluginBlock*, curl_ftp_command_t) + 5905
11 com.4D.cURL 0x0000000127201583 PluginMain + 403
12 com.4D.cURL 0x000000012720fe20 FourDPackex + 60
13 com.4d.4d 0x0000000108f4eec9 CallUnPack(calcblock*, short, int, char*, char***, long long*, unsigned char, bool) + 316
14 com.4d.4d 0x0000000108f4f082 mycallext(calcblock*, short, char**, short, char**, unsigned char, bool) + 264
15 com.4d.4d 0x0000000108b810a4 do_extfonc(calculLink*, unsigned char const*, champvar_template<256>) + 2984
16 com.4d.4d 0x0000000108b7ebd7 calcul_subexpress(champvar_template<256>
, calculLink*, bool, bool*) + 1359
17 com.4d.4d 0x0000000108b7d7f6 calculLink::Execute(champvar_template<256>) + 4644
18 com.4d.4d 0x0000000108b62206 cct_interpreted(cctLink&) + 3479
19 com.4d.4d 0x0000000108d2c958 VDBLanguageContext_interpreted::DoExecute(calcblock&, VCodeDescriptor
) + 318
20 com.4d.4d 0x0000000108d3ad3e VDBLanguageContext::Execute(VDB4DTableProxy*, VFormContext*, short, int, int, champvar_template<256>, VCodeDescriptor*) + 264
21 com.4d.4d 0x0000000108d3a940 VDBLanguageContext::ExecuteProjectMethod(VMethodInfo const*, int, champvar_template<256>
, VDB4DTableProxy*, VFormContext*, short, int) + 568
22 com.4d.4d 0x0000000108b8040e CallProjectMethod(unsigned char const*, champvar_template<256>, calculLink) + 538
23 com.4d.4d 0x0000000108b7ed7d calcul_subexpress(champvar_template<256>, calculLink, bool, bool*) + 1781
24 com.4d.4d 0x0000000108b7d7f6 calculLink::Execute(champvar_template<256>) + 4644
25 com.4d.4d 0x0000000108b62206 cct_interpreted(cctLink&) + 3479
26 com.4d.4d 0x0000000108d2c958 VDBLanguageContext_interpreted::DoExecute(calcblock&, VCodeDescriptor
) + 318
27 com.4d.4d 0x0000000108d3ad3e VDBLanguageContext::Execute(VDB4DTableProxy*, VFormContext*, short, int, int, champvar_template<256>, VCodeDescriptor*) + 264
28 com.4d.4d 0x0000000108d3a940 VDBLanguageContext::ExecuteProjectMethod(VMethodInfo const*, int, champvar_template<256>
, VDB4DTableProxy*, VFormContext*, short, int) + 568
29 com.4d.4d 0x0000000108cdbf96 std::__1::__function::__func<V4DWorkerMessage::CreateProjectMethodMessage(VMethodInfo const*, VLanguageParameterList&, bool)::$_0, std::__1::allocator<V4DWorkerMessage::CreateProjectMethodMessage(VMethodInfo const*, VLanguageParameterList&, bool)::$_0>, short (VDBLanguageContext*, VFormContext*)>::operator()(VDBLanguageContext*&&, VFormContext*&&) + 56
30 com.4d.4d 0x0000000108cdae25 std::__1::function<short (VDBLanguageContext*, VFormContext*)>::operator()(VDBLanguageContext*, VFormContext*) const + 39
31 com.4d.4d 0x0000000108cdada9 V4DWorkerMessage::_Execute(VDBLanguageContext*, VFormContext*) + 59
32 com.4d.4d 0x0000000108cdb6e3 V4DWorker::Run(V4DTaskConcrete*) + 213
33 com.4d.4d 0x0000000108caefb1 Task4DProc(V4DTaskConcrete*) + 829
34 com.4d.4d 0x00000001091e3f53 V4DTaskManager::_Task4DProc(xbox::VTask*) + 157
35 com.4d.kernel 0x000000010aec636e xbox::VTask::_Run() + 126
36 com.4d.kernel 0x000000010aecb656 xbox::XMacTask_fiber::_ThreadProc(void*) + 70
37 com.4d.kernel 0x000000010af0151d xbox::XMacFiber::ThreadProc(void*) + 141
38 libsystem_pthread.dylib 0x00007fff590e12eb _pthread_body + 126
39 libsystem_pthread.dylib 0x00007fff590e4249 _pthread_start + 66
40 libsystem_pthread.dylib 0x00007fff590e040d thread_start + 13



==================================================================

the log is similar to

curl/curl#6691

Hi Keisuke,

I tried cURL Plugin 4.4.4.
On Windows it still works fine, on macOS after making a call to the plugin the resulting object "$status" is null. It doesn't crash anymore, though.
It seems that no code is executed at all since no log file is created when setting the option "$options.DEBUG"

`
$options:=New object
$options.USERNAME:=$3
$options.PASSWORD:=$4

//===== weitere Optionen =====
$options.SSH_AUTH_TYPES:=1+2+8 //+ CURLSSH_AUTH_KEYBOARD
//=====================

//Die komplette URL zusammensetzen (POSIX style)
$URL:="sftp://"+$1+"/"+$2
$options.URL:=$URL

$status:=cURL_FTP_PrintDir($options;"")
`

what about $version:=cURL_VersionInfo or other commands?

Ups, I didn't check…
There must be an issue with the plugin on macOS - I was using the plugin from the .dmg. Either v18R4 or v19 - binary mode - x86_64.

image

what is your OS version?

I set to min 10.15.

I can lower it if you want. maybe 10.13 ?

Min. macOS 10.14 please - our system requirements are as follows:

image

I lowered to 10.13, now libcurl doesn't load.

10.14 seems to work.

10.14 is OK! Is it online already?

4.4.5 still doesn't load on 10.14.
On 10.15 there's an error from GateKeeper, saying that it can't be loaded because Apple is not able to search for malware…

Bildschirmfoto 2022-01-24 um 15 54 10

SORRY, my fault regarding 10.15! It seems to load now…
Performing tests and will give you feedback!

Still issues on 10.15. Now it doesn't crash anymore, but yields 28 (timeout) when trying to connect to the sftp-Server. No log files are created.
Works perfectly on Windows. Log files are created.

Here's the issue on 10.14:

Bildschirmfoto 2022-01-24 um 16 15 39

Don't worry about 10.14. When a customer is still working with 10.14 he/she should upgrade to at least 10.15.
More important is that it should work like on Windows (no crashes, no timeouts, …)

BTW: I tried "$options.SSH_AUTH_TYPES:=8" only. Result is the same: cURL error 28

information about windows is irrelevant.
plugin code can be compiled for each platform independently.

should I activate CURLSSH_AUTH_AGENT ?

Hmm, not sure. Was it active in the old cURL FTP plugin? There I didn't pass any $options.SSH_AUTH_TYPES and it worked like a charm.

again, what worked in old curl is irrelevant. curl is an external library and the plugin is only a wrapper.

maybe CURLSSH_AUTH_GSSAPI is required on Mac?

Hi Keisuke,

first: many thanks for your efforts!

I'm afraid I can't help you with this question. I'm not very deep in cURL, just writing wrappers for our application so other engineers can use them without having to dig into cURL.

Somehow something has changed between "old" cURL FTP plugin and the current cURL plugin. Either in your code or at least in one of the libs you're using…

I must keep updating the libraries.
especially to support apple silicon.

Sure, I won't blame you for that :-)

Just trying to be of any help that we can figure out why it's not working anymore…

please try 4.4.7.

Hi, just tried 4.4.7 on macOS 10.15 and v18 R6 with either

//$options.SSH_AUTH_TYPES:=0xFFFF //CURLSSH_AUTH_ANY //$options.SSH_AUTH_TYPES:=8 //CURLSSH_AUTH_KEYBOARD //$options.SSH_AUTH_TYPES:=16 //CURLSSH_AUTH_AGENT //$options.SSH_AUTH_TYPES:=24 //CURLSSH_AUTH_KEYBOARD + CURLSSH_AUTH_AGENT

at no avail. The result is always cURL error 28 (timeout).

What else can I do to be of any help? Sorry, I can't give you any credentials for this specific sftp-server. I'm using customer's credentials to connect to this server…

you could try 3.9.5 of curl-FTP.

the code is unchanged, just the library is updated.

https://github.com/miyako/4d-plugin-curl-ftp/releases/tag/3.9.5

if it doesn't work, it mean the plugin is innocent, the library has stopped support of ssh2 keyboard.

the discussion on curl/curl#6695

talks about

configure to not use CURLSSH_AUTH_PASSWORD

as well as

libssh2 bug

should I downgrade ssh2?

Hi Keisuke,

you could try 3.9.5 of curl-FTP.

the code is unchanged, just the library is updated.

https://github.com/miyako/4d-plugin-curl-ftp/releases/tag/3.9.5

if it doesn't work, it mean the plugin is innocent, the library has stopped support of ssh2 keyboard.

we've been using curl-FTP 3.9.3 without any problems so far on 10.14, 10.15 and 11.6.
I tried curl-FTP 3.9.5: No problems too.

Jörg

Hi Keisuke,

downgraded to libssh2-1.9.0

https://github.com/miyako/4d-plugin-curl-v3/releases/tag/4.4.9

tried cURL 4.4.9 on 11.6: "$status:=cURL_FTP_PrintDir($options;"")" seems to work now! Great job!
I'll run more tests tomorrow.

Now the question: Does the downgrade to libssh2-1.9.0 has any impact on future versions of your cURL plugin?

Jörg

Hi Keisuke,

Don't worry about 10.14. When a customer is still working with 10.14 he/she should upgrade to at least 10.15.

sorry, this statement from me was NOT correct! A colleague told me he still needs to develop on 10.14 since he has to maintain some old versions of our app with v17.
And our build system (which performs ftp transfer from/to one of our version servers) also runs 10.14 because our v17 based apps need to be built there as well as our v18 and v19 based apps.
We're still in binary mode so arm_64 isn't relevant at the moment.

Sorry for that inconvenience but I'd really appreciate if you could restore 10.14 compatibility for cURL plugin!

Again, MANY thanks for taking the time and restoring that specific sftp functionality on macOS!!!

Best regards, Jörg

Sorry for that inconvenience but I'd really appreciate if you could restore 10.14 compatibility for cURL plugin!

I don't understand. I never removed "10.14 compatibility". does it not work anymore? since which version?

Now the question: Does the downgrade to libssh2-1.9.0 has any impact on future versions of your cURL plugin?

impossible to answer such question. sorry about that.

we've been using curl-FTP 3.9.3 without any problems so far on 10.14, 10.15 and 11.6. I tried curl-FTP 3.9.5: No problems too.

that is so weird. it means the libssh2 version doesn't matter. yet your test with curl-v3 implies that it does matter

Sorry for that inconvenience but I'd really appreciate if you could restore 10.14 compatibility for cURL plugin!

I don't understand. I never removed "10.14 compatibility". does it not work anymore? since which version?

Above you said that, starting with 4.4.4, you set macOS min to 10.15. And since that, any version up to 4.4.9 doesn't load anymore on 10.14.

image

image

there are 3 factors that dictate the minimum version.

  • MACOSX_DEPLOYMENT_TARGET - I have set this to 10.14 but that simply sets LSMinimumSystemVersion in infor.plist. it doesn't necessarily mean that the plugin will work in older systems.

  • platform SDK - I am using macOS 12 Monterey.

  • the above 2 for each library linked to the plugin

I lowered the deployment target to 10.13 in 4.4.10 but it sounds like the deployment target is not the issue.

if it doesn't work on Mojave that means libcurl must be downgraded. not to 7.75 because of the crash, but to an even older version, to support keyboard without crash.

I don't want to regresss libcurl only to support mojave.

so here is what I will do: I will create a new branch on GitHub (mojave) and add a release to that branch.

https://github.com/miyako/4d-plugin-curl-v3/releases/tag/4.4.11

curl version is 7.75.0, ssh2 is libssh2/1.9.0 and SSH_AUTH_TYPES is by default CURLSSH_AUTH_ANY.

I hope that is the right combination for you.

you will have to test all over again.

Hi Keisuke,

first things first: 4.4.11 loads again on 10.14 Mojave! But it crashes again on macOS 10.14, 10.15, 11.2 with the well known exception mentioned above :-(

I don't know what's the difference to 4.4.9 now (esp. regarding libs), but maybe there's an interference when you lower the deployment target to 10.13/10.14.

Thanks again for your time - in the end all will be good. I think we're quite close ;-)

Thread 34 Crashed:: P_1 (id = -7)
0 libsystem_platform.dylib 0x00007fff590d56f2 _platform_strlen + 18
1 libsystem_c.dylib 0x00007fff58f8fbf6 strdup + 18
2 com.4D.cURL 0x0000000123fc61b0 kbd_callback + 40
3 com.4D.cURL 0x0000000123da9999 libssh2_userauth_keyboard_interactive_ex + 1753
4 com.4D.cURL 0x0000000123fc23ed ssh_statemach_act + 2082
5 com.4D.cURL 0x0000000123fc1a6f ssh_multi_statemach + 39
6 com.4D.cURL 0x0000000123f99e6b multi_runsingle + 1079
7 com.4D.cURL 0x0000000123f99936 curl_multi_perform + 129
8 com.4D.cURL 0x0000000123d5eb29 curl_perform_non_atomic(void*, void*, std::__1::basic_string<unsigned short, std::__1::char_traits, std::__1::allocator >&, C_TEXT&, void*) + 1311
9 com.4D.cURL 0x0000000123d59bc6 cURL_FTP(PluginBlock*, curl_ftp_command_t) + 5982
10 com.4D.cURL 0x0000000123d574a8 PluginMain + 392
11 com.4D.cURL 0x0000000123d65b78 FourDPackex + 60
12 com.4d.4d 0x000000010549aec9 CallUnPack(calcblock*, short, int, char*, char***, long long*, unsigned char, bool) + 316
13 com.4d.4d 0x000000010549b082 mycallext(calcblock*, short, char**, short, char**, unsigned char, bool) + 264
14 com.4d.4d 0x00000001050cd0a4 do_extfonc(calculLink*, unsigned char const*, champvar_template<256>) + 2984
15 com.4d.4d 0x00000001050cabd7 calcul_subexpress(champvar_template<256>
, calculLink*, bool, bool*) + 1359
16 com.4d.4d 0x00000001050c97f6 calculLink::Execute(champvar_template<256>) + 4644
17 com.4d.4d 0x00000001050ae206 cct_interpreted(cctLink&) + 3479
18 com.4d.4d 0x0000000105278958 VDBLanguageContext_interpreted::DoExecute(calcblock&, VCodeDescriptor
) + 318
19 com.4d.4d 0x0000000105286d3e VDBLanguageContext::Execute(VDB4DTableProxy*, VFormContext*, short, int, int, champvar_template<256>, VCodeDescriptor*) + 264
20 com.4d.4d 0x0000000105286940 VDBLanguageContext::ExecuteProjectMethod(VMethodInfo const*, int, champvar_template<256>
, VDB4DTableProxy*, VFormContext*, short, int) + 568
21 com.4d.4d 0x00000001050cc40e CallProjectMethod(unsigned char const*, champvar_template<256>, calculLink) + 538
22 com.4d.4d 0x00000001050cad7d calcul_subexpress(champvar_template<256>, calculLink, bool, bool*) + 1781
23 com.4d.4d 0x00000001050c97f6 calculLink::Execute(champvar_template<256>) + 4644
24 com.4d.4d 0x00000001050ae206 cct_interpreted(cctLink&) + 3479
25 com.4d.4d 0x0000000105278958 VDBLanguageContext_interpreted::DoExecute(calcblock&, VCodeDescriptor
) + 318
26 com.4d.4d 0x0000000105286d3e VDBLanguageContext::Execute(VDB4DTableProxy*, VFormContext*, short, int, int, champvar_template<256>, VCodeDescriptor*) + 264
27 com.4d.4d 0x0000000105286940 VDBLanguageContext::ExecuteProjectMethod(VMethodInfo const*, int, champvar_template<256>
, VDB4DTableProxy*, VFormContext*, short, int) + 568
28 com.4d.4d 0x0000000105227f96 std::__1::__function::__func<V4DWorkerMessage::CreateProjectMethodMessage(VMethodInfo const*, VLanguageParameterList&, bool)::$_0, std::__1::allocator<V4DWorkerMessage::CreateProjectMethodMessage(VMethodInfo const*, VLanguageParameterList&, bool)::$_0>, short (VDBLanguageContext*, VFormContext*)>::operator()(VDBLanguageContext*&&, VFormContext*&&) + 56
29 com.4d.4d 0x0000000105226e25 std::__1::function<short (VDBLanguageContext*, VFormContext*)>::operator()(VDBLanguageContext*, VFormContext*) const + 39
30 com.4d.4d 0x0000000105226da9 V4DWorkerMessage::_Execute(VDBLanguageContext*, VFormContext*) + 59
31 com.4d.4d 0x00000001052276e3 V4DWorker::Run(V4DTaskConcrete*) + 213
32 com.4d.4d 0x00000001051fafb1 Task4DProc(V4DTaskConcrete*) + 829
33 com.4d.4d 0x000000010572ff53 V4DTaskManager::_Task4DProc(xbox::VTask*) + 157
34 com.4d.kernel 0x000000010740636e xbox::VTask::_Run() + 126
35 com.4d.kernel 0x000000010740b656 xbox::XMacTask_fiber::_ThreadProc(void*) + 70
36 com.4d.kernel 0x000000010744151d xbox::XMacFiber::ThreadProc(void*) + 141
37 libsystem_pthread.dylib 0x00007fff590e12eb _pthread_body + 126
38 libsystem_pthread.dylib 0x00007fff590e4249 _pthread_start + 66
39 libsystem_pthread.dylib 0x00007fff590e040d thread_start + 13

Hi Keisuke,

please understand: we absolutely don't want to block further improvements on cURL Plugin, that was the reason for my question above on the impact for you and cURL Plugin when downgrading to libssh2 1.9.0.

We know that 10.14 is outdated and we should refrain from supporting 10.14 ASAP. That'll happen - as planned - in Q3/Q4 2022. BUT as I mentioned above: Some of OUR systems still run 10.14 with the need of performing ftp-transfer as well as some customer systems outside. So forking a branch supporting 10.14 is a very good idea from you and as soon as we're ready for any future improvement of cURL Plugin (running only on 10.15 and above) we'll jump to that version! Many thanks and thanks for your understanding.

The next main release of our app will only support 10.15 and higher - as long as 4D doesn't release other system requirements ;-)

Best regards, Jörg

If it's any help for you: I called cURL_VersionInfo and found a difference regarding cURL version, which is marked in the following screen shots:

Here's 4.4.9 (which was working on 10.15 and above, but didn't load on 10.14, screenshot made on a Intel Mac mini with 10.15.7):

image

Here's 4.4.11 (which loads on 10.14 and above, but crashes on 10.14 and above, screenshot made on a M1 Mac mini with 11.6.2 - 4D is NOT running arm_x64 but Rosetta 2):

image

Jörg

sounds like reverting to libcurl 7.75.0 brings back the crash (which I suppose was the reason for disabling auth_keyboard).

when I do

brew fetch  --bottle-tag=x86_64_mojave curl
brew fetch  --bottle-tag=mojave curl

homebrew downloads the source (no bottle).

I guess I have to charge my old mojave and compile from source.

memo: running brew install curl on Mojave, I see that

  • brotli--1.0.9.mojave.bottle.tar.gz
  • libunistring-1.0.tar.gz (build from source)
  • libidn2--2.3.2.mojave.bottle.tar.gz
  • libnghttp2--1.46.0.mojave.bottle.tar.gz
  • openssl-1.1.1m.tar.gz (build from source)
  • libssh2--1.10.0.mojave.bottle.tar.gz
  • openldap-2.6.1.tgz
  • rtmpdump--2.4+20151223_1.mojave.bottle.tar.gz
  • zstd-1.5.2.tar.gz (build from source)
  • curl-7.81.0.tar.bz2 (build from source)

this is getting ridiculously hard. on my 2012 mojave, I need to update Xcode (not the latest, 11.3.1 is the ceiling), update homebrew...

That might be easier I suppose…

it is not about settings. the OS and computer and Xcode has changed.

see Mojave branch.

I compiled some libraies on Mojave and Monterey, then combined the files.

it's a real mess.

the feature set is slightly different for Intel vs ARM. rtmp and idn is for Intel only.

https://github.com/miyako/4d-plugin-curl-v3/releases/tag/4.4.12

Hi Keisuke,

first: 4.4.12 loads on 10.14 and higher (short test on macOS)
second: In 4.4.12 CURLSSH_AUTH_KEYBOARD seems to work on 10.14 and higher (short test on macOS)
third: I really believe that: "it's a real mess" :-D
fourth: I can't perform extensive tests for individual SFTP functions or the other protocols (FTP/FTPS) tomorrow (20220127) but I will keep you up to date ASAP.
fifth: Should have been first - but see it as the dessert ;-) We - and probably not only us - really appreciate your effort in making it possible that CURLSSH_AUTH_KEYBOARD is working now in your cURL Plugin again which was working in cURL FTP Plugin before!!! Together both of us spent a lot of time in this issue (probably days) - but I think it's worth it. Your plugin has been improved a lot (even if you say it's barely used in Japan - but this authentication mode is quite common at least in Germany), the communication was constructive and expedient and - as a bonus - we (and again: not only us) got back a lost functionality. Meanwhile both of us might judge this issue as a challenge to be solved! We're both software engineers who say: Nothing is impossible! MANY THANKS for your effort!

And BTW: It seems that we have misunderstood each other again - I saw that you deleted your "angry" posts and (in my thinking) the reason for that is that you accepted my apology. Thanks for that too - personal issues shouldn't appear in a public visible thread. I gonna delete my replies as well ;-)

Conclusion: Whenever you have the opportunity to be in Europe (esp. in Germany/Munich/4D) we should take this as a chance to meet personally - our company is situated very close to Munich - maybe with Thomas whom I know for more than 30 years!

Greetings to Japan and best regards, Jörg

thank you for testing, I have merged the mojave branch to master.

thank you for testing

"de nada" - as spanish speaking people would say - "no problem". Google translator told me that "問題なし" in Japanese would be (nearly) the same as "no problem". Is this correct? :-D :-D
I don't speak Japanese so I can't identify Japanese glyphs ;-)

I have merged the mojave branch to master

Great :-D - as promised - I'll give you an update when all unit tests on our side have been performed!