After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 447425 - Evolution should support POP accounts to have their own storage/folder-trees
Evolution should support POP accounts to have their own storage/folder-trees
Status: RESOLVED DUPLICATE of bug 273944
Product: evolution-data-server
Classification: Platform
Component: Mailer
1.12.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
evolution[accounts] evolution[pop]
Depends on:
Blocks:
 
 
Reported: 2007-06-14 07:27 UTC by Philip Van Hoof
Modified: 2012-03-02 13:10 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Philip Van Hoof 2007-06-14 07:27:05 UTC
Transcript from IRC:

Some invalid reads (byref passing of NULL) are also happening. Especially in the POP code and the reason is non-locking also those are exploitable. Although a lot more difficult (you need to get evolution to race). 

If a disconnect happens with the right timing, compared to the LIST command that camel sends pe->engine will become NULL, and that one is used somewhere (which causes a crash). Since it'll be written (valgrind reported this), I think writing to NULL is exploitable. Just very difficult

There are a lot of those in the POP code

A valgrind warning fix (unrelated)
http://tinymail.org/trac/tinymail/changeset/2143 

This one fixes the locking in the POP code: http://tinymail.org/trac/tinymail/changeset/2142

This is another member that needs locking in the POP code: http://tinymail.org/trac/tinymail/changeset/2137

ps. Using svn diff -r rev:rev-1 it should be possible to get these changes as nice patches that can be used to merge upstream camel with these fixes.
Comment 1 Jeffrey Stedfast 2007-06-14 14:16:02 UTC
probably easier to just use a GStaticMutex lock instead of *lock, then you don't have to malloc one.

also, no need to use g_new0() and then g_static_mutex_init(), the init() will set the values correctly. g_new0()'ing there doesn't save the code from anything over the use of g_new()
Comment 2 Srinivasa Ragavan 2007-06-19 04:37:49 UTC
Philip, can you provide a reworked patch as fejj suggested? 
Comment 3 Philip Van Hoof 2007-06-19 06:47:37 UTC
Varadhan is already working on bringing the entire POP3 code of camel-lite into an experimental but comittable status into upstream camel.

More information:

http://mail.gnome.org/archives/evolution-patches/2007-June/msg00006.html
Comment 4 Philip Van Hoof 2007-06-19 07:11:01 UTC
About Comment #1: A non allocated lock would be a global one. In Tinymail at least I've built-in the possibility to have many POP accounts. Their code doesn't need to lock the others (it's a local lock for that instance). Or also: locking the data ... not the code. So although the type's name is misleading here, I'm not so sure that I agree fully with the non-allocated version of GStaticMutex.

On the gnew0 vs. gnew: Yes, true. I usually use allocators that instantly set everything to 0. Mostly to ease debugging. On top of it I also usually yet initialize everything, for code readability.  With nowadays mobile CPUs (and Desktop CPUs too, of course), it doesn't make a lot sense anymore (at least to me) to micro-optimize this.

I don't know what Varadhan is planning, but I'll wait for his work on the POP3 code before reworking patches, to avoid duplication of (trivial) work.
Comment 5 Philip Van Hoof 2007-06-19 09:41:09 UTC
"A non allocated lock would be a global one" : I misunderstood you, sorry. You probably meant a non-pointer in the struct. That, of course, works indeed too.
Comment 6 Jeffrey Stedfast 2007-06-19 16:54:27 UTC
yes, that is what I meant :)
Comment 7 Srinivasa Ragavan 2007-06-19 19:09:40 UTC
Varadhan: Can you share you POP3 plans here? 
Comment 8 Matthew Barnes 2008-03-11 01:00:47 UTC
Bumping version to a stable release.
Comment 9 André Klapper 2008-12-23 13:39:10 UTC
So once again something rotting (in this case because Varadhan never answered)?
Comment 10 Akhil Laddha 2011-02-10 11:53:35 UTC
duplicate of bug 273944 ?
Comment 11 Matthew Barnes 2012-03-02 13:10:33 UTC
Yeah, it's a dupe.

*** This bug has been marked as a duplicate of bug 273944 ***