Re: [Evolution-hackers] known bugs in gpg support?

[Jeffrey Stedfast <fejj ximian com>]

On Wed, 2003-02-26 at 23:52, Not Zed wrote:
> On Thu, 2003-02-27 at 10:16, Jeffrey Stedfast wrote:
> > did some digging and it seems that my first impression of the problem
> > was *almost right*.  I had been thinking that we were passing the last
> > \n before the boundary (which really belongs to the boundary, so we
> > should not be doing that) but it actually turns out the canon filter
> > code would always just add a \r\n to the end of the stream even if the
> > higher-level code did provided a stream that did not end with \n
> > 
> > however, that was not the only problem... I discovered in my testing
> > that the code was in fact dropping the entire last line when sending it
> > to gpg because the last line did not end with a \n, and so it was saved
> > in the backup buffer of the canon filter waiting for a
> > filter_complete().
> > 
> > the filter_complete(), however, would never come because:
> > 1) all of the data had been read from the src stream
> > 2) filter_stream->priv->filteredlen == 0, meaning that the filter_stream
> > did not have any data in its own buffer.
> 
> > to fix this, I just fixed camel-stream-filter.c:do_eos() to check for
> > buffered data in any of the filters in the chain. if there was data
> > there, then eos == FALSE.
> 
> I'm not sure this fix is correct, but it might be, i'll verify.
> 
> Another simpler way might be to do
> 
> eos = filteredlen == 0
> 	&& complete has been called
> 
>  and set the 'complete called' when its been called, since filters MUST
> flush everything when that is called.

that'd be fine... 

> 
> > attached are patches for 1.2 and 1.3 - it seems when I backported a
> > patch from 1.3 to 1.2 (or vise versa?) and extra blank line made it in
> > there and so the 1.3 patch will not apply cleanly to the 1-2-branch, so
> > I made 2 patches. both are identical except for that minor difference.
> > 
> > Michael (NotZed): The only change I'm not 100% sure about is the removal
> > of the code in camel-mime-filter-canon.c:filter_complete() that added
> > \r\n to the stream. As far as I can tell, it should not be needed since
> > filter_filter() works on a line-by-line basis and so any remaining
> > buffered data *should* be an incomplete line and thus never contain a
> > \n, and so I *think* my removal of that code is fine.
> 
> Its a fallback for repairing truncated data ... its there for a reason. 
> It might not be the right approach for canonicalising pgp data though.
> 
> Just #ifdef it out for now.  If somethign else needs it to work like
> that it can be done as a different flag, or if not, removed later.

ah, okay... will do.

Jeff

-- 
Jeffrey Stedfast
Evolution Hacker - Ximian, Inc.
fejj ximian com  - www.ximian.com