Talk: Logseq

The information about fixing full-text search is not needed because the issue is fixed https://github.com/NixOS/nixpkgs/issues/230212 and should be removed, correct?

Can we add more information about allowing insecure versions of electron (as that continues to not be fixed) (and can this be limited to one's per-user packages, and is there any benefit to that)?

How we can fix Logseq going forward

I've had a go at trying to update Logseq's package.nix, and I gave up due to my limited Nix knowledge, but I wanted to document these for anyone else braver than me. It is a fairly difficult task because of a combination of factors:

Logseq uses the also outdated Electron 31 in its yarn.lock. However, we could override the electron version in its package.nix; this wouldn't necessarily fix the problem, but it would presumably mitigate a chunk of the vulnerabilities.
The current approach to packaging apps is to build them from source. For a pure yarn package, that is tried and tested, with countless examples. Therefore, ideally, an update to this package would adhere to the best practices. See this coordinated effort PR and this example PR, and this previous Logseq PR touching on these issues. From what I can find, other packages with Clojure dependencies just repackage the released binaries, e.g.: *babashka*
However, Logseq uses a hybrid build using Clojure, CLJS, gulp and yarn. Now, building the yarn dependencies is more than achievable, but building the CLJS ones runs into issues because of the sandboxing. As it currently stands, Clojure can't resolve it's own dependencies without internet nor does it have a lockfile (which would allow us to pre-fetch its dependencies). See this discussion and this ticket.
Now, since (to my understanding) Clojure dependencies are the same as Java/maven modules for the most part, we could build each by itself and then import them as nativeBuildDependencies. However, we don't have an easy way of achieving that (as far as I can find) comparable to pythonXXXPackages, so any effort in this direction would have to implement it from scratch. And while I'm happy to support where I can, I know way too little Java/Clojure to even consider spearheading such an initiative.

Happy to help if there's any thoughts or suggestions. Doggobit (talk) 03:00, 25 February 2025 (UTC)