On Thu, 2024-09-05 at 15:58 +0000, Micah Snyder (micasnyd) wrote: Warning: veering wildly off-topic below. I know rust isn't going away, I just like to hear myself talk.
> Depending on countless hours of work from volunteers to maintain an OS-level > package for every library dependency seems untenable to me. Whatever number of hours you were going to spend updating your machine, you instead spend updating the distro package. For that one guy, it's the same cost, but then for everyone else, it's free, because the first guy did it. Updating the distro package for clamav consists literally of me compiling it, just like I would have to do if I wasn't maintaining the distro package and was going to install it as a normal (non-distro) user. But I don't really want to make a theoretical argument: before rust was involved, every distro had packaged every library needed by clamav. In Gentoo we even packaged a few more (patching autotools to unbundle libtommath, for example). Empirically it just isn't a hard problem, and using distro sources solves lots of other ones, like crates, npm, pypi, etc. being fundamentally insecure (no web of trust). > > What's worse is having the build system just link in whatever happens to be > installed on your system as an application dependency, simply because > pkg-config happened to detect it. I think this is an archaic and unreliable > way to compile software. This isn't hypothetical either. I just fought this > issue (on Windows) with a new version of libcurl linking in libidn2 that was > installed by Strawberry Perl because pkg-config found it. I had no intention > of linking some random version of libidn2 and might've accidentally bundled > it into the Windows installer and shipped it if there hadn't been a > compatibility issue. > This is _also_ a problem, but I don't see how it's related? We call them "automagic dependencies," and they're essentially a bug in the build system. They ignore the fact that people sometimes install libraries incidentally, and later uninstall them. It's pretty easy to fix by submitting patches that add --disable-foo to the build system. Most people are willing to accept them once you explain the issue: https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Automagic_dependencies All you really wanted was a way to compile your thing without libidn2, which the build system should have provided if the feature is optional and in some cases undesirable. (They are basically always "in some cases" undesirable by minimalists or on embedded systems.) > My stance at this time is that I would rather statically link the right > versions of the required dependencies and have to recompile the application > if it is affected by a CVE. I can appreciate that it saves compute if you > have multiple applications using the same shared lib and you only have to > rebuild the shared lib. And again, libcurl is probably a great example there > where everyone uses it, and it's huge, and it seems to have a new CVE like > every 12 weeks. So, I do I get that. But in most cases, I don't believe > that's worth the burden of tracking down bugs due to unreproducible C/C++ > build system technology, and maintaining all those extra packages. > This is a reasonable trade-off as a developer if someone is looking for security vulnerabilities in the version you use. But are they? Is someone checking foobar-0.1.9 for vulnerabilities two years after it was released? As a user the trade-off is less attractive. Normal users are far less emotionally invested in your one application, and are more concerned about the system as a whole. Static linking or bundling always wastes memory, disk space, and time. Every developer wants his thing to be special, but if _every_ package wasted disk space, memory, and time, chaos would ensue. Or rather, Microsoft Windows would ensue. Which is why people who switched to Linux to get away from the Windows way of doing things always have an opinion on this :) _______________________________________________ Manage your clamav-users mailing list subscription / unsubscribe: https://lists.clamav.net/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/Cisco-Talos/clamav-documentation https://docs.clamav.net/#mailing-lists-and-chat
