ClamAV is looking for a new team member!

The ClamAV Development team is looking to add a new C programmer to the team, located in Fulton, Maryland USA!

Our team is a small and friendly one. At present, we have two software engineers and one quality assurance engineer. All three of us work in the Cisco office in Fulton, MD where we occupy a comfortable corner complete with our own snack area and Nerf gun arsenal. And we're not simply legacy software maintainers: we actively design and engineer new features while improving existing ones. If you’re seeking a long-term, head-in-the-sand, maintenance job, look elsewhere. Our team is constantly engaged. From discussing new ways to improve our processes, to opening ourselves to new concepts, our willingness to learn and explore new ideas leads us to write better code, test more effectively, and ultimately build a better product.

As a member of the ClamAV team, you wouldn’t be working in a vacuum, and you wouldn’t get stuck fixing bugs in legacy software day-in and day-out. The team has an ever-evolving list of cool, new ideas to work on. Project planning is a collaborative effort. We derive requirements from community requests as well as from our partners in Talos Malware Research, Talos Web Team, and stakeholders across a handful of Cisco product groups. We work as a team to find the best way to tackle the more difficult challenges. The ClamAV Dev team is part of a larger group of skilled developers, researchers, and analysts, with whom we collaborate daily. Working on ClamAV, you'll always have a friendly and highly-skilled talentpool from which to draw upon and share ideas.

Our team performs for a wide audience. ClamAV is oft regarded as an anti-malware product, but our tools do more than protect endpoint devices. In fact, ClamAV is run on most mail servers and many web servers on the internet, protecting the world from malware transmitted via email and file upload. What’s more, our open source scanning and matching technology is baked into many of Cisco's core products. As a consequence, our team is responsible for maintaining a healthy relationship not only with the open source community but also with those Cisco product development teams that integrate ClamAV into their software.

Speaking of Talos, the ClamAV team is a core component of the largest and coolest commercial threat intelligence organization on the planet. Our offices are new and shiny. Our workforce is skilled, but also casual. We enjoy our work, and we know how to relax, too. That means our office has an active roster of video gamers, board gamers, ping pong players, and more.

Ok … so the work sounds good to you, and the office sounds great too… but your schedule can be a little crazy, and sometimes you need to stay home in your pajamas. No problem. Our team generally works from home once a week. Usually we work from home on Fridays, but things can be adjusted as needed to accomodate life's inescapable work-week appointments.

Does this job sounds too good to be true? Don't take my word for it. This year, Cisco placed #6 in Fortune’s rankings of the 100 best companies to work for! Our offices in Fulton, MD and in San Jose, CA are no exception.

To see the required skills, please check out the job listing on our careers page on TalosIntelligence.com.

Libclamav missing headers issue; Upcoming ClamAV 0.101.1 patch

Earlier this month we wrote to the ClamAV users and developers mailing lists to disclose an issue with ClamAV 0.101.0. To reach a larger audience, we are re-posting those details here.

Shortly after the 0.101.0 release was published, we discovered an issue in ClamAV 0.101.0 impacting software developers and software package maintainers that integrate libclamav into other products on Unix/Linux systems. This issue causes an error when a user attempts to compile against a system-installed libclamav. 

We have a fix staged and nearly ready to be published. The fix will be published shortly after the start of 2019 in the ClamAV 0.101.1 patch release. This delay is necessary in order to fully test the fix and complete the due diligence required when creating a new build, accounting for delays that the holiday season brings. We apologize for the inconvenience.

Here are some additional details about this patch:

• ClamAV uses a lot of mixed integer variable types internally. The preferred types are standard int types (eg int8_t, uint64_t, size_t, ptrdiff_t, etc).
• As an ongoing effort to make variable types more consistent throughout the code base, we made the mistake of including the `cltypes.h` header file in `clamav.h`, which is not only used internally, but defines the public libclamav API. Because neither the `cltypes.h` header, nor the supporting `clamav-config.h` header are provided when installing libclamav to a system, applications built with a system-installed libclamav from version 0.101.0 will fail to compile.
• To resolve the issue, we will be replacing `cltypes.h` with a new `clamav-types.h` file that is generated when the user runs `./configure.` This will be installed alongside `clamav.h` when the user runs `make install.` This will ensure that `clamav.h` has access to the necessary integer types on all operating systems and architectures.
• To mitigate similar issues in the future, we have added a test to our build-acceptance suite to test building an application against a system-installed libclamav library.

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.