Allow users to bring their own libdave

[zfcmoe]

The project does currently not work on some Linux distros, such as CentOS Stream, due to the shared libraries requiring a recent glibc version. Also more obscure operating systems, such as FreeBSD are also not supported. This has already been pointed out by issue #30 30

This is a fairly simple fix, where one can depend only on club.mincced:jdave-api, and provide the library file separately by specifying a path as LIBDAVE_PATH=/opt/libdave.so java -jar bot.jar.

This also avoids reading a shared library from /tmp/, which has some security implications I'm not a fan of.

[MinnDevelopment]

This also avoids reading a shared library from /tmp/, which has some security implications I'm not a fan of.

Could you elaborate? This is a very common pattern used by many libraries.

[MinnDevelopment]

I would prefer using a system property for this.

Please also add some information about this to the readme.

[creperozelot]

This also avoids reading a shared library from /tmp/, which has some security implications I'm not a fan of.

Could you elaborate? This is a very common pattern used by many libraries.

What I had in mind is mainly that some hardened systems apply stricter security controls to /tmp.
For example, with setups aligned to CIS recommendations, /tmp is often mounted on a separate partition and may use restrictive mount options such as noexec, and sometimes additional permission restrictions.

The separate partition itself is not really the main issue. The bigger problem is that these restrictions can prevent files extracted there from being read or executed as expected.

Because of that, it may be safer to extract the files into something like System.getProperty("user.dir") + "/tmp" instead, and optionally clean that directory on restart.

EDIT: Under normal circumstances this should not happen, but on certain specialized or hardened systems it can definitely occur if user permissions are not configured correctly.