ClamAV Bugzilla new ticket creation will redirect to GitHub Issues

In early 2021, we made a decision to switch to using GitHub directly. Before then, our primary Git repository was sequestered to the Cisco corporate network. The public GitHub repository was just a mirror. That made it tougher for us to connect to and work with contributors from the ClamAV community. Our daily routines drew our attention away from GitHub.

At the same time, we also settled on a plan for how we could test using GitHub Issues for ClamAV bug reports. Initially, this would supplement our aging Bugzilla server. While Bugzilla requires users to make an account on our server, enabling GitHub Issues would open up bug reporting to the wider GitHub community that already has an account.

Since enabling GitHub Issues at the start of June, we have found that using GitHub Issues has been a very positive experience. At this point, most of our reports come in through GitHub Issues. With the aid of issue templates, the quality of bug reports coming through GitHub Issues has also been of a higher caliber than those coming through Bugzilla. With users following guidance in the template, the bug reports are generally easier to triage and respond to intelligently. 

All that being said, we will disable Bugzilla ticket creation so we can focus all new bug reports towards GitHub Issues. Effective immediately, the new ticket creation form on bugzilla.clamav.net will redirect users to the new issue creation page on our primary ClamAV repository on GitHub.com.

Existing open tickets on Bugzilla will remain open for now, and the Bugzilla server is expected to remain available through 2022 as we complete this transition. 

If you have an open ticket on Bugzilla and would like to help migrate it to GitHub Issues, we would appreciate the help. If you choose to migrate any tickets from Bugzilla to GitHub Issues, please add references in each ticket and close the original Bugzilla ticket(s) to assist our team with the ticket queue maintenance.

Thank you!

Micah

"clamav-devel" GitHub repository name change to "clamav"

On Tuesday, May 18th the Cisco-Talos "clamav-devel" repository on GitHub will be renamed to "clamav".

This is just an advisory notice. GitHub automatically redirects requests for renamed repositories so that the old URLs remain functional.

However, those who have clones-of or links-to this git repository may wish to update the URLs after the rename is complete. For example:

http://github.com/Cisco-Talos/clamav-devel

  to http://github.com/Cisco-Talos/clamav

http://github.com/Cisco-Talos/clamav-devel.git

  to http://github.com/Cisco-Talos/clamav.git

git@github.com:Cisco-Talos/clamav-devel.git

  to git@github.com:Cisco-Talos/clamav.git

 

Thank you!

ClamAV Git Work-flow Changes

If you use ClamAV’s Git repository, you may have noticed that we’ve recently changed our Git workflow.

It’s a big departure from what we had been doing, and we believe it will be a major improvement. Our new workflow took inspiration from the popular and well-known GitFlow model, and it shares some of its features. However, to better suit our needs, we’ve made a number of modifications and simplifications to the original GitFlow paradigm. Here’s a rundown of some of the most important changes:

1. New commits will go into dev/0.101 instead of master.  The default branch will now be dev/0.101.
• When unit tests, system tests, and regression tests on dev/0.101 are up to snuff, we will cherry-pick the commits over to master. This way, master will always be stable. 
2. When we’re ready to release, we will create a release branch (rel/0.101) from master and tag the release (0.101.0). 
3. A new dev branch will be created for the next feature release (dev/0.102) and will be set as the default branch. 
4. Any urgent security or bug-fix patches will be applied both to the new dev branch (dev/0.102) and to the previous dev branch (dev/0.101).  
• After successful testing on dev/0.100, the patch(es) will be cherry-picked to rel/0.101 and tagged for the patch version release (0.101.1). 
• Meanwhile, the same urgent patch(es) will undergo normal testing in the current dev branch (dev/0.102). Security related patches will remain private until the patch version release is published.
5. The goal going forward is for master to always be stable, so we can publish releases as frequently as needed.  With this workflow and versioning scheme, it will also be easy to create patch releases. 

As a disclaimer:  We’re just getting started with the new Git workflow, which means that master isn’t proven stable yet. Also, we have some major automation improvements to make to our system and regression-testing processes that will make this workflow highly effective. The automation improvements are still in the works, and are probably a couple months out. Until then, any testing done before we cherry-pick changes to master will be mostly manual.

The takeaway from this is that these are the important branches in the ClamAV Git repository:

• dev/0.101 — The latest unstable code in development.
• master — The latest tested stable code.
• rel/0.100 — The latest released version, which is also posted on clamav.net.
• dev/0.100 — The previous development branch, used to test hotfixes prior to a patch release. 

For any further questions or discussion please head on over to our ClamAV-devel mailing list
http://lists.clamav.net/mailman/listinfo/clamav-devel

Thank you.

Create your own ClamAV signatures with CASC!

The ClamAV community is growing and we are receiving more user-generated ClamAV signatures through our community signatures mailing list. Thanks to all who have contributed! For those who find the task of writing your own signatures daunting, we have created something you may be interested in.

To aid users in developing better ClamAV signatures faster, I've created the ClamAV Signature Creator (CASC), an IDA Pro plug-in. A quick and easy installation into IDA Pro 6.7 or higher (reduced feature set for IDA Pro 6.6) will have you creating basic ClamAV ndb and ldb signatures in no time. CASC allows users to select aspects of a sample's disassembly, a function block, or a set of strings to create a sub-signature. Each sub-signature can contain user-defined notes to keep track of information contained within the sub-signature. Once you've selected enough sub-signatures to get the job done, or until your heart's content, a ClamAV signature can be created from one or more sub-signatures.

Check out this IDA Pro plug-in on Github and its wiki for documentation.