Comments (8)
I made some minor improvements to the loading functionality. Should be in release 4.0.1 now. Overall I am super happy with how it loads the shared libraries now!
Happy to close this 😀
from lazysodium-java.
Hello again @dmitry-timofeev,
These are very thought provoking questions.
Background
I wanted Lazysodium to be as frictionless as possible to get started with. I could have relied on the user to install libsodium.so
or libsodium.dylib
or libsodium.dll
files on their system, but even that is a headache as users may have had to compile libsodium to get it installed. Bundling those shared libraries with Lazysodium had several positive effects such as being able to use Lazysodium as a dependency of a dependency. As you have rightly mentioned, Lazysodium is very flexible in the sense that it can load from a variety of different sources, such as the system or an absolute path or from within the bundled resources.
So in the spirit of making it as easy as possible to use for developers, I decided that Lazysodium should load its shared libraries from bundled resources first.
However, you have raised a very valid point that the developer may not control the environment (and therefore to a certain extent how Lazysodium loads its shared libraries). Thus, a developer may want control over that... And I wholeheartedly agree with that.
Answers
So to answer Q3, the default going forward should be:
- We need to first try to load from the system installed libraries.
- If that fails, load from the bundled shared libraries.
To answer Q1, the user does not always know what's best. We can make it easier for them by first loading from the system then falling back to the bundled shared libs, which are tried and tested to be working.
To answer Q2. This is a fantastic idea and provides the user with more explicit control over how Lazysodium loads its shared libsodium
libraries. As mentioned, the default should be the procedure outlined above. But the user can override it by setting variables within LibraryLoadingMode
.
Further questions
- So now the question becomes what will
LibraryLoadingMode
look like? It needs to provide developers with a way of saying "Load from system first, then if that fails load from bundled resources, then if that fails load from absolute path, if that fails throw exception." I am not sure how best to achieve this. - Slightly related question, do you know how other libraries handle this problem? I imagine it is an infrequent (but not rare) problem, so I am curious how other libraries handle this? Do you know of any projects I could look at?
from lazysodium-java.
Hi @gurpreet- ,
Thank you for the background and the feedback!
Regarding your first question, I imagined the following interface for instantiation:
SodiumJava
----------
# The existing interface, uses the default loading policy
+ SodiumJava()
# A new constructor that gives explicit control over the policy,
# if the default is not suitable
+ SodiumJava(mode: LibraryLoadingMode)
# The existing constructor accepting a 'library locator',
# which may be a filesystem path.
#
# Mostly for advanced usage,
# e.g., when a user needs to load the sodium library
# that they manage themselves from a path, therefore,
# has its own constructor to not complicate the two previous
# that must be enough for most cases.
+ SodiumJava(libPath: String)
With such interface, LibraryLoadingMode
may be a simple enum:
LibraryLoadingMode
------------------
+ PREFER_INSTALLED
+ PREFER_BUNDLED
+ INSTALLED_ONLY
It might also be reasonable to consider pushing handling of various loading modes into LibraryLoader
for easier testing.
Do you think that would work?
I don't know of libraries with a similar mechanism, but maybe some Java bindings to popular libraries might have one.
If you don't mind, I could try to implement this feature (probably, later this week/next week). If other questions arise, we can ponder on them meanwhile.
from lazysodium-java.
Yes I think that could work, although I was thinking LibraryLoadingMode
could be something like the following (this should be treated like pseudocode as I'm writing by hand at the moment):
abstract class LibraryLoadingMode {
// Returns load order. One of INSTALLED, BUNDLED, PATH
abstract Mode[] loadOrder();
// Will be an absolute path to the library, can be null.
abstract String path();
void loadLibrary() {
// Using loadOrder(), load a shared library according to the user's wishes.
}
}
And therefore can be used easily like:
new SodiumJava(new LibraryLoadingMode() {
Mode[] loadOrder() {
return [INSTALLED, BUNDLED, PATH];
}
String path() {
return "/absolute/path/to/libsodium.so"
}
});
from lazysodium-java.
👍 that would be more flexible, and it would be possible to provide pre-defined instances (as they can be immutable) covering the common use-cases we discussed, so that the user does not need to create them themselves unless they need to.
Do you think though it is needed to attempt to load both system/bundled and using a certain path? I certainly can't imagine all the use-cases, but I think that one either ensures there is their library build supplied with the application and available by a certain path, or they rely on the system and/or the bundled.
I had a chance to hack on it yesterday, and currently went with the simpler implementation using three pre-defined modes: #52
from lazysodium-java.
Also, I've managed to enable integration testing of both modes by running the tests in corresponding classes in individual (forked) VMs: exonum/exonum-java-binding#991
Each VM can then load its own version of sodium. The configuration in that PR is for Maven Surefire plugin + JUnit 5, but I am sure something similar exists for Gradle.
from lazysodium-java.
Thank you @dmitry-timofeev,
I trialled my version using the abstract class and to be honest, it's not at all great. It's confusing to the end user as to what to override and if they're not using an absolute path shared library why should they override path()
anyway.
Your implementation targets all 3 loading modes strategically and in a way that aligns with the mission of this library - which is to make it effortless to use cryptography in any project.
So I have merged your changes into the library. I am preparing a v4
of lazysodium which will include all the new changes to the core libsodium project.
Stay tuned 👍
from lazysodium-java.
Thank you! Looking forward to the release!
from lazysodium-java.
Related Issues (20)
- Upgrade JNA to latest HOT 1
- Problems with resolving resource-loader dependency through OSGI HOT 2
- Padding methods take wrong data type HOT 7
- Support passing byte arrays to lazy methods instead of strings HOT 2
- Lazy Sodium on an M1 mac is not able to load libsodium properly HOT 13
- Lazysodium 5.1.1 doesn't load libsodium for Rocky Linux 8 HOT 1
- libsodium.so can't be loaded on Raspberry Pi OS due to missing libssp.so.0 library HOT 1
- 5.1.2 is not released to maven HOT 3
- ShortHash 'in' expected in hex format?
- Bundled sodium.dll cannot be loaded when path to JAR contains spaces HOT 1
- Provide module information HOT 1
- classes that support shortened number of parameters
- LazySodiumAndroid.cryptoKdfDeriveFromKey() throws an exception if key length exceeds 32 bytes
- help using sealed box for GitHub secret HOT 1
- LazySodium creates folders "resource-loader*" under /tmp folder HOT 1
- An error occurred with java. lang. NoClassDefFoundError
- sodiumHex2Bin silently accepts garbage input
- cryptoScalarMult takes inputs in the wrong order HOT 1
- Blake min bytes seems to be incorrect
- cryptoSign(String message, Key secretKey) does not use messageEncoder
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from lazysodium-java.