Software Patches

The CAcert application software running on the webdb server and signing server requires corrections from time to time, as a result of the continuous software development and assessment process conducted by the Software Assessment project team.

This page describes the steps to be taken by the CAcert critical system administrator team on receiving e-mail from the Software Assessment team with detailed patch instructions.

Process for webdb server

  1. Check that e-mail with patch request was sent and signed by one of the nominated and approved software assessors (list kept under ).

  2. Check documentation of the patch request under Requirements are:

    1. the patch must have been reviewed by at least two software assessors
    2. the patch must have been tested by at least two software testers
  3. Transfer the patch with scp to /tmp on the production server.
  4. Evaluate risk of applying the patch to the live system. In case of doubt, shut down the webserver temporarily with sudo service apache2 stop, and do not forget to start it again after completion of the patch process with sudo service apache2 start.

  5. Apply patch to the production server like this:
      cd /home/cacert/www
      sudo patch -p1 --ignore-whitespace </tmp/patch-script.diff
    and verify that the patch applies cleanly. In case of patch failure(s), back out the patch and report the failure in full detail to the Sofftware Assessment Team for review. Do not continue the process below.
  6. Commit the software application update to CVS:
      cd /home/cacert/www
      sudo cvs add "any new files added by the patch"
      sudo cvs commit "any directories containing patched files"

    cvs commit will prompt for a commit message (within pico); the recommended text is a reference to the bug # patched and the short description shown for the bug # at, for example:

      Fix for
      "If I delete Domains, no Servercerts for this domains are
      listed, even not the revoked".

    cvs commit will automatically send checkin notification messages (one per directory) to the alias; these notification messages should be used in step 10 below.

  7. Create a new source tar ball of the current source code:
      cd /home/cacert/www/tmp
      sudo make
  8. Push any new message strings to the translation server for translation:
      cd /home/cacert/www/locale
      make upload

    Note that the correct execution of this step requires a specific setting in the critical admin's ~/.ssh/config file on the webdb server:

      Host hopper
      ForwardAgent yes
      Host translations
      User critical
      ProxyCommand ssh /usr/bin/netcat %h %p
      User critical
      ProxyCommand ssh /usr/bin/netcat %h %p
  9. Pull any new translations from the translation server into the production server and enable them:
      cd /home/cacert/www/locale
      sudo service apache2 reload
  10. Send a notification of the patch installation to the cacert-systemlog mailing list, i.e. send signed e-mail to which contains a summary text, a pointer to the new source tar ball and the full cvs commit message(s) (forwarded as attachment(s)). Example:

      Fix for
      "If I delete Domains, no Servercerts for this domains are
      listed, even not the revoked".
      In conjunction with the attached CVS changes a new tarball has been
      made available incorporating all updates. The new tarball is available
    followed by the forwarded cvs commit e-mails generated in step 6 above.
  11. Update the bug entry on to "Solved?" with a message stating when the patch was installed on the production server, and including a reference to the e-mail sent out in step 10, which can be found in the cacert-systemlog archives at

  12. Reply to the Software Assessment team's e-mail which requested this patch by stating the date on which the patch has been installed and forward the e-mail sent out in step 10 as attachment.
  13. Deploying the patches to the CAcert test servers is not part of the critical admin job, but mirroring the new source tar ball to the test servers is. This can be done with the script found in SVN at Please note that this script should be run on the admin's own trusted home machine!

Modified process for signing server

The above procedure only applies to patches of the webdb server. For patches involving the signer, a modified process is required, involving a visit to BIT by two critical system administrators plus one secure-u Access Engineer.

Steps 1, 2, 10, 11 and 12 still apply, except that there is no cvs commit message available in this case.

Steps 8 and 9 are not applicable.

Step 5, 6 and 7 may be applicable (in case the affected source code is kept in the CVS on the webdb), but it can also be a change to stuff kept in at

Step 3 and 4 depend on the situation, but typically the new code or patch will be brought on a USB stick which can be mounted on the signing server during the patch process. In some cases it may be necessary to shut down the signing process temporarily, with service commmodule stop.

SystemAdministration/Procedures/SoftwarePatches (last edited 2013-11-01 15:12:22 by WytzevanderRaay)