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

[edgar . soldin]

Sorry to be persistent on it ... finally it is your decision.

Just to be clear. Because at some point in time ncftp 3.2.0 segfaulted, 
this gives a hint that it was badly programmed and every data from it 
might get corrupted without somebody noticing it?
Again mine is also 3.2.0 so why is it not banned? Ok I know that 
everything is fione because I verify every backup. But still. Shouldn't 
it be banned?

..ede

> 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
> >
> >     
>
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Duplicity-talk mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/duplicity-talk
>