Getting Pidgin 2.10.10 out the door
Mark Doliner
mark at kingant.net
Mon Oct 6 11:42:18 EDT 2014
On Oct 4, 2014 12:59 AM, "Tomasz Wasilczyk" <tomasz at wasilczyk.pl> wrote:
> In my opinion, "gadu gadu issues" are not security
> threats, but it would be helpful if any other dev could
> have his say.
I haven't looked at the issues myself, but I think you were right, we
should only request a CVE for the third one (buffer overflow), not for the
others.
I think you and Ethan were basically saying the same things in the other
email thread. As much as possible, we should try to avoid trusting the
server. There is some gray area here, because obviously there are things
where you MUST trust the server.
Clear-cut example: Pidgin should not crash when parsing incoming data from
the server. Our prpls should be well behaved when they receive unexpected
data, such that they log a warning or an error and return gracefully. If
Pidgin receives invalid data from a server and crashes, we request a CVE
for this (in years past we only requested a CVE if the crashy data was
instigated by another user--now we request a CVE in either case).
Another clear-cut example: Our PRPLs generally trust the server to tell us
our roster. The server could absolutely lie to us and we'd have no way of
knowing. There's not much we can do here. We don't request a CVE for this.
Less clear example: What if a server sends us a huge IM 100 times per
second? Should we attempt to display it? I think ideally we'd perform as
good as possible: keep our UI responsive, avoid consuming tons of memory,
avoid playing the incoming IM sound 100 times per second. Detecting
problems like this is difficult, and I think it's not super critical. We
should try hard to connect to the correct server (use SSL, validate certs,
etc), after that we're really trusting the server to behave. I think we
should usually not request CVEs for these types of issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pidgin.im/cgi-bin/mailman/private/security/attachments/20141006/20bbff3e/attachment.html>
More information about the security
mailing list