GNOME Bugzilla – Bug 537507
port to GMime 2.4.x
Last modified: 2015-04-11 23:58:30 UTC
port to gmime-2.4
Created attachment 112454 [details] [review]
This is a patch to port balsa to gmime-2.4 (which is not yet finalized, but figured I'd get a patch going so people can test balsa out with gmime-2.3.3+)
Obviously not worth applying this patch until gmime-2.4.0 is released ;)
Created attachment 112521 [details] [review]
Thanks for getting this started! I had to make a few addtional changes to get Balsa to build and run with GMime from current svn--apply the attached patch after gmime-2.4.patch. We presumably need some further changes to take advantage of the new capability of handling encrypted signed parts.
agh, looks like I forgot all about the pgp stuff (configure check disabled it because I don't have gpgme installed I guess)
Looks like I also missed use of off_t in data structures, good thing you noticed that ;)
There's one thing I think both of our patches missed: in the gpgme GMimeCipherContext implementation, I changed g_mime_cipher_context_sign() to return -1 on error (same as before) or the GMimeCipherHash id on success (rather than just 0).
Probably wouldn't be too hard to fix (I think gpgme has that info).
if no one else gets around to it before I have time, I'll update the patches to do that (might not be until next week, family stuff this weekend).
Anyways, glad the patch was appreciated :)
Also served as a great initial test for my gmime-port-2-2-to-2-4.sh script for which I found a few missing renames ;-)
Created attachment 112575 [details]
** gmime:ERROR:(gmime-filter-basic.c:215):filter_complete: assertion failed: (nwritten <= len)
Program received signal SIGABRT, Aborted.
0x00110416 in __kernel_vsyscall ()
thanks, I'll take a look.
I believe the issue is that g_mime_encoding_quoted_encode_close, when called with inlen == 0 and *state needs encoding, adds 4 characters to outbuf, but
#define GMIME_QP_ENCODE_LEN(x) ((size_t) (((x) + 1) * 3))
evaluates to 3. I tried
#define GMIME_QP_ENCODE_LEN(x) ((size_t) ((((x) + 1) * 3) + 1))
to allow for the '\n', and it seems to work.
awesome catch, thanks! I've just fixed this in gmime trunk - I'll commit a similar fix to the gmime-2-2 branch as well.
(In reply to comment #3)
> Looks like I also missed use of off_t in data structures, good thing you
> noticed that ;)
Hmmm...I'm sure you would have noticed it, if we hadn't used an evil cast on a GMimeParserHeaderRegexFunc callback :(
We used a function that replaced the "gpointer user_data" with a data pointer, and cast it to GMimeParserHeaderRegexFunc. Needless to say, it also used "off_t offset", but because of the explicit cast, gcc didn't complain about the mismatched argument.
Not to worry, the resulting seg fault got it onto the radar screen! Anyway, it's cleaned up in Balsa's svn trunk, so now the additional patch (id=112521) may fail against svn.
Created attachment 112730 [details] [review]
Ok, this patch includes both the original gmime-2.4.patch and also Peter's gmime-2.4-extras.patch, plus it also includes some fixes to gmime-gpgme-context to get rid of the need for the micalg member variable (no longer needed because g_mime_cipher_context_sign() now returns the hash algo used so that g_mime_multipart_signed_sign() can properly set the micalg parameter itself)
Created attachment 115783 [details] [review]
Additional patch to accommodate GMimeRecipientType enum.
Created attachment 117742 [details] [review]
updated patch, this builds against gmime-2.3.8 which I just released.
I make no claim to "bug free"ness, but it does compile cleanly ;-)
Some GObject ref stuff has changed in gmime-2.3.8 - I did a quick search and fixed the only spots I could find that were affected, but I may have missed some.
basically, g_mime_*_get_*() where the *'s are both subclasses of GObject no longer returns a ref'd object.
Created attachment 118266 [details] [review]
Here's a more extensive patch, for building --with-rubrica and --with-gpgme. It also takes more advantage of GMime's new api.
Note to testers: There are likely more cases where Balsa tests for
InternetAddressList == NULL that should also test for internet_address_list_length == 0, or just assume that InternetAddressList != NULL. I found some, but more probably exist. Watch out for CRITICAL messages!
Created attachment 118268 [details] [review]
patch for GMime 2.3.9
Just saw the update to 2.3.9.
the g_mime_[message,multipart]_foreach() functions have been changed to actually be recursive (altho won't descend into message/rfc822 parts), so you'll likely need to change lbm_mbox_prepare_object() and possibly lbm_try_reassemble_func() too unless I'm reading the patch wrong...
Created attachment 118312 [details] [review]
revised patch for Balsa 2.3.26, GMime 2.3.9
Thanks for the heads-up!
The lbm_try_reassemble_func case seems OK--looking deeper for a wrapped message/partial shouldn't hurt. In lbm_mbox_prepare_object, we can allow g_mime_multipart_foreach to handle a GMimeMultipart tree; firing it up just once at the top of each tree should do it.
Created attachment 124974 [details] [review]
Patch to compile against gmime-2.4.3
I think we should release balsa-2.3.26 this year and merge this patch.
Would that mean requiring gmime-2.4? F10 is still on -2.2.21.
I know, it is a difficult decision to make. This is why I want to make one final release against 2.0 first. Then, the development in svn would be made against 2.4 We could possibly provide own gmime-2.4 packages to users on older distributions if they want to upgrade. Let's move this discussion to balsa-list.
Created attachment 125012 [details] [review]
We could use conditional code to handle both versions, as in the attached patch. It's ugly, and we'd want to simplify it asap, but it could get us through the transition.
Created attachment 126861 [details] [review]
patch for Balsa rev 8057 to GMime-2.4.3
Updated patch for Balsa rev 8057.
Oops--126861 obsoletes 124974.
Created attachment 126870 [details] [review]
Remove conditioning on HAVE_GMIME_2_2_7.
Created attachment 126948 [details] [review]
patch for Balsa rev 8058
Created attachment 127220 [details] [review]
patch against Balsa rev 8064
why don't you use a branch in SVN or a GIT repo for new patches?
I'm assuming that Balsa has been ported to GMime 2.4 (and hopefully 2.6) by now, so this bug can probably be closed.
Yes, looks like it's been at least 3 years, probably more like 6 :)
I'll leave you the pleasure of closing it...
Haha, cool ;-)