GNOME Bugzilla – Bug 474000
Use GLib's Base64 API
Last modified: 2013-09-14 16:49:52 UTC
This bug is a piece of bug #376991. I'm breaking things up to try and expedite the simple parts. From bug #376991: - Use the new Base64 API in GLib 2.12 for encoding and decoding passwords in the account passwords file. All of the Base64 stuff at the end of e-passwords.c drops out. I shipped the following patch in Fedora 7.
Created attachment 95020 [details] [review] Proposed patch
I'm piling on to this a bit because I found several other Base64 codec implementations in evolution-data-server. Here's what I changed in addition to the above patch for e-passwords.c: - libsoup's Base64 API is deprecated in favor of GLib's. Change all calls to soup_base64_encode() to g_base64_encode(). Similarly with decode. - Remove the Exchange server's Base64 implementation. - Remove the EVCard Base64 implementation. - Remove the LDIF importer's Base64 decoder implementation. - Camel's Base64 API should be deprecated and I plan to do so after this round of patches are committed. For now, convert all external calls to Camel's Base64 API over to GLib's Base64 API.
Created attachment 95398 [details] [review] Additional patch for evolution-data-server
Created attachment 95399 [details] [review] Proposed patch for evolution
Created attachment 95400 [details] [review] Proposed patch for evolution-exchange
Created attachment 95470 [details] [review] Proposed patch for camel Here's the final patch that deprecates Camel's Base64 API and turns it into thin wrappers for GLib's Base64 API. I also changed Camel to not use the newly deprecated functions internally. Please check my work carefully on this one! CC'ing Philip since I imagine he'll be interested.
Matthew, I have reviewed the patches and it seems fine for me. I liked the deprecation and fallback to g_base* in camel. I haven't compiled /tested it. Please do so and commit to head.
Committed patches to Subversion trunk: Evolution (revision 34325) Evolution-Data-Server (revision 8090) Evolution-Exchange (revision 1480)
This work/bug/patch has been used to synchronized tinymail's camel-lite
The camel patch has an issue : When camel_base64_decode_simple gets "" as data, g_base64_decode will return NULL, the g_assert will be OK (as out_len will be <= 0), so memcpy will be called with NULL as source.
Matthew?
Looking into it. Also double-checking whether these changes are related to the recent GAL authentication breakage.
Created attachment 98735 [details] [review] Additional patch for Camel This patch adds argument guards to camel_base64_decode_simple() so that it fails gracefully on invalid data. Of course nothing in Evolution or E-D-S should still be calling this function...
Okay, I'm fairly certain the GAL authentication issues are unrelated to this.
Camel-lite has been updated with this patch: http://tinymail.org/trac/tinymail/changeset/2932
Commit
Committed to trunk (revision 8188).
Reopening due to a flaw in my error handling logic. See [1] for details. [1] http://bugzilla.redhat.com/show_bug.cgi?id=384741
Created attachment 99152 [details] [review] Additional patch strengthens error handling Patch for the previously mentioned bug. Basically just ensures that 'length' is initialized before calling g_base64_decode(). Fixed across the board.
Philip, you'll want to pick the Camel hunks out of this.
(In reply to comment #19) > Created an attachment (id=99152) [edit] > Additional patch strengthens error handling > > Patch for the previously mentioned bug. Basically just ensures that 'length' > is initialized before calling g_base64_decode(). Fixed across the board. > Just add ChangeLog entry and make all those len gsize and commit to trunk.
...and stable :)
Thanks for the quick review, Milan. Turns out my original Base64 changes are not in the stable branch, so this patch doesn't apply there. My mistake. Committed to trunk (revision 8215).
Committed patch in #19 to camel-lite