security review and patches for libpurple

[Chris Palmer]

Yes, thank you John!

Are there any particular areas of the code that you would like us to focus on?


On Jul 1, 2011, at 11:23 AM, Dan Auerbach wrote:

> Hi John,
> 
> Thanks for getting back to us so quickly. Please let us know if you have follow-up questions about this initial set of bugs/patches, and we will be in touch about future ones, keeping in mind to raise issues though the process outlined below.
> 
> Best,
> Dan
> 
> On 06/29/2011 06:31 PM, John Bailey wrote:
>> On 06/29/2011 08:21 PM, Dan Auerbach wrote:
>>> We at the Electronic Frontier Foundation are dedicated to ensuring people have
>>> the ability to engage in private and secure communication. As we believe the
>>> open source suite of tools based on libpurple can and should be used for this
>>> purpose (most securely via the Off-The-Record Messaging protocol), we think it
>>> is vital to ensure that the software is secure and safe from attack. As such, we
>>> hope to begin to partner with you in doing an audit of security vulnerabilities
>>> surrounding libpurple and dependent libraries, and providing patches. In this
>>> introductory email, we have included some simple initial changes that we believe
>>> are in keeping with best practices, as well as some changes that close potential
>>> vulnerabilities. In the coming couple of months, we hope to do a thorough audit,
>>> and plan to stay communicative about vulnerabilities, offering patches where we
>>> are able to do so. Our goal is to work with you, so please let us know the
>>> preferred way to interface with your team for disclosing and patching these
>>> vulnerabilities beyond the security vulnerability disclosure page.
>> Hi, Dan, Chris,
>> 
>> First of all, we'd like to thank you for the effort you've shown thus far.  We
>> always welcome constructive input on how to make our code safer and more secure.
>>  We welcome such input even more when patches are provided.
>> 
>> For security-related topics we generally prefer to contain discussion to the
>> security mailing list until we've reached a point where we can discuss with our
>> packagers and coordinate a scheduled release, at which point we'll move the
>> discussion to our (private) packagers mailing list.  We make it a point, when
>> possible and practical, not to discuss security issues in public fora such as
>> the devel or support mailing lists or Trac until a pached release has been made
>> available.  In short, you should continue to contact us via this security
>> mailing list.
>> 
>>> Attached is a document outlining and summarizing suggested changes, along with
>>> the patches we provide. I have also attached a tar.bz2 of diffs, generated using
>>> "mtn diff", and a build log. Please see the document for the information
>>> requested in http://developer.pidgin.im/wiki/SecurityVulnerabilityProcess.
>> Again, thank you for providing these.  And an even bigger thank you for
>> providing mtn diffs instead of just using a recent tarball!  We will review your
>> patches as soon as we can.  Once we have reviewed them, we will likely want to
>> coordinate a release which includes them.
>> 
>> I've quickly reviewed your document and would like to provide two comments on
>> items I saw in it as points of information:
>>   * We don't currently use Visual Studio to build Pidgin releases for the
>> Windows platform, nor do we plan to in the foreseeable future.  We instead use
>> the MinGW toolkit, often in a cross-compile environment.  This is why we have
>> Makefile.mingw files throughout our source tree.  Hopefully the relevant gcc
>> options will apply equally well to the MinGW toolkit's gcc.
>>   * The Zephyr and Sametime plugins are currently completely maintainerless and
>> rely entirely on contributed patches from interested users.  We don't really
>> have any way to test these plugins other than compiling, and we probably won't
>> be able to explain a whole lot about them if you find you need further
>> information.  Please don't take that as discouragement, though!
> 
> Both of these are good to know---thanks!
> 
>>> We would also like to thank Jake Appelbaum (cc'ed) for this help with the review
>>> process; we hope to collaborate with him for future steps of this review.
>> We look forward to future discussion and review!
>> 
>> Thanks again,
>> John
>> 
> 

-- 
Chris Palmer
Technology Director, Electronic Frontier Foundation
https://www.eff.org/code