[Pan-devel] Re: Buffer overflow in pan when parsing .nzb files

[Duncan]

Greg Lee <address@hidden> posted
address@hidden, excerpted below, on  Sun, 01 Jun 2008 00:34:05
+0000:

> On Wed, 28 May 2008 23:12:22 -0400, Pavel Polischouk wrote:
>> 
>> The solution is to clear() the 'parts' vector on each init(),
> 
> I hope this fix doesn't disturb a rather odd but quite useful
> characteristic of pan: when there's a crash and pan is in the midst of
> doing something (e.g., downloading), when you invoke pan again, it
> continues where it left off, as it didn't even know that something bad
> happened.

It shouldn't, as that's something entirely different.  What's going on 
there is that pan stores the download list (as a newsbin file, as it 
happens), and when it starts up, reads it back in.  It then sees what's 
already been downloaded and continues with what hasn't been yet.

However, it doesn't start exactly where it left off, as what it was 
actually working on at the time (the individual message segment) will 
have not been saved to cache yet, and will therefore be redownloaded to 
combine with other individual messages to make the whole multi-segment 
message.  However, those individual message segments don't take long... a 
few seconds on a multi-megabit connection, maybe a few minutes on an old 
dialup, so it's /almost/ as if it started where it left off, when 
compared to the entire job, probably minutes on a multi-megabit 
connection, hours on dialup.

The patch affects the in-memory handling, not the newsbin file as it'd be 
written to disk, so it shouldn't affect pan's resume at all.  (FWIW, I'm 
already running the patch, but don't do binaries very often so haven't 
tried the resume since rebuilding with the patch.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman