= 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 https://wiki.cacert.org/Software/Assessment/Team ).
 1. Check documentation of the patch request under https://bugs.cacert.org/. Requirements are:
  a. the patch must have been reviewed by at least two software assessors
  a. the patch must have been tested by at least two software testers
 1. Transfer the patch with scp to /tmp on the production server.
 1. 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''.
 1. 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.
 1. 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 bugs.cacert.org, for example:
 {{{
  Fix for https://bugs.cacert.org/view.php?id=1141
  "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 critical-admin@cacert.org alias; these notification messages should be used in step 10 below.
 1. Create a new source tar ball of the current source code:
 {{{
  cd /home/cacert/www/tmp
  sudo make
 }}}
 
 1. 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
  Hostname hopper.intra.cacert.org
  ForwardAgent yes

  Host translations
  Hostname translations.intra.cacert.org
  User critical
  ProxyCommand ssh hopper.intra.cacert.org /usr/bin/netcat %h %p

  Host translations.cacert.org
  Hostname translations.intra.cacert.org
  User critical
  ProxyCommand ssh hopper.intra.cacert.org /usr/bin/netcat %h %p
 }}}
 1. Pull any new translations from the translation server into the production server and enable them:
 {{{
  cd /home/cacert/www/locale
  make
  sudo service apache2 reload
 }}}
 1. Send a notification of the patch installation to the cacert-systemlog mailing list, i.e. send '''signed''' e-mail to cacert-systemlog@lists.cacert.org 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 https://bugs.cacert.org/view.php?id=1141
  "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
  through http://www.cacert.org/src-lic.php
 }}}
 followed by the forwarded cvs commit e-mails generated in step 6 above.
 1. Update the bug entry on https://bugs.cacert.org 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 https://lists.cacert.org/wws/arc/cacert-systemlog/
 1. 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.
 1. 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 https://svn.cacert.org/CAcert/SystemAdministration/rsync-tarballs. 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 svn.cacert.org at
    http://svn.cacert.org/CAcert/SystemAdministration/signer/

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''.
----

 . CategorySystems
 . CategoryProcedures