Ok that was the answer. It was done because the development team wanted new toys and the fact that you have to include instructions as to how to go about building cmake (and using a version that requires a fairly new distro). And cmake is constantly releasing new updates which, in my mind, puts it right up there with Fedora in terms of "ready for production". Autotools was at least a staple that pretty much and pretty much any end user could run the configure command and end up with a functional program without having to install a whole new build.
system.
 
total disregard for the user base, not so much as a poll or query on the lists, enjoy your new cutting edge toys
 
Corporate BS rears it's ugly head again, First snort, then centos and now clamav.
 
 

From: clamav-users [mailto:clamav-users-bounces@lists.clamav.net] On Behalf Of Micah Snyder (micasnyd) via clamav-users
Sent: Tuesday, July 27, 2021 6:26 PM
To: ClamAV users ML
Cc: Micah Snyder (micasnyd)
Subject: Re: [clamav-users] ClamAV® blog: ClamAV 0.104.0 Release Candidate is here!

All:

 

I and others on the development team struggled with Autotools and felt plagued by a myriad of little bugs. Whenever we had a problem with autotools (and there were plenty) it was always, “Heeey you’re the Autotools expert. You got this, right?…” No one wanted to deal with it.

 

CMake is far less confusing and less error-prone (at least to me). The documentation is great. It has built in features to detect loads of system-installed libraries. More recent versions even have system similar to pkg-config for importing build targets exactly as they were created when compiled, so that you never miss a library dependency. No more mussing about with LDFLAGS and LIBS variables and various directory variables. Honestly, it’s a breath of fresh air. And CMake supports Windows which allowed us to drop the old Visual Studio project files. There’s more, but I think that should be enough. No it won’t necessarily improve detection, unless you were one of those people who didn’t realize you needed libbz2 or some such “optional” dependency in order to get the most out of ClamAV.

 

Anyways, there are many reasons why CMake is better than Autotools but I don’t want to ramble on about it any more than I already have. I recommend reading up on some modern CMake features. You may find that you like it.

 

But if you really don’t want to deal with it, you can wait until your system’s packaging system has the next ClamAV version. That’s what most people will do anyways.

 

Mark:

 

I’m sorry about breaking your scripts. For what it’s worth, all of the dependency builds should stay the same but you’ll have to change the commands for building ClamAV itself.

 

One of those reasons why CMake is awesome is that it’s really easy to build installers. Just last week Hanspeter and I figured out how to link ClamAV with a static libcurl build and have it bring along all of libcurl’s dependencies. This was a roadblock for a couple things to include building a PKG installer for macOS. After seeing your comments about Homebrew, and with that roadblock finally removed, you successfully nerd-sniped me into figuring out the rest of the macOS installer build.

 

I just finished a pull-request to add support to build a PKG installer for Mac. I would love your input on it: https://github.com/Cisco-Talos/clamav/pull/228

Note that I picked an install path /opt/clamav rather arbitrarily.  If we’re going to add a macOS PKG installer to our Downloads page, I’d appreciate input on where you think it should actually install to.

 

