Changes between Version 12 and Version 13 of SecurityVulnerabilityProcess


Ignore:
Timestamp:
03/04/13 21:59:23 (6 years ago)
Author:
datallah
Comment:

Update developer process to include private repo usage instructions

Legend:

Unmodified
Added
Removed
Modified
  • SecurityVulnerabilityProcess

    v12 v13  
    3636}}}
    3737   b. If the bug has already been announced publicly (on devel mailing list, IRC, or Jabber conference), send all information about the bug to security@pidgin.im
    38  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.
    39  2. 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:
     38 1. 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.
     39 1. 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:
    4040{{{
    4141A security vulnerability has been discovered in [Pidgin|Finch|libpurple|other]
     
    4646Embargo date: [Either "none" or the agreed upon date]
    4747}}}
    48  2. 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.
    49  2. On the day of the embargo, push the changes to the repository and update http://pidgin.im/news/security/
     48 1. Commit the agreed upon patch to the `private/main` repo:
     49   a. 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)
     50      * `hg clone ssh://hg.pidgin.im/private/main /path/to/myprivatemain`
     51      * '''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!
     52   a. Propagate all changes from the `pidgin/main` repo into `private/main`
     53      * `cd /path/to/myprivatemain`
     54      * `hg pull`
     55      * `hg pull https://hg.pidgin.im/pidgin/main`
     56      * `hg push`
     57      * NOTE: You may need to merge if there have already been commits to the private repo.
     58   a. Apply the patch to the correct branch and commit it as usual
     59   a. Push the changeset to the server.
     60      * '''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.
     61 1. 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.
     62 1. 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/
    5063
    5164= Information for Distributors =
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!