Re: new gmime/gpg bug

[Jeffrey Stedfast <fejj stampede org>]

On Sun, 2004-07-04 at 18:30 +0200, Albrecht Dreß wrote:
> Am 04.07.04 18:20 schrieb(en) Pawel Salek:
> > I guess I can commit that patch if gmime-2.1.5 does not break anything  
> > else: I trust your judgement!
> 
> To be honest, I currently don't see a reason why this patch should be  
> committed (if it still applies cleanly). It *requires* gmime 2.1.5 or  
> above due to the gmime crypto api changes, but it doesn't improve the  
> situation on the crypto side at all. I don't think it will break anything  
> elsewhere, though, at least if we don't add GMIME_DISABLE_DEPRACTED to the  
> flags.
> 
> If Jeff produces a working gmime rfc 3156 implementation, I will of course  
> be happy to submit a new patch!

Unfortunately, I don't think I can "fix" GMime 2.2 to treat
multipart/signed content streams 100% opaquely without breaking
API/ABI :-\

The brokennes you reported the other day about the boundary changing was
due to a bug in a fix that I did that was meant to minimise the risk of
header reformatting as much as I could for the Content-* headers... it
should help, but there's still no 100% guarentee.

That said, CVS should be no *more* broken than 2.1.3 (or 2.0.x versions)
in any area, if it is - I want to know so I can fix it :-)

as far as the GMIME_DISABLE_DEPRECATED, I don't plan on removing them
from any 2.x release - I mostly just added them to discourage developers
from using those API's for any new code - most of the deprecated
functions were leftovers from the pre-1.0 days when the parser acted
upon in-memory string streams rather than the current concept of
GMimeStream's.

since I saw someone mention g_mime_part_get_content(), let me note that
that particular function is the spawn of the devil because it loses
track of the original content stream, thus making it such that trying to
later verify that part (pgp/mime, etc) is far more likely to fail since
gmime would have to re-encode the content.

- if the content was in quoted-printable, there are multiple ways to qp-
encode the same text stream and so it's likely that the re-encoded
version will not be identical to the original

- even with base64, there may be a different number of blank lines at
the beginning or end of the re-encoded base64 stream


Jeff

-- 
Jeffrey Stedfast <fejj stampede org>