How to Report a Security Vulnerability

If you think you've found a bug in our software that could be exploited in a way that could harm users or prevent them from using the software (e.g. a remotely triggerable crash):

• DO NOT disclose the information publicly
• DO NOT tell people on our mailing lists
• DO NOT tell people in our IRC channel or our Jabber conference room
• DO send an email to security@…. Emails to this address are sent to a core group of developers who will review the problem and take appropriate action.

When reporting a problem to security@…, please provide this information:

• The version of Pidgin, libpurple, finch, or other package in which the problem was discovered.
• A concise description of the problem, including a summary of why you believe it is security-critical. This might be, for example, "Receipt of an invalid XMPP message containing the tag <foo> causes Pidgin to write data to an invalid memory location."
• Steps to reproduce the problem, if known.
• Any debugging information, including backtraces (see our instructions for obtaining a backtrace), a debug log (the output of pidgin -d), etc.
• Any proof of concept exploits, debugging tools, or other information you have and are willing to divulge.
• The oldest and newest versions of our software affected by the bug to the best of your knowledge. If you don't know, that's fine — we'll try to find out.
• Information on any security reports or vulnerability assessments you may have already made on the issue (preferably not yet public, as mentioned above).
• Any proposed embargo dates, release schedules, etc. you or your organization may have established.

Before informing us of security vulnerabilities, please be aware that we will NOT consider our storage of passwords in plain-text a security issue. We have discussed our position on this at length here and our position on this has not changed. We will, at a future date, be implementing proper integration with password safes such as gnome-keyring, however that support is not yet ready for general consumption. Please do not report this particular issue as a security problem.

Process for Developers

When a developer is made aware of a security vulnerability, follow these steps:

1. Acknowledge receipt the bug report.
   1. If the bug is reported only to security@…, reply to the reporter with an email based on this template:

      Thank you for reporting this problem to us!
      
      We take security problems very seriously.  We will verify that this
      is indeed a problem and release an appropriate fix as soon as
      possible.  In the mean time, please do not disclose the problem to
      the public!  We prefer to work work with distributors of our
      software to allow them to build a fixed package before the problem
      is announced publicly.
      
      Please provide us with the following information:
      [any items from the above list that were missing from the original email]
      

   2. If the bug has already been announced publicly (on devel mailing list, IRC, or Jabber conference), send all information about the bug to security@…
2. Developers on the security email list should determine an appropriate fix and create a patch. Do not share it publicly, but do get it reviewed and tested by other developers.
3. Once an agreed upon patch has been created, an email based on this template should be sent to the packagers mailing list with the diff attached:

   A security vulnerability has been discovered in [Pidgin|Finch|libpurple|other]
   Affected software: [e.x. "Pidgin 2.4.2-2.6.0", or "All clients based on libpurple 2.3.3-2.3.7"]
   Description: [Information about the bug]
   Discovered by: [Name of company or individual]
   Public: ["no" or "yes as of YYYY-MM-DD"]
   Embargo date: [Either "none" or the agreed upon date]
   

4. As the embargo date approaches, a developer should be chosen to commit the fix to their repository. Do not push yet, but go through the normal release process and prepare the ChangeLog, NEWS, etc. This developer should also create (but not upload) tarballs. It's often nice to provide the tarball to packagers prior to the embargo date.
5. On the day of the embargo, push the changes to the repository and update ​http://pidgin.im/news/security/