Re: Problems with remote repository access via sftp

Hi,

some news about this problem.

looking at the stack at the time of the segfault, we saw this occurring 
"below" libcurl in getaddrinfo() call (part of glibc). There is a bug
in that part that could explain this problem (affecting only statically 
linked binaries in multi-threaded context).

Beside this possible root cause, I also met a bug due to translated 
messages in dar/libdar (which relies on the gettext library/software).

You can disable it by un-setting the LANG environment variable before 
running dar

unset LANG
./dar_static ...

I could not find any error in the translated message regarding the "%" 
masks where a wrongly substituted or extra format in a translated string 
for example, could pretty lead to a memory corruption. I will give a 
deeper view at this next week-end.

Anyway, if un-setting the LANG variable fixes the issue, this is the 
second bug that you hit (gettext), else this is probably the first 
(getaddrinfo) one [1] you hit and upgrading glibc that include a fix for 
that and recompiling dar_static against it will I hope fix the issue, if 
the cause is not yet else.

I still have to test under Void Linux, will do that soon also

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=10652

Cheers,
Denis


On 09/11/2022 23:15, Denis Corbin wrote:
> 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
>