Running Peergos with custom native-lib path still creates native-lib in current path

[raspher]

Discovered while packaging peergos on NixOs. When i run java -Djava.library.path=result/share/peergos/native-lib/ -jar result/share/java/peergos.jar it creates native-lib/libtweetnacl.so in current pwd.

#: java -Djava.library.path=result/share/peergos/native-lib -jar result/share/java/peergos.jar 
Jan 22, 2024 10:11:34 AM peergos.server.util.Logging init
INFO: Logging to /home/raspher/.peergos/peergos.0.log
Run with -help to show options

What i'm doing:

1. get https://github.com/Peergos/web-ui/releases/download/v${version}/Peergos.jar to $out/share/java/
2. mkdir -p $out/share/peergos && cd $out/share/peergos
3. run peergos to generate native-libs in this directory for current architecture
4. create a wrapper (by using $out/bin/peergos user can pass arguments without typing java ...)

As you may saw, running java -Djava.library.path=result/share/peergos/native-lib -jar result/share/java/peergos.jar does not spam about To use the native linux-x86-64 crypto implementation use option -Djava.library.path=native-lib but it still creates native-lib in pwd instead of just using provided java.library.path

Related work can be found here: NixOS/nixpkgs#282470

[ianopolous]

Currently we only support using a native-lib dir in pwd. Is that a problem for nixos?

[raspher]

Well, it's not problem with specific OS but rather problem with user experience and consequences. If you run peergos in multiple places (no matter why, today it was ~/Downloads, yesturday ~/Desktop) you'll have multiple places with created native-lib directory.

Every system have special places to put user applications data:

• linux: do it inside ~/.local/share/peergos
• windows: %appdata%/somewhere_here_idk
• macos: idk, never have had

[raspher]

There is also simpler option which fixes problem for all systems and architectures:

• if native-lib path is specified, search in specified patch, if not found, create in specified path and use specified path instead of pwd
• if native-lib path is not specified or it cannot be created, use pwd

[ianopolous]

The file is 32kb so shouldn't cause anyone any problems, even with 1000 copies of it. Peergos creates a bunch of other files in the ~/.peergos dir by default (mainly sqlite files), though this can be controlled with the -PEERGOS_PATH arg or env var.

We only use native-lib on x86 + linux. No other arch is supported, but everything still works fine.

[raspher]

Yeah, it works i am not saying it is not working. But thrust me, if you run peergos inside your home directory and it poops a folder there. Don't tell me you'd like to have for each application you have 1 poopped folder on your desktop. Especially when you can run it in multiple places...

[ianopolous]

Yep, people can control the .peergos dir with the arg above.

[ianopolous]

the native-lib is the only thing not in that dir we create, but it is an arg to the JVM, not to peergos. So we don't actually get the arg in peergos.

[raspher]

So how it's created?

[ianopolous]

It's basically tweetnacl.c.

[raspher]

I am not asking what is that file or what is inside this folder.

Issue here is that it's created in current pwd. Better place for this file would be ~/.peergos or even /tmp.

[ianopolous]

This is a philosophical question of whether you want to separate data from code. This lib is code and so really belongs where the jar is. At least that's why it is where it is now. I guess we could put it in .peergos, I don't feel strongly either way.

[raspher]

Native-libs is not created inside the jar path, but it is created in the current directory. If you call java -jar /usr/opt/peergos/peergos.jar from ~/Downloads, then it is created in ~/Downloads.

It would be nice if it creates native-libs inside jars path (in this example /usr/opt/peergos, but keep in mind different distributions have different standards for file locations, so it cannot be hard coded)

[ianopolous]

Yep we assume you run the jar from the current dir.

I'll see what I can do.

[rapenne-s]

This is also an issue in the container version in which we can only add parameters after java -jar Peergos.jar, so we can't inject the parameters to use native-libs without having them being interpreted as Peergos parameters.