I’ve had a casual look at this, and while I’ve not spotted anything outright malicious, there’s some obfuscation in the init scripts that give me cause for concern.
I.E., the snap command points to a shell script, the shell script then points to another script that ultimately runs the Electron package that this ships with. This concerns me because it’s not obvious whats actually being executed and it seems to be somewhat flexible.
HERE="$(dirname "$(readlink -f "${0}")")"
EXEC=$(grep -e '^Exec=.*' "${HERE}"/*.desktop | head -n 1 | cut -d "=" -f 2- | sed -e 's|%.||g')
exec ${EXEC} "$@"
I’d compared this against what Snapcraft itself produces and against modern Core24 releases, there’s nothing like this at all. I do remember older cores were more liberal in their use of scripts like this, but cannot understand what the HERE is for. $SNAP is a hardcoded filesystem in a mount namespace. The binary path is literally immutable so it’s unnecessarily overengineered, there are no reasonable situations I can think of you’d need to seek out the binary to execute rather than know it’s where you’ve placed it yourself.
Ultimately, I run the snap on my own machine and it doesn’t actually work since it’s presumably missing libraries, and despite being strict, doesn’t use e.g., extensions to set up things like X11/Wayland/etc.
So while I don’t wanna say this is outright malicious, I would say, it will not be missed in its current state and I’d balance probability here with consequence, of which seems none, given it doesn’t work and has no active maintenance.
Edit: Looking at the source repo, the AppRun subset makes sense, the exec is dynamic because an AppImage would extract to /tmp/random-path-12345 and so the exec does need to be relative to the AppImage mount point rather than hardcoded. Concerns there have diminished but ultimately this is still a no-op snap as is and the upstream source is not reproducable because the AppImage being used for the snap isn’t actually part of the snapcraft.yaml, i.e it’s simply on the disk by magic rather than using source:.
On the whole, even if it’s not malicious, an appimage cannot simply be converted into a snap ( and trust me, I’ve actually tried to trick snapd into running a hypothetical AppSnap before! Due to magic numbers checking, it doesn’t work, but I have thought a well designed SquashFS bundle could be validly a self extracting AppImage and also a sandboxed snap at the same time 
), so I’d be in favour of removing this simply because its broken.
