ClamavUpdates

Differences between revisions 3 and 10 (spanning 7 versions)
Revision 3 as of 2009-05-02 02:56:15
Size: 3733
Editor: static-72-81-252-22
Comment:
Revision 10 as of 2009-07-06 21:10:57
Size: 6763
Editor: minbar
Comment: compulsive spellchecking
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
This document describes the policy for major updates to Clamav packages in a stable supported distro, including LTS. Micro-release updates are already covered under StableReleaseUpdates/MicroReleaseExceptions. Major updates require a different process because they generally involve interface changes in libclamav and require multiple packages to be tested and updated together to maintain functionality. This document describes the policy for major updates to Clamav packages in a stable supported distro, including LTS. Micro-release updates (eg 0.94.1 to 0.94.2) are already covered under StableReleaseUpdates/MicroReleaseExceptions. Major updates (eg 0.94.2 to 0.95) require a different process because they generally involve interface changes in libclamav and require multiple packages to be tested and updated together to maintain functionality.  Upstream considers 0.8X to 0.90 a major update, 0.9X to 0.9Y a minor update, and 0.94.X to 0.94.Y a micro version update.
Line 7: Line 7:
Packages brought into an existing release must be brought in with a minimal difference from the development/current release (the process should branch from the earliest release to carry the current upstream release which may be the current release and may be the development release). They will go through some functional and integration testing first in the ubuntu-clamav PPA, then exposed to a broader audience in the *-backports repositories, and then finally delivered as updates to all users of each particular release. The process for this is described in [[MOTU/Clamav/]]. QA of the update has three major components:

1. Qualification and test of the clamav package.

2. Qualification and test of the integration of the new clamav with its reverse dependencies.

3. Qualification and test of the installability and functionality of clamav and its reverse dependencies on the target release

Packages brought into an existing release must be brought in with a minimal difference from the development/current release (the process should branch from the earliest release to carry the current upstream release which may be the current release and may be the development release). They will go through some functional and integration testing first in the ubuntu-clamav PPA, then exposed to a broader audience in the *-backports repositories, and then finally delivered as updates to all users of each particular release.

Clamav package QA:

The clamav package itself includes a test suite that is enabled by default and make check is integrated into debian/rules, so if the package builds, it has passed its test suite (Dapper is an exception to this as the version of check in Dapper is too old). Some tests are skipped due to build-depends not being included (such as electric-fence). The tests that are reliable are included and activated. Tests that are not activated by default have been found to only find faults in the underlying system and not in the clamav package itself (valgrind and electric-fence).

