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. Commit the agreed upon patch to the private/main repo:
   1. If you don't already have a clone of the the private/main repo, make one (you can clone from a local repo if you like)
      • hg clone ssh://hg.pidgin.im/private/main /path/to/myprivatemain
      • NOTE: If you clone from a local repo, you'll need to edit the .hg/hgrc file and make sure that the default path points to ssh://hg.pidgin.im/private/main to avoid pushing changes to the wrong repo!
   2. Propagate all changes from the pidgin/main repo into private/main
      • cd /path/to/myprivatemain
      • hg pull
      • hg pull https://hg.pidgin.im/pidgin/main
      • hg push
      • NOTE: You may need to merge if there have already been commits to the private repo.
   3. Apply the patch to the correct branch and commit it as usual
   4. Push the changeset to the server.
      • NOTE: it's a great idea to make sure that the default path in your .hg/hgrc points to ssh://hg.pidgin.im/private/main before doing this.
5. Prior to the normal release process, the changes from pidgin/main should be propagated to private/main as mentioned above (merging any heads as necessary). The release can then be performed as normal but out of the private/main repo instead of the normal repo. It's often nice to provide the tarball to packagers prior to the embargo date.
6. On the day of the embargo, push the changes to the pidgin/main repository (hg push ssh://hg.pidgin.im/private/main -r $release_tag), and update ​http://pidgin.im/news/security/

Information for Distributors

Anyone who packages or distributes Pidgin, Finch or libpurple to a large audience is eligible to be on our "packagers" mailing list. This is a private mailing list that we use to pre-announce security vulnerabilities and organize a disclosure date. If you think you should be on this mailing list, please send an email to mark@… and request access.