Re: [Duplicity-talk] [ ftplicity-Bugs-2684345 ] Traceback with duplicity 0.5.06-2~bpo40+1]

[Kenneth Loafman]

Short answer, yes, sort of.  It won't harm the system, but it may harm
the program, or the data it generates.

A segfault is an errant memory read/write to memory outside the program
itself, i.e. it tries to read/write to a system area, or into another
program.  If this errant read/write is to a legitimate location inside
the program itself, you can get stack or data corruption, which is very
hard to find, and annoying.

This location can change when, for example, the compiler is different or
even when the compile options are different.  Different distro's use
different versions of the compiler, sometimes change the options that
the author used, gen for 32-bit and 64-bit, any number of changes can
move the target address, and move the problem.

If I know that I have a program that may segfault in one environment,
then I know that I have a program that may corrupt data in another
environment.  Its best not to trust to luck in an application that
serves a backup program.

That said, I take back what I wrote earlier (entirely too much blood in
my caffeine stream).  The check should stay in for that particular
version, and it is better to ask the user to upgrade.

...Ken

address@hidden wrote:
> Do I understand correctly that a segfault might compromise the systems
> stability or affect other programs running on the same machine? In that
> case I totally agree with you ...
> 
> ..ede
> -- 
>> Not sure that A was the right choice, but we're past that now.  It's
>> easily removed if you just remove the check in ftpbackend.py, so maybe a
>> patch could be issued to remove the check, or maybe just issue a warning
>> instead.
>>
>> I tend to err towards caution in handling errors.  A segfault may not be
>> generated if the memory modified is not executed, but could produce bad
>> data output instead, so unless I know the version has been fixed, and
>> not just compiled differently, I would not really trust it.
>>
>> ...Ken
>>
>> address@hidden wrote:
>>  
>>> Thanks for this overview ... very interesting in every detail indeed
>>> ....
>>>
>>> Regarding your comments ...
>>>
>>> A) If ncftp 3.2.0 raises an error, but not always, why blocking by
>>> version and not by issuing the segfault or whatever error? E.g. in the
>>> case of the ftplicity user from the bug list... He used
>>> ftplicity/duplicity happily until now the new version refuses to work
>>> with a obviously working ncftp version.
>>>
>>> B) You explained that a version string is compared, so the question on
>>> put with list-files is obsolete :)
>>>
>>> Eventually, I agree totally ... Dogmatic Rules are for people that
>>> refuse development. Usually they don't last long .... Said that, why
>>> force somebody to upgrade, if there is only a chance of an error
>>> occuring but no certainty. This is like trying to keep children from
>>> danger. Impossible ;)
>>>
>>> ... ede
>>>
>>> PS: I really love the phrase of your french teacher :))
>>>
>>>
>>> Kenneth Loafman wrote:
>>>    
>>>> address@hidden wrote:
>>>>  
>>>>      
>>>>>> I have a suspicion there may be differences in the distro's, some
>>>>>> with
>>>>>> bug fixes, some not.
>>>>>>                   
>>>>> How does duplicity detect the faulty version? Or does it detect the
>>>>> fault itself?
>>>>>             
>>>> The fault itself would be a segfault, so no, we don't do that.  It runs
>>>> the ncftp command and looks for the version string.  Simplicity.
>>>>
>>>>  
>>>>      
>>>>> But then, why does the list command issue a ftp put command?
>>>>>             
>>>> You'll have to explain that one.  It should not.
>>>>
>>>>  
>>>>      
>>>>> ..qeustions over questions ..ede
>>>>>             
>>>> Back in the dawn of history, duplicity used ftplib.py for direct access
>>>> to ftp.  This was impossible to maintain because the maintainers of
>>>> ftplib.py preferred standardization over functionality.  They treated
>>>> the RFC's as gospel and anyone who's been around ftp long enough grows
>>>> to know that ftp servers are only 'mostly' standard.  I chose NcFTP
>>>> because I had never had it fail to work on any server I targeted.  I
>>>> chose functionality over standardization.  A note - do a 'strings' on
>>>> NcFTP and you will find where they detect the problem FTP servers and
>>>> this is something any ftp client needs to do.
>>>>
>>>> The 2nd incarnation of the ftp backend used the ncftpget/put/ls
>>>> utilities rather than the ncftp command directly.  After much success
>>>> with pexpect driving ssh, and many problems with various versions of
>>>> the
>>>> ncftp utilities, I decided to drive ncftp directly with pexpect and not
>>>> use the utilities for anything at all.  I made the mistake of thinking
>>>> that if ncftp was so solid, then the utilities would be solid as well.
>>>>
>>>> Thus the 3rd incarnation of the ftp backend.  This one still has some
>>>> issues, I'm sure, but those are being ironed out.  Unless someone can
>>>> prove to me that they have a better functioning ftp server or
>>>> library, I
>>>> think we have finally found the functionality and robustness we need
>>>> going forwards.
>>>>
>>>> I'm getting really tired of fixing bugs against a flaky protocol that
>>>> should have died years ago.  It wastes too much time.  It's one of
>>>> those
>>>> things like French that I don't like to mess with.  As my French
>>>> teacher
>>>> said on the day after it was too late to drop, "Throw away the rules,
>>>> now we're going to learn French.".  FTP is like that.
>>>>
>>>> ...Ken
>>>>
>>>>
>>>>  
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> _______________________________________________
>>>> Duplicity-talk mailing list
>>>> address@hidden
>>>> http://lists.nongnu.org/mailman/listinfo/duplicity-talk
>>>>         
>>>
>>> _______________________________________________
>>> Duplicity-talk mailing list
>>> address@hidden
>>> http://lists.nongnu.org/mailman/listinfo/duplicity-talk
>>>
>>>     
>>
>>
>>  
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Duplicity-talk mailing list
>> address@hidden
>> http://lists.nongnu.org/mailman/listinfo/duplicity-talk
>>   
> 
> 
> 
> _______________________________________________
> Duplicity-talk mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/duplicity-talk
>

signature.asc
Description: OpenPGP digital signature