From what I see in src/folderutils.c, the gint folderutils_delete_duplicates function uses server-provided Message-Id header field to deduplicate messages. It does not do a byte-by-byte comparison to confirm a duplicate nor does it use checksums of its own. This could allow the server/sender to craft a special Message-Id that would result in a previously stored message being wrongly moved to thrash (and deleted afterwards). This function looks the same in claws-mail-3.13.0 as well.
Created attachment 416362 [details] Part of the chat with upstream Upstream #claws@freenode says there is nothing wrong with this (!?!?!)
I request for the package to be masked if noone is wiling to fix this. Perhaps this will teach upstream about what is not OK.
Seems package maintainer is not added in this report to begin with, so adding now. Will the deduplication actually delete the existing message and not the newly incoming one?
I do not know, in any case it would be wrong as they are different messages.
(In reply to Fedja Beader from comment #2) > I request for the package to be masked if noone is wiling to fix this. > Perhaps this will teach upstream about what is not OK. I doubt upstream would feel taught by such a measure. Did you file a bug report upstream? Having only some IRC conversation might not be the best approach to put upstream's attention on this issue. To be clear, I see your point and I do agree that this can be dangerous but I won't mask the package because of this. We should rather make this public and perhaps get some CVE ID for this in order to force some reaction from upstream. The more public pressure the better.
(In reply to Lars Wendler (Polynomial-C) from comment #5) > (In reply to Fedja Beader from comment #2) > > I request for the package to be masked if noone is wiling to fix this. > > Perhaps this will teach upstream about what is not OK. > > I doubt upstream would feel taught by such a measure. > Did you file a bug report upstream? Having only some IRC conversation might > not be the best approach to put upstream's attention on this issue. > > To be clear, I see your point and I do agree that this can be dangerous but > I won't mask the package because of this. We should rather make this public > and perhaps get some CVE ID for this in order to force some reaction from > upstream. The more public pressure the better. Discussion of CVE might be premature at this point, as I'm not sure if it crosses any security boundry. For the same reason I'm making the report public for discussion. In particular I'd say it makes a different if only new message is rejected vs existing one. What does other MUAs do in similar situations?
Since public, adding project alias
Closing after four years of inactivity with dubious security impact anyway.
