I suggest to use Flatpak instead of AppImage, that way you can update all your apps at the same time with GNOME Software, Plasma Discover or flatpak command line interface:
I used app image launcher for some time, but I’ve switched to flatpak later–the updates work automatically, no drawbacks, so I recommend looking into that instead that as well.
I have installed flatpack and when running ‘flatpak run com.logseq.Logseq’ Logseq opens and works as before, it took a while to realize I had to update theme and plugin to see icons on top line.
I notice that there are some errors/warnings in the terminal
➜ ~ flatpak run com.logseq.Logseq
[3:0310/102419.915203:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory
(rsapi) init loggers
LaunchProcess: failed to execvp:
xdg-settings
Gtk-Message: 10:24:36.190: Failed to load module "appmenu-gtk-module"
Gtk-Message: 10:24:36.208: Failed to load module "canberra-gtk-module"
[3:0310/102438.462298:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory
[3:0310/102438.462396:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory
LaunchProcess: failed to execvp:
xdg-settings
10:24:44.916 › Logseq App(0.10.7) Starting...
10:24:45.176 › restore proxy settings {:type "system"}
10:24:45.179 › set proxy to {:type "system"}
libva error: /usr/lib/x86_64-linux-gnu/dri/intel-vaapi-driver/iHD_drv_video.so init failed
marketplace checks for updating plugins and themes
Warning: vkCreateInstance: Found no drivers!
Warning: vkCreateInstance failed with VK_ERROR_INCOMPATIBLE_DRIVER
at CheckVkSuccessImpl (../../third_party/dawn/src/dawn/native/vulkan/VulkanError.cpp:88)
at CreateVkInstance (../../third_party/dawn/src/dawn/native/vulkan/BackendVk.cpp:458)
at Initialize (../../third_party/dawn/src/dawn/native/vulkan/BackendVk.cpp:344)
at Create (../../third_party/dawn/src/dawn/native/vulkan/BackendVk.cpp:266)
at operator() (../../third_party/dawn/src/dawn/native/vulkan/BackendVk.cpp:521)
[44:0310/102639.740171:ERROR:gl_display.cc(520)] EGL Driver message (Error) eglCreateContext: Requested GLES version (3.1) is greater than max supported (3, 0).
Warning: eglCreateContext failed with EGL_BAD_ATTRIBUTE
at CheckEGL (../../third_party/dawn/src/dawn/native/opengl/UtilsEGL.cpp:71)
at Create (../../third_party/dawn/src/dawn/native/opengl/ContextEGL.cpp:88)
at Create (../../third_party/dawn/src/dawn/native/opengl/PhysicalDeviceGL.cpp:97)
Updating Logseq via Flatpak/Flathub sounds like a good idea. But first I would like app to be verified by the original developer, which then gets a signed checkmark. Lots of apps already provide this safety feature. More infos here: Verified apps.
I suggested many times to devs to apply for ownership on FlatHub but they didn’t reply.
Anyway, the build happens automatically using GitHub Actions both in the Logseq repo and on FlatHub, all the code is public.
The weak link remains GitHub Actions and to trust it reproducible builds are needed. The “verified” badge would not change anything. If I remember correctly Logseq on FlatHub has reproducible builds. You can check by building the Flatpak package locally and compare the checksums.
Releases are built by github-actions user as indicated on the releases page.
This imo would be called a reproducible build. What part makes you think otherwise (speaking of Linux Desktop version)? I’ve heard about the sync implementation being closed-source, but currently can’t find anything surprising in that build file.
The “verified” badge would not change anything.
I think we agree this badge in general is useful for verification. And non-ownership is a potential trust issue. All downstream reproducible GitHub action builds won’t help, if you got a scam package on Flathub impersonating original developer. Or if an automatic package update includes “surprising” content, due to the distribution channel not being owned by the origional devs, despite having the official app name.
It’s reproducible if the checksums match, otherwise it would be useless. The point is trusting a process that from time to time anyone can check by reproducing the build and comparing the checksums. If someone (Logseq devs or GitHub) tries to distribute altered builds it would be found out. Indeed this is why Telegram implements reproducible builds, for example.
I asked them to public it and in the end they made it available, so Logseq is fully FOSS client-side
Yes, but more as an indication that the upstream devs recognize that FlatHub app as an officially supported way to install their app.
When it comes to Logseq, there is always GitHub as gatekeeper and only reproducible builds can guarantee you are running the actual public code:
Yes, this is the logical consequence, if all above described conditions are met.
If both Flathub and GitHub Action builds are reproducable, unauthorized modificiations can be detected by inspecting the build. Personally I don’t have time (and desire) to do that for all used apps. Besides, you would need to do this on every app update, as build might point to different sources at any future point in time, as not owned by devs.
With a Flathub verified checkmark, I can put trust in original developer without any third-party involved, and not bother with downstream builds. It also illustrates, that reproducible builds and badges cover different aspects of integrity - former detects changes, latter verifies identity. I think there is a trade-off between security, convenience and knowledge - with that badge non-technical users can do simple safety checks on their own.
No, it’s not enough. For reproducibility you need additional conditions, like not downloading extra code during the build, so you need to check building script line by line. It’s not enough for them to be public. For example, all packages by Debian have a public build process but only some of them have reproducible builds.
You can’t inspect the build…
This is why reproducible builds are important, because anyone can check from time to time, there is no need for every individual to reproduce every version.
This is not what that checkmark is for, as I said it’s only to mark a Flatpak repo as an official way to install an app.
See the diagram I made: when it comes to Logseq, there is no difference since GitHub is the only gatekeeper, both for AppImage builds by Logseq and Flatpak ones by FlatHub.
Indeed it is misleading. That badge should say something like “Official” instead of verified.
Did you read the source I have given? The very definition of reproducible build is
A build is reproducible if given the same source code, build environment and build instructions, any party can recreate bit-by-bit identical copies of all specified artifacts.
I don’t see what “additional conditions, like not downloading extra code during the build” adds to above argument… If you don’t agree with these statements, I suggest to add a contribution at reproducible-builds.org.
Please don’t twist the word around. I’ve the slight feeling you consciously intent to read something different out of the context in order to justify your statements.
Sometimes that is too late, despite brought to public eventually. There are lots of scam examples for other software repositories like npm and PyPI.
This is your opinion. Quoting Flathub:
A verified app is an app that is published on Flathub by its original developer or a third party approved by the developer.
, again with the hint to spread wisdom to their domain experts, as you seem to disagree with just everything.
Well, it depends on the threat model. If GitHub is your main concern, that might be right. I’d argue, unauthorized third-party scam developers are the major evil (generally speaken, not concerning Logseq).
Honestly I don’t like your unpolite way of communicating, I am out of the discussion.
Please use the right terms: if by “build” you mean the build process, say “the build process”. Anyway, the right statement would be “if the ones on GitHub are reproducible builds, one can check by building locally and compare the checksum”; this is the only way to check if the builds on GitHub are built using the build process specified in the GitHub Actions.
GitHub has a reputation to protect and one can sue GitHub if malicious actions are found. You can’t compare GitHub to anonymous users who upload on PyPi.
FlatHub says exactly what I said, it’s you who gave an interpretation. They don’t say it’s a security measure, it’s about being an official supported by upstream installation method.
Try to make an app added to FlatHub. The approval process has nothing to do with the one of PyPI & Co. FlatHub is more like Linux distros. New contributions are carefully reviewed and approved. The “verified” checkmark is just to say that upstream has been involved.
Well I don’t like to discuss with people who can’t even read basic English.