Once the package is built, then it should be tested with the [[https://code.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master |Security Team's QA regression test for clamav]] (see scripts/README for details on how to test).

These two steps should ensure the package is functional.

Integration and testing with the reverse dependencies and the target release are done together. The process for this is described in [[MOTU/Clamav/]].
Line 15: Line 33:
* Generally major version updates are not permitted post-release. Because anti-virus capability degrades over time due to new threats, in the case of clamav not updating only provides an illusion of stability. Updates are essential to maintain an even level of capability.  * Generally major version updates are not permitted post-release. Because anti-virus capability degrades over time due to new threats, in the case of clamav not updating only provides an illusion of stability. Updates are essential to maintain an even level of capability.
Line 21: Line 39:
This process has been experimentally executed from beginning to end twice. Dapper, Feisty, and Gutsy were updated to Clamav 0.92.2 (which is what Hardy was released with) and Dapper and Hardy are just about to be updated to 0.94.2 (which is what Intrepid was released with). So far, although labor intensive and taking longer to complete than would be ideal, this process has produced good results. When Dapper, Feisty, and Gutsy were updated only two bugs were filed (both Dapper). In one case a user needed to manually adjust a configuration file. In the other case the user had depended on a function provided by python-clamav that had been dropped in the newer release for his own private scanning tool. We were able to quickly package python-pyclamd and provide a suitable alternative. This process has been experimentally executed from beginning to end twice. Dapper, Feisty, and Gutsy were updated to Clamav 0.92.2 (which is what Hardy was released with) and Dapper and Hardy were updated to 0.94.2 (which is what Intrepid was released with). The initial Dapper update was a major version update (0.88 to 0.92). The other updates were all minor version updates within the 0.9X series. So far, although labor intensive and taking longer to complete than would be ideal, this process has produced good results. When Dapper, Feisty, and Gutsy were updated only two bugs were filed (both Dapper). In one case a user needed to manually adjust a configuration file. In the other case the user had depended on a function provided by python-clamav that had been dropped in the newer release for his own private scanning tool. We were able to quickly package python-pyclamd and provide a suitable alternative.  For the Dapper/Hardy update to 0.94.2, the only issue known so far was one rdepend misbuilt against the old clamav and that was quickly corrected.
Line 23: Line 41:
This process have provided a good balance between cutting edge and stable, integrated capability and seems suitable to extend to Intrepid and Jaunty where clamav is in Main. This does, however, involve a lot of work to build a lot of packages. On this last cycle, the following were needed:

For [[https://bugs.launchpad.net/ubuntu/+source/clamav/+bug/368785 | Dapper]]:

clamav 0.94.dfsg.2-1ubuntu0.3~dapper1

avscan 3.2.2-openssl-1build1~dapper1

clamassassin 1.2.4-1~dapper1

clamcour 0.2.2-1.2build1~dapper2

dansguardian 2.9.9.7-2~dapper1

gurlchecker 0.10.2-2ubuntu1~dapper1

havp 0.89-2ubuntu1~dapper1

klamav 0.44-3~dapper1

python-clamav 0.4.1-1build2~dapper1

python-pyclamd 0.1.1-0ubuntu1~dapper1

php-clamavlib 0.12a-4~dapper2

sylpheed-claws-gtk-clamav 1.0.5-5.1ubuntu0.1~dapper2

sylpheed-claws-gtk2-clamav 2.6.0-1.1ubuntu1.1~dapper2

For [[https://bugs.launchpad.net/ubuntu/+source/clamav/+bug/368613 | Hardy]]:

clamav 0.94.dfsg.2-1ubuntu0.3~hardy3

avscan 3.2.2-openssl-1build1+hardy1

dansguardian 2.9.9.7-2~hardy1

gurlchecker 0.10.2-2ubuntu1~hardy1

havp 0.89-2ubuntu1~hardy1

klamav 0.44-3ubuntu2~hardy1

python-clamav 0.4.1-1build2~hardy1

php-clamavlib 0.13-1.2ubuntu1~hardy1

This process has provided a good balance between cutting-edge and stable, integrated capability and seems suitable to extend to Intrepid and Jaunty where clamav is in Main. Up-to-date clamav with an integrated, tested package set is a feature unique to Ubuntu Server that is another way to positively differentiate Ubuntu Server from its competitors.

This document describes the policy for major updates to Clamav packages in a stable supported distro, including LTS. Micro-release updates (eg 0.94.1 to 0.94.2) are already covered under StableReleaseUpdates/MicroReleaseExceptions. Major updates (eg 0.94.2 to 0.95) require a different process because they generally involve interface changes in libclamav and require multiple packages to be tested and updated together to maintain functionality. Upstream considers 0.8X to 0.90 a major update, 0.9X to 0.9Y a minor update, and 0.94.X to 0.94.Y a micro version update.

Clamav is the premier FOSS anti-virus scanning engine. By its nature, the performance requirements for clamav evolve rapidly as new threats are discovered, so unlike normal packages, stabilizing the version and not changing it does not provide performance stability, it causes performance degradation. Updates to anti-virus signatures are downloaded regularly using freshclam, but often older scanning engines cannot use the signatures and detect newer threats. In order to provide continuing, first class performance and pace the threat, newer versions need to be integrated into existing Ubuntu releases.

QA Process

QA of the update has three major components:

1. Qualification and test of the clamav package.

2. Qualification and test of the integration of the new clamav with its reverse dependencies.

3. Qualification and test of the installability and functionality of clamav and its reverse dependencies on the target release

Packages brought into an existing release must be brought in with a minimal difference from the development/current release (the process should branch from the earliest release to carry the current upstream release which may be the current release and may be the development release). They will go through some functional and integration testing first in the ubuntu-clamav PPA, then exposed to a broader audience in the *-backports repositories, and then finally delivered as updates to all users of each particular release.

Clamav package QA:

The clamav package itself includes a test suite that is enabled by default and make check is integrated into debian/rules, so if the package builds, it has passed its test suite (Dapper is an exception to this as the version of check in Dapper is too old). Some tests are skipped due to build-depends not being included (such as electric-fence). The tests that are reliable are included and activated. Tests that are not activated by default have been found to only find faults in the underlying system and not in the clamav package itself (valgrind and electric-fence).

Once the package is built, then it should be tested with the Security Team's QA regression test for clamav (see scripts/README for details on how to test).

These two steps should ensure the package is functional.

Integration and testing with the reverse dependencies and the target release are done together. The process for this is described in MOTU/Clamav/.

Deviations

This process deviates in a few important respects from standard Ubuntu process and should be approved by the Ubuntu Tech Board.

  • Generally library packages are not approved for backporting. In order to make it reasonable to make an exception to this rule, all packages that use libclamav are tested and backported in tandem (if needed) .
  • Generally major version updates are not permitted post-release. Because anti-virus capability degrades over time due to new threats, in the case of clamav not updating only provides an illusion of stability. Updates are essential to maintain an even level of capability.
  • Because the libclamav design is rapidly changing, its rdepends need active maintenance to remain functional. If an upstream is inactive, it may be necessary to drop support for a package in a post-release update. This is unfortunate, but may be unavoidable. In these cases, the dropped package should be used as a transitional package that depends on the most generally suitable alternative so users are not left without an installed, functional package.

Experience

This process has been experimentally executed from beginning to end twice. Dapper, Feisty, and Gutsy were updated to Clamav 0.92.2 (which is what Hardy was released with) and Dapper and Hardy were updated to 0.94.2 (which is what Intrepid was released with). The initial Dapper update was a major version update (0.88 to 0.92). The other updates were all minor version updates within the 0.9X series. So far, although labor intensive and taking longer to complete than would be ideal, this process has produced good results. When Dapper, Feisty, and Gutsy were updated only two bugs were filed (both Dapper). In one case a user needed to manually adjust a configuration file. In the other case the user had depended on a function provided by python-clamav that had been dropped in the newer release for his own private scanning tool. We were able to quickly package python-pyclamd and provide a suitable alternative. For the Dapper/Hardy update to 0.94.2, the only issue known so far was one rdepend misbuilt against the old clamav and that was quickly corrected.

This does, however, involve a lot of work to build a lot of packages. On this last cycle, the following were needed:

For Dapper:

clamav 0.94.dfsg.2-1ubuntu0.3~dapper1

avscan 3.2.2-openssl-1build1~dapper1

clamassassin 1.2.4-1~dapper1

clamcour 0.2.2-1.2build1~dapper2

dansguardian 2.9.9.7-2~dapper1

gurlchecker 0.10.2-2ubuntu1~dapper1

havp 0.89-2ubuntu1~dapper1

klamav 0.44-3~dapper1

python-clamav 0.4.1-1build2~dapper1

python-pyclamd 0.1.1-0ubuntu1~dapper1

php-clamavlib 0.12a-4~dapper2

sylpheed-claws-gtk-clamav 1.0.5-5.1ubuntu0.1~dapper2

sylpheed-claws-gtk2-clamav 2.6.0-1.1ubuntu1.1~dapper2

For Hardy:

clamav 0.94.dfsg.2-1ubuntu0.3~hardy3

avscan 3.2.2-openssl-1build1+hardy1

dansguardian 2.9.9.7-2~hardy1

gurlchecker 0.10.2-2ubuntu1~hardy1

havp 0.89-2ubuntu1~hardy1

klamav 0.44-3ubuntu2~hardy1

python-clamav 0.4.1-1build2~hardy1

php-clamavlib 0.13-1.2ubuntu1~hardy1

This process has provided a good balance between cutting-edge and stable, integrated capability and seems suitable to extend to Intrepid and Jaunty where clamav is in Main. Up-to-date clamav with an integrated, tested package set is a feature unique to Ubuntu Server that is another way to positively differentiate Ubuntu Server from its competitors.

ClamavUpdates (last edited 2009-07-10 16:32:55 by static-72-81-252-22)