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

[Not Zed <notzed ximian com>]

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.

> 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.

BTW stop changing alloca to g_alloca, its not required.