Re: Problems with remote repository access via sftp

On 07/11/2022 21:58, Martin Michel wrote:
> Hi Denis,

Hi Martin,


[...]

> 
> Gotcha, this worked!  My mistake, I also ran the "normal" curl sftp
> command in insecure mode and I was misleaded by this (it is using the
> same libssh2 version, see later) You wrote about this in your last email
> and it is also on the man page, sorry for the extra round.

no worries

> 
> 
>>> $ curl -V
>>> curl 7.74.0 (x86_64-pc-linux-gnu) libcurl/7.74.0 OpenSSL/1.1.1n
>>> zlib/1.2.11 brotli/1.0.9 libidn2/2.3.0 libpsl/0.21.0
>>> (+libidn2/2.3.0) libssh2/1.9.0 nghttp2/1
>>> .43.0 librtmp/2.3
>>
>> AFAIK, libcurl relies on libssh2 for ssh/sftp stuff. Here this is
>> libssh2/1.9.0, I have an older one so I will upgrade and see.
> 
> In the dar_static you provided, it is also libssh2/1.9.0 ?:
> 
>      $ dar_static -V | grep libssh2
>         Remote repository (libcurl)  : YES (libcurl/7.85.0 OpenSSL/1.1.1n zlib/1.2.11 zstd/1.4.8 libssh2/1.9.0)

yes, you are correct, I was misleaded by the filename of the libssh library.

> 
> 
> Concerning Segmentation fault on Void Linux:
> 
>>> I tested on both with `dar_static`.
>>> On my local machine, I get a segfault both with and without running
>>> with
>>> -afile-auth.
>>
>> OK, I will try to reproduce this segfault under Void Linux.
> 
> Here is the strace tail, maybe it helps?:

the strace does not help much as its very low level and not let you know 
where these system calls were invoked from (dar, libdar, libcurl, libssh 
or other part...) And worse, you can make the segfault occuring in a 
library by providing wrong arguments when calling it... for example the 
following code:

--- 

#include <stdio.h>

int main()
{
     sprintf(0, "Hello world\n");
}
---

This triggers a segfault in the call to sprintf() while obviously the 
mistake is in main()


By the way, I could hit a segfault while remotely reading a dar backup 
using ftp/libcurl (thus, not the same context as yours). Digging into 
the problem with gdb, to my point of view this seems a libcurl problem, 
but from libcurl team this is not... so I focus on bringing more stuff 
to the table for now with libcurl team (maybe the same root cause?) in 
order to understand what causes this segfault to occur 
(dar/libdar/libcurl/libc/...)


> 
> Best regards,
> Martin
> 

Cheers,
Denis