Release Procedure

Step by Step Guide Through CRS release

Preparation

• Update CHANGES file
• Add new contributors to CONTRIBUTORS.md sorted by last name, or username if the real name is unknown (e.g. git shortlog -s v3.0.1..v3.0/dev)
• Update copyright in all the files if there is a new year

 import os
  excluded = ['.git']
  directory = "owasp-modsecurity-crs/"
  # Iterate over over all files in the directory
  for root, dirs, files in os.walk(directory):
      for name in files:
          found = False
          # if our path contains an excluded name mark it as found
          for exclude_term in excluded:
              if root.find(exclude_term) != -1:
                  found = True
          # if we have an excluded path, skip
          if found is True:
              continue
          file_name = os.path.join(root, name)
          with open(file_name, 'r') as fil:
              filedata = fil.read()
S>            filedata = filedata.replace('# Copyright (c) 2006-2017', '# Copyright (c) 2006-2018')
          with open(file_name, 'w') as fil:
              fil.write(filedata)

• Update CRS version in crs-setup.conf.example (tx.crs_setup_version)
• Update CRS version in rules/REQUEST-901-INITIALIZATION.conf (SecComponentSignature)
• Update CRS version in all rules, e.g. ver:'OWASP_CRS/3.0.0'
• Update all copyright for new versions

grep -rl "OWASP ModSecurity Core Rule Set ver\.3\.0\.0" owasp-modsecurity-crs/ | xargs sed -i s@"OWASP ModSecurity Core Rule Set ver\.3\.0\.0"@"OWASP ModSecurity Core Rule Set ver\.3\.0\.2"@g

• Run tests. Make sure that a vanilla request does not trigger any rules due to messup (problem with 3.0.1 release)

Release (RC or final)

• Create a new release draft.
• Tag: Use format v3.2.0-rc1 for a release candidate or v3.2.0 for final; always use three digits.
• Release title: v3.2.0-rc1
• Write: This is the OWASP ModSecurity Core Rule Set version 3.2 RC1
• In case of a RC, enable the 'pre-release' checkbox.
• Press Publish on the release; GitHub will automatically create .tar.gz and .zip files of the source and add it to the release.

New branch

• Create a new branch v3.2/master forked off v3.2/dev. Bug fixes will go here.
• Create a new branch v3.3/dev forked off v3.2/dev. New development will continue here.
• In case of a new branch (e.g. 3.3/dev), update all util/docker/Dockerfile* files to use the new branch.
• In case of a new branch (e.g. 3.3/dev), also add the new branch to .travis.yml.
• Send request to Trustwave to make the new branch the GitHub default branch.

Communication

• Finish release message
• Post to OWASP slack channel
• Send release message to crs mailinglist - [email protected]
• Crosspost release message to modsec mailinglist - [email protected]
• Update CRS homepage with new version and release date
• Update CRS installation page (versions, zip, tar.gz, SHA sums, CHANGES, INSTALL, KNOWN_BUGS)
• Publish blog post on CRS site
• Announce blog post on twitter with CoreRuleSet twitter account
• Ask Trustwave to tweet about release with ModSecurity twitter account
• Make sure release is mentioned in monthly OWASP connector