ipfs-desktop > Trace/breakpoint trap

[commandline-be]

installed from latest .deb on a debian derivate

on launch
$ipfs-desktop
$Trace/breakpoint trap

[alphanmoon]

The same issue on Debian 10 after .deb install:
$ipfs-desktop
$Trace/breakpoint trap

And it's not starting from inside the xfce app menu.

[nekr0z]

Yep, I confirm on Debian 10.

[autonome]

Thanks for reporting, looking asap!

[lidel]

I believe it is the same problem as described in https://github.com/signalapp/Signal-Desktop/issues/3536.

IUUC this needs to be fixed in electron-builder responsible for creating .deb.
I've added this to v0.10.4 (#1343)

For now, available workarounds are:

• Run with additional parameter:
  ipfs-desktop --no-sandbox
  
  
  
  • This is what Signal does on Debian 10 too: https://github.com/signalapp/Signal-Desktop/issues/3627#issuecomment-536000779
  
  
• If you don't feel safe with that, you have two options:
  
  
  
  • enable user namespaces for unprivileged users by setting sysctl kernel.unprivileged_userns_clone=1
  
  
  • wrap execution in something like Firejail: firejail ipfs-desktop --no-sandbox
  
  

@commandline-be @alphanmoon @nekr0z
Let me know if any of this helped. If not, please share the output of uname -a

[commandline-be]

Thanks for the very informative response.

😁 I already hope for a rewrite in rust so this sandbox nonsense can be left behind.

[lidel]

Nonsense indeed.. I hoped for a generic fix, but Chrome/Electron sandbox situation on Linux is nearly as bad as the tray icon one (#1153) :upside_down_face:

Below is my brain dump. TL;DR: fix is in https://github.com/ipfs-shipyard/ipfs-desktop/pull/1370

---

As noted in https://github.com/ssbc/patchwork/issues/1217#issuecomment-560468383 and 99999 issues about --no-sandbox one can find on github, nobody seems to agree how to handle this mess.

• Debian: Disallow unprivileged CLONE_NEWUSER by default
• Electron/Chromium: Depend on unprivileged CLONE_NEWUSER or root SUID on chrome-sandbox, discourage --no-sandbox

Ugh.. ok. Even if we ignore security considerations of SUID and are okay with going that route... we can't. Not everywhere:

• AppImage / Snap: Reject packages with root SUID
  (https://github.com/electron-userland/electron-builder/issues/4495, https://github.com/electron-userland/electron-builder/issues/3608)

So.. what are our options given we are bound to Electron and electron-builder?

• I've seen folks hack around it by reimplementing linux packaging in sequential manner, setting setuid flags on everything linux related apart from appimage and snap
  (example in ElectronMail repo)
  
  
  
  • We have no bandwidth for writing nor maintaining that type of Rube Goldberg machine, and I am not sure if that is even the right thing to do in the first place. What If setuid hack is removed and all this work is for nothing?
  
  
• Best we can do for now is to set executableArgs to --no-sandbox in electron-builder.yml.
  
  
  
  • Done just that in https://github.com/ipfs-shipyard/ipfs-desktop/pull/1370 + updated deps where possible
  
  
  • This fixes GUI: will update Exec command in ipfs-desktop.desktop manifest that is run when menu item / icon in desktop environment is clicked.
  
  
  • CLI users can always add --no-sandbox manually – will update README.
  
  

[lidel]

Hi friends, fyi v0.10.4 shipfs with updated ipfs-desktop.desktop manifest which starts ipfs-desktop with --no-sandbox by default, restoring startup via GUI shortcut on Debian 10.