Allow to use system's tomsfastmath library instead of the bundled one.

[sebastianas]

By default the bundled tomsfastmath library is used. It can be overriden to use the library from the system if available. Should the system library only be able to handle RSA keys up to 2048 bits then the selftest will fail.

Signed-off-by: Sebastian Andrzej Siewior sebastian@breakpoint.cc

[val-ms]

We had this feature but removed it, here: 5c3e866

A standard build of tomsfastmath does not support wide enough floating point numbers for our use case and will not work correctly. It is better (for us) to know that everyone is using tomsfastmath that is configured to work for clamav.

Edit: I saw your comment:

Should the system library only be able to handle RSA keys up to 2048 bits then the selftest will fail.

... but I do not see this feature in this PR.

Edit 2: I also see you have a patch for the debian tomsfastmath package https://sources.debian.org/patches/tomsfastmath/0.13.1-1/Increase-FP_MAX_SIZE-to-8192.patch/

I should also note that I'm really hesitant to revert 5c3e866 because the more build configurations we have, the more we should test -- and that is very time consuming to build and test each variation, which means we probably won't do it.
Further, Tomsfastmath's last release was in 2017. I realize a CVE could pop up any time. It is C after all. But... 🤞 it seems pretty stable.

[sebastianas]

On 2023-01-06 10:22:48 [-0800], Micah Snyder wrote: We had this feature but removed it, here: 5c3e866 A standard build of tomsfastmath does not support wide enough floating point numbers for our use case and will not work correctly. It is better (for us) to know that everyone is using tomsfastmath that is configured to work for clamav.

Could we have something that is not announced? I kind of need to use the in-tree lib rather than the bundled copy. You could as upstream to update lib and make a release ;) This is the only change right? Sebastian

[val-ms]

Could we have something that is not announced?

It is included in the major changes in the change log;

• https://blog.clamav.net/2022/11/clamav-100-lts-released.html
• https://github.com/Cisco-Talos/clamav/blob/clamav-1.0.0/NEWS.md?plain=1#L45-L50

I kind of need to use the in-tree lib rather than the bundled copy.

I feel like "need" is an exaggeration. It is not your responsibility to de-bundle bundled sources. I see the appeal in the situation where a bunch of other packages are using tomsfastmath. If de-bundled, you would be able to push out 1 update to tomsfastmath if there is a security issue and have that cover them all. Though I don't know how many other packages depend on tomsfastmath for Debian. I don't know how to check what other packages depend on https://packages.debian.org/source/bullseye/tomsfastmath. Though that sort of ties into my next point.

You could as upstream to update lib and make a release ;)

I don't know if changing from the defaults will break other software packages that expect the default settings. If there are no other packages that depend on tomsfastmath, then it seems even less critical that this tomsfastmath is de-bundled from clamav.

This idea is not invalid, but it doesn't take into consideration all of the other distros that may use clamav and think "hey, external tomsfast seems better, let's do that!" We obviously can't find and "fix" tomsfastmath packages for every distro.

This is the only change right? Sebastian

We also build with these defined:

• TFM_CHECK
• TMP_NO_ASM

Set through the build system in: 375ecf6#diff-6d5ce841c8f84bb1d6383da4bf5fa35316926e2e0668ad71aa137d7bd5429c43R26-R34

[sebastianas]

On 2023-01-23 11:43:11 [-0800], Micah Snyder wrote: > Could we have something that is not announced? It is included in the major changes in the change log; - https://blog.clamav.net/2022/11/clamav-100-lts-released.html - https://github.com/Cisco-Talos/clamav/blob/clamav-1.0.0/NEWS.md?plain=1#L45-L50

I meant to support system's lib without making a big fuss about.

> I kind of need to use the in-tree lib rather than the bundled copy. I feel like "need" is an exaggeration. It is not your responsibility to de-bundle bundled sources. I see the appear if a bunch of other packages are using tomsfastmath to be able to push out 1 update to tomsfastmath if there is a security issue and have that cover them all. I don't know how to check what other packages depend on https://packages.debian.org/source/bullseye/tomsfastmath. Though that sort of ties into my next point.

$ apt-cache rdepends libtfm1 libtfm1 Reverse Depends: libtfm-dev libtfm1-dbgsym libclamav11 In general the policy is to use system's libs. For this reasons I also provided the glue layer for libmspack.

> You could as upstream to update lib and make a release ;) I don't know if changing from the defaults will break other software packages that expect the default settings. If there are no other packages that depend on tomsfastmath, then it seems even less critical that this tomsfastmath is de-bundled from clamav. This idea is not invalid, but it doesn't take into consideration all of the other distros that may use clamav and think "hey, external tomsfast seems better, let's do that!" We obviously can't find and "fix" tomsfastmath packages for every distro.

Hmm. I started looking into replacing tfm with openssl bignum (BN). That should fix all things are is there something that is unique to tfm? I just started so I may discover it soon - or not ;)

> This is the only change right? Sebastian We also build with these defined: - `TFM_CHECK` - `TMP_NO_ASM`

That should be what we do. Sebastian

[sebastianas]

This is obsoleted by #840

[val-ms]

Closing because not desired out of compatibility concerns with default TFM build config for other distros that may use it, and because obsoleted by #840 as Sebastian said.