My example in the PR (and commit message) rely on having used Mussels, our dependency build automation tool, to build all of the static libs (https://github.com/Cisco-Talos/Mussels).

We use Mussels to build the dependencies for Windows and for Linux (for OSS-Fuzz). Crafting recipes for static libs for macOS wasn’t so bad. I added those last night. You can review the recipes the “clamav cookbook” uses to build each dependency here: https://github.com/Cisco-Talos/clamav-mussels-cookbook/

 

If you want to give it a try instead of using your own build tools, the Mussels project page has some basic instructions but for a leg up here are some commands to get you started:

 

python3 -m pip install mussels

msl --help

msl up

msl cookbook trust clamav

msl build --help

msl build clamav_deps -t host-static --dry-run

msl build clamav_deps -t host-static

 

I have not yet modified the clamav recipe to build the PKG installer, since the above PR hasn’t merged yet, but “msl build clamav -t host-static” should also work.

 

Anyways, please let me know what you think. 

 

Respectfully,

Micah

 

 

From: clamav-users <clamav-users-bounces@lists.clamav.net> On Behalf Of Mark Allan via clamav-users
Sent: Monday, July 26, 2021 5:27 PM
To: ClamAV users ML <clamav-users@lists.clamav.net>
Cc: Mark Allan <markjallan@gmail.com>
Subject: Re: [clamav-users] ClamAV® blog: ClamAV 0.104.0 Release Candidate is here!

 

I find myself asking the same question. Just from a personal point of view, I've invested a lot of time over the years creating scripts that pull down dependencies, build & install them in the right order, and then build package and deploy ClamAV. Looks like I'll now have to spend even more time, trying to get my head around making them work with CMake....and for what? What benefit does it bring?

 

Of course, I understand that this is your project and you can do whatever you like with it, and that you don't owe us any explanation for doing anything, but it still seems odd to change the whole build process without at least saying what the benefits are.

 

...and don't get me started on the official recommendation to use Homebrew on macOS.

 

Regards

Mark



On 26 Jul 2021, at 4:35 pm, Rick Cooper <rcooper@dwford.com> wrote:

 

And what, exactly, is the reason for moving to cmake? I am sure you know it's going to be problematic for thousands of people so I am curious what tremendous gain of speed, size, memory usage or seciurity the other users get from this change, or if it's just a convenience thing for the developers?

 

 

 

From: clamav-users [mailto:clamav-users-bounces@lists.clamav.net] On Behalf Of Joel Esler (jesler) via clamav-users
Sent: Thursday, July 22, 2021 12:19 PM
To: ClamAV users ML; ClamAV Development
Cc: Joel Esler (jesler)
Subject: [clamav-users] ClamAV® blog: ClamAV 0.104.0 Release Candidate is here!

 

ClamAV 0.104.0 Release Candidate is here!

We are pleased to announce the ClamAV 0.104.0 release candidate.

Please help us validate this release. We need your feedback, so let us know what you find and join us on the ClamAV mailing list, or on our Discord, which is bridged with our IRC.

This release candidate phase is only expected to last about two to four weeks before the 0.104.0 Stable version will be published. Take this opportunity to verify that you 0.104.0 can build and run in your environment. 

Please submit bug reports to the ClamAV project GitHub Issues.  

ClamAV 0.104.0 includes the following improvements and changes.

New Requirements

  • As of ClamAV 0.104, CMake is required to build ClamAV.
  • We have added comprehensive build instructions for using CMake to the new INSTALL.md file. The online documentation will also be updated to include CMake build instructions.
  • The Autotools and the Visual Studio build systems have been removed.

Major changes

  • The built-in LLVM for the bytecode runtime has been removed.
  • The bytecode interpreter is the default runtime for bytecode signatures just as it was in ClamAV 0.103.
  • We wished to add support for newer versions of LLVM, but ran out of time. If you're building ClamAV from source and you wish to use LLVM instead of the bytecode interpreter, you will need to supply the development libraries for LLVM version 3.6.2. See INSTALL.md to learn more.
  • There are now official ClamAV images on Docker Hub.
    • Note: Until ClamAV 0.104.0 is released, these images are limited to "unstable" versions, which are updated daily with the latest changes in the default branch on GitHub.

You can find the images on Docker Hub under clamav.

Docker Hub ClamAV tags:

  • clamav/clamav:<version>: A release preloaded with signature databases.

Using this container will save the ClamAV project some bandwidth. Use this if you will keep the image around so that you don't download the entire database set every time you start a new container. Updating with FreshClam from the existing databases set does not use much data.

  • clamav/clamav:<version>_base: A release with no signature databases.

Use this container only if you mount a volume in your container under /var/lib/clamav to persist your signature database databases. This method is the best option because it will reduce data costs for ClamAV and for the Docker registry, but it does require advanced familiarity with Linux and Docker.

Caution: Using this image without mounting an existing database directory will cause FreshClam to download the entire database set each time you start a new container.

You can use the unstable version (i.e. clamav/clamav:unstable or clamav/clamav:unstable_base) to try the latest from our development branch.

Please, be kind when using "free" bandwidth for the virus databases and Docker registry. Try not to download the entire database set or the larger ClamAV database images on a regular basis.

For more details, see the ClamAV Docker documentation.

Special thanks to Olliver Schinagl for his excellent work creating ClamAV's new Docker files, image database deployment tooling, and user documentation.

  • clamd and freshclam are now available as Windows services. To install and run them, use the --install-service option and net start [name] command.

Special thanks to Gianluigi Tiesi for his original work on this feature.

Notable changes

We added these features in 0.103.1 but wanted to re-post them here, as patch versions do not generally introduce new options:

  • Added a new scan option to alert on broken media (graphics) file formats. This feature mitigates the risk of malformed media files intended to exploit vulnerabilities in other software. Currently, media validation exists for JPEG, TIFF, PNG, and GIF files. To enable this feature, set AlertBrokenMedia yes in clamd.conf, or use the --alert-broken-media option when using clamscan. These options are disabled by default in this patch, but may be enabled in a subsequent release. Application developers may enable this scan option by enabling CL_SCAN_HEURISTIC_BROKEN_MEDIA for the heuristic scan option bit field.
  • Added CL_TYPE_TIFF, CL_TYPE_JPEG types to match GIF and PNG typing behavior. BMP and JPEG 2000 files will continue to detect as CL_TYPE_GRAPHICS because ClamAV does not have BMP or JPEG 2000 format-checking capabilities.
  • Added progress callbacks to libclamav for:
    • database load: cl_engine_set_clcb_sigload_progress()
    • engine compile: cl_engine_set_clcb_engine_compile_progress()
    • engine free: cl_engine_set_clcb_engine_free_progress()

These new callbacks enable an application to monitor and estimate load, compile and unload progress. See clamav.h for API details.

  • Added progress bars to ClamScan for the signature load and engine compile steps before a scan begins. The startup progress bars won't be enabled if ClamScan isn't running in a terminal (i.e. if stdout is not a TTY), or if any of these options are used:
    • --debug
    • --quiet
    • --infected
    • --no-summary

Other improvements

  • Added the %f format string option to the ClamD VirusEvent feature to insert the file path of the scan target when a virus event occurs. This supplements the VirusEvent %v option that prints the signature (virus) name. The ClamD VirusEvent feature also provides two environment variables, $CLAM_VIRUSEVENT_FILENAME and $CLAM_VIRUSEVENT_VIRUSNAME for a similar effect. This fix comes courtesy of Vasile Papp.
  • Improvements to the AutoIt extraction module. Patch courtesy of cw2k.
  • Added support for extracting images from Excel *.xls (OLE2) documents.
  • Trusted SHA256-based Authenticode hashes can now be loaded in from *.cat files. See our Authenticode documentation for more info about using *.cat files with *.crb rules to trust signed Windows executables.

Bug fixes

  • Fixed a memory leak affecting logical signatures that use the "byte compare" feature. Patch courtesy of Andrea De Pasquale.
  • Fixed bytecode match evaluation for PDF bytecode hooks in PDF file scans.
  • Other minor bug fixes.

Acknowledgments

The ClamAV team thanks the following individuals for their code submissions:

  • Alexander Golovach
  • Andrea De Pasquale
  • Andrew Williams
  • Armin Kuster
  • Brian Bergstrand
  • cw2k
  • Duane Waddle
  • Gianluigi Tiesi
  • Jonas Zaddach
  • Kenneth Hau
  • Markus Strehle
  • Olliver Schinagl
  • Orion Poplawski
  • Sergey Valentey
  • Sven Rueß
  • Tom Briden
  • Vasile Papp
  • Yasuhiro Kimura


_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml