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:[email protected]] 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 <[email protected]> On Behalf Of Mark
Allan via clamav-users
Sent: Monday, July 26, 2021 5:27 PM
To: ClamAV users ML <[email protected]>
Cc: Mark Allan <[email protected]>
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 <[email protected]> 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:[email protected]] 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!

 


https://blog.clamav.net/2021/07/clamav-01040-release-candidate-is-here.html


ClamAV 0.104.0 Release Candidate is here!


We are pleased to announce the  <https://www.clamav.net/downloads> 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
<https://lists.clamav.net/mailman/listinfo/clamav-users> ClamAV mailing
list, or on  <https://discord.gg/sGaxA5Q> 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  <https://github.com/Cisco-Talos/clamav/issues>
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  <https://hub.docker.com/r/clamav/clamav> 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
<https://docs.clamav.net/manual/Installing/Docker.html> 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  <https://docs.clamav.net/appendix/Authenticode.html>
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
[email protected]
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

 

_______________________________________________

clamav-users mailing list
[email protected]
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

Reply via email to