Untrusted application launcher problem (Bookworm DDOG - XFCE/Thunar 4.18)

[dcung]

Hi @fredx181

I experienced this in DDOG DE, I have same issue like what is described here.
https://forum.xfce.org/viewtopic.php?id=16903

But I have my .desktop files in /root/Desktop instead.
I tried as suggested (suggestion 2) in the link above and it works.

Code: Select all

thunar -q
export XDG_DATA_DIRS=$XDG_DATA_DIRS:/root/Desktop
Thunar --daemon &

Now, how/where is the 'best' place to put XDG_DATA_DIRS in DDOG?
I have read and experimented few places as suggested by following link
https://unix.stackexchange.com/question ... -data-dirs

I tried putting/adding it in /etc/environment , or .session

Code: Select all

XDG_DATA_DIRS=/root/Desktop:$XDG_DATA_DIRS
export XDG_DATA_DIRS

or in .xsessionrc by running this in terminal to create the file

Code: Select all

echo export 'XDG_DATA_DIRS="$XDG_DATA_DIRS:/root/Desktop"' >> ~/.xsessionrc

But it always failed to finish booting to X desktop, and drop to # prompt instead.

[fredx181]

@dcung Adding to ~/.bashrc works for me, e.g. :
echo 'export XDG_DATA_DIRS=$HOME/Desktop/${XDG_DATA_DIRS:+:$XDG_DATA_DIRS}' >> .bashrc
Or just echo 'export XDG_DATA_DIRS=$HOME/Desktop/' >> .bashrc
Check after re-login:

Code: Select all

root@live:~# echo $XDG_DATA_DIRS
/root/Desktop/
root@live:~# 

I tried putting/adding it in /etc/environment , or .session

Code: Select all

XDG_DATA_DIRS=/root/Desktop:$XDG_DATA_DIRS
export XDG_DATA_DIRS

Note btw that this :
XDG_DATA_DIRS=/root/Desktop:$XDG_DATA_DIRS
would give wrong output: /root/Desktop: (with colon appended), it's because XDG_DATA_DIRS shows as empty by default on Debian.

[dcung]

@dcung Adding to ~/.bashrc works for me, e.g. :

Or just echo 'export XDG_DATA_DIRS=$HOME/Desktop/' >> .bashrc
Check after re-login:

Code: Select all

root@live:~# echo $XDG_DATA_DIRS
/root/Desktop/
root@live:~# 

I added to ~/.bashrc as above, and check that the variable XDG_DATA_DIRS has correct value after rebooting (ie. /root/Desktop/).
It finished booting as normal to X desktop now.

But "Untrusted application launcher" still appeared.
Not sure what happened.

[fredx181]

..
I added to ~/.bashrc as above, and check that the variable XDG_DATA_DIRS has correct value after rebooting (ie. /root/Desktop/).
It finished booting as normal to X desktop now.

But "Untrusted application launcher" still appeared.
Not sure what happened.

Could it be that only new added launchers become 'trusted' after setting XDG_DATA_DIRS env ?

Perhaps make them all executable at once: chmod +x /root/Desktop/*.desktop

[dcung]

Could it be that only new added launchers become 'trusted' after setting XDG_DATA_DIRS env ?

Probably not, since if I do manually

Code: Select all

export XDG_DATA_DIRS=$XDG_DATA_DIRS:/root/Desktop
Thunar --daemon &

and run them, all existing .desktop are okay.
No "Untrusted application launcher" message.

Perhaps make them all executable at once: chmod +x /root/Desktop/*.desktop

I checked that they are already all executable, but I re-did it anyway...still no luck.

Code: Select all

root@live:~/Desktop# ls -las
total 50
0 drwxr-xr-x 2 root root  396 Mar 12 20:05 .
8 drwxr-xr-x 1 root root 4096 Mar 25 18:52 ..
5 -rwxr-xr-x 1 root root 4150 Mar 12 20:05 audacious.desktop
1 -rwxr-xr-x 1 root root  176 Mar 12 20:05 conkytoggle.desktop
1 -rwxr-xr-x 1 root root  185 Mar 12 20:05 DebianDog-Installer.desktop
1 -rwxr-xr-x 1 root root  158 Mar 12 20:05 DogRadio.desktop
1 -rwxr-xr-x 1 root root  293 Mar 12 20:05 epsonscan2.desktop
4 -rwxr-xr-x 1 root root 3416 Mar 12 20:05 exo-terminal-emulator.desktop
1 -rwxr-xr-x 1 root root  157 Mar 12 20:05 firefox.desktop
9 -rwxr-xr-x 1 root root 8473 Jan 21  2019 google-chrome.desktop
4 -rwxr-xr-x 1 root root 3623 Mar 12 20:05 grsync.desktop
2 -rwxr-xr-x 1 root root 1829 Mar 12 20:05 leafpad.desktop
1 -rwxr-xr-x 1 root root  391 Mar 12 20:05 mtpaint.desktop
1 -rwxr-xr-x 1 root root  198 Mar 12 20:05 Remaster-porteus-wheezy.desktop
8 -rwxr-xr-x 1 root root 7579 Mar 12 20:05 smplayer.desktop
9 -rwxr-xr-x 1 root root 8670 Mar 12 20:05 synaptic.desktop

root@live:~/Desktop# chmod +x *.desktop
root@live:~/Desktop# ls -las
total 96
 8 drwxr-xr-x 1 root root 4096 Mar 12 20:05 .
 8 drwxr-xr-x 1 root root 4096 Mar 25 18:52 ..
 8 -rwxr-xr-x 1 root root 4150 Mar 12 20:05 audacious.desktop
 4 -rwxr-xr-x 1 root root  176 Mar 12 20:05 conkytoggle.desktop
 4 -rwxr-xr-x 1 root root  185 Mar 12 20:05 DebianDog-Installer.desktop
 4 -rwxr-xr-x 1 root root  158 Mar 12 20:05 DogRadio.desktop
 4 -rwxr-xr-x 1 root root  293 Mar 12 20:05 epsonscan2.desktop
 4 -rwxr-xr-x 1 root root 3416 Mar 12 20:05 exo-terminal-emulator.desktop
 4 -rwxr-xr-x 1 root root  157 Mar 12 20:05 firefox.desktop
12 -rwxr-xr-x 1 root root 8473 Jan 21  2019 google-chrome.desktop
 4 -rwxr-xr-x 1 root root 3623 Mar 12 20:05 grsync.desktop
 4 -rwxr-xr-x 1 root root 1829 Mar 12 20:05 leafpad.desktop
 4 -rwxr-xr-x 1 root root  391 Mar 12 20:05 mtpaint.desktop
 4 -rwxr-xr-x 1 root root  198 Mar 12 20:05 Remaster-porteus-wheezy.desktop
 8 -rwxr-xr-x 1 root root 7579 Mar 12 20:05 smplayer.desktop
12 -rwxr-xr-x 1 root root 8670 Mar 12 20:05 synaptic.desktop
root@live:~/Desktop# 

More investigation to do...

The link said that XDG_DATA_DIRS need to exist before Thunar daemon starts.
So maybe, this is the issue? Putting it in .bashrc is already too late (?)

You could try adding that path to your $XDG_DATA_DIRS. Something like:

XDG_DATA_DIRS=$XDG_DATA_DIRS:/media/user/FLASH_DRIVE/apps

...so that is allowed, but how will you do that on a live system? You'd need to set this during Xfce start, or at least before "Thunar --daemon" start.

[fredx181]

@dcung Strange... a .desktop launcher that's made executable shouldn't give the 'untrusted' warning.
I tested on DDOG with the XDG_DATA_DIRS set to /root/Desktop and it works without problems, no need to do anything else, e.g. Thunar --daemon & .

[dcung]

@dcung Strange... a .desktop launcher that's made executable shouldn't give the 'untrusted' warning.
I tested on DDOG with the XDG_DATA_DIRS set to /root/Desktop and it works without problems without needing to do anything else, e.g. Thunar --daemon & .

Yes, that's because your conf is using pup-volume-monitor.

This issue is only if using gvfs.
Some of my builds, I substituted pup-volume-monitor with gvfs.

[fredx181]

@dcung Strange... a .desktop launcher that's made executable shouldn't give the 'untrusted' warning.
I tested on DDOG with the XDG_DATA_DIRS set to /root/Desktop and it works without problems without needing to do anything else, e.g. Thunar --daemon & .

Yes, that's because your conf is using pup-volume-monitor.

This issue is only if using gvfs.
Some of my builds, I substituted pup-volume-monitor with gvfs.

Ah, cannot test that atm, yes that makes the difference.

[fredx181]

@dcung A hard one to crack !
Tested now with gvfs and I think that I found a solution/workaround.
Following from here https://forum.xfce.org/viewtopic.php?id=16903 works for me to make all launchers "trusted", but needs gio (edit: from package libglib2.0-bin):
for f in /root/Desktop/*.desktop; do gio set -t string "$f" metadata::xfce-exe-checksum "$(sha256sum "$f" | awk '{print $1}')"; done

Script for in ~/Startup to monitor new added .desktop launchers constantly ((needs inotifywait, from package "inotify-tools"):

Code: Select all

#!/bin/bash

# uncomment if done already for the existing .desktop files in /root/Desktop
for f in /root/Desktop/*.desktop; do gio set -t string "$f" metadata::xfce-exe-checksum "$(sha256sum "$f" | awk '{print $1}')"; done

# monitor new added .desktop launchers (needs inotifywait, from package "inotify-tools") 
inotifywait -m /root/Desktop -e create -e moved_to |
    while read path action file; do
        if [[ "$file" =~ .*desktop$ ]]; then # Does the file end with .desktop?
            echo "$path $file" # If so, do your thing here!
#        chmod +x "$path/$file"
gio set -t string "$path/$file" metadata::xfce-exe-checksum "$(sha256sum "$path/$file" | awk '{print $1}')"
        fi
        
# adjust sleep time as preferred
sleep 2
    done

EDIT: From what I tested there's no need to set XDG_DATA_DIRS if using the above.
edit later: there was a small mistake in the Startup script, fixed now.

[rockedge]

This appears in KLV's time to time.........found that it only happens in a certain scenario during the first system startup.....a system reboot fixes it.

[fredx181]

This appears in KLV's time to time.........found that it only happens in a certain scenario during the first system startup.....a system reboot fixes it.

It's default in KLV (with XFCE) that you get "untrusted" message after you copy a .desktop launcher to the Desktop and run it.
A reboot might help for already existing launchers, but if you add a new one (and run it), the warning dialog appears again.
The startup script above should fix it.

[dcung]

@dcung A hard one to crack !
Tested now with gvfs and I think that I found a solution/workaround.
Following from here https://forum.xfce.org/viewtopic.php?id=16903 works for me to make all launchers "trusted", but needs gio (edit: from package libglib2.0-bin):
for f in /root/Desktop/*.desktop; do gio set -t string "$f" metadata::xfce-exe-checksum "$(sha256sum "$f" | awk '{print $1}')"; done

I have been using the gio / for f in /root/Desktop/*.desktop; do gio set -t string "$f" metadata::xfce-exe-checksum "$(sha256sum "$f" | awk '{print $1}')"; done since I noticed it last year or so when I first used gvfs. (I found it at another posting back then).
I made a thunar-trust.squashfs with the gio needed stuff and do the metadata thing to all my .desktop, each time I used a new build. And unload the SFS. That's how I workaround it since then.

But, like the OP of https://forum.xfce.org/viewtopic.php?id=16903 , I think the XDG_DATA_DIRS is a 'better' solution (if it can work in DDOG). I don't like having to do the metadata/loading gio each time I used a new DDOG build.
The gio/metadata way is ok, if you don't do it frequently. But for me (and the OP of the link), this is an 'inconvenience', since we have to repeat the procedure each time (new build for me, and similar to OP).

I just couldn't figure out when/where to set XDG_DATA_DIRS 'early' enough in DDOG (yet).

[dcung]

It's default in KLV (with XFCE) that you get "untrusted" message after you copy a .desktop launcher to the Desktop and run it.
A reboot might help for already existing launchers, but if you add a new one (and run it), the warning dialog appears again.

That's why I think XDG_DATA_DIRS way is 'better', in the sense that it sets the 'allowed' / 'trusted' location wherever we point to (and no need for gio).

[fredx181]

...
But, like the OP of https://forum.xfce.org/viewtopic.php?id=16903 , I think the XDG_DATA_DIRS is a 'better' solution (if it can work in DDOG). I don't like having to do the metadata/loading gio each time I used a new DDOG build.

I think what the second poster of https://forum.xfce.org/viewtopic.php?id=16903 calls "tough" may be right:

Or alternatively, something like:

thunar -q
export XDG_DATA_DIRS=$XDG_DATA_DIRS:/media/user/FLASH_DRIVE/apps
Thunar --daemon &

...but that will only work while that Thunar --daemon process is running.

That's about the problem that I experienced too, the Thunar --daemon process isn't always running, may be not anymore e.g. at the point that you open a folder with Thunar.
(check with e.g. ps aux | grep "Thunar --daemon")
edit: For without gvfs I think that the XDG_DATA_DIRS env setting works well, but with gvfs ... it might be impossible, not 100% sure though.

[dcung]

I think what the second poster of https://forum.xfce.org/viewtopic.php?id=16903 calls "tough" may be right:

Yes...
The 'good thing' is that I seem to use LXQT DE more now than DDOG DE ...
It used to be the other way around.

[fredx181]

@dcung

I don't like having to do the metadata/loading gio each time I used a new DDOG build.
The gio/metadata way is ok, if you don't do it frequently. But for me (and the OP of the link), this is an 'inconvenience', since we have to repeat the procedure each time (new build for me, and similar to OP).

Maybe I don't understand well, anyway...
No repeating necessary IM0, probably works OOTB if you make a new build (including gvfs) with libglib2.0-bin and inotify-tools installed and add the startup script from here viewtopic.php?p=145405#p145405 in chroot/root/Startup/

[rockedge]

The startup script above should fix it.

It seems to be working on KLV-Airedale!

Sometimes it does not happen but I can't pin down why it does sometimes and other times the untrusted message appears. Also I have seen that the untrusted launcher problem doesn't happen after the first reboot and the system starts after that. I see it a lot on QEMU virtual machines with the reboot fixing it.

Overall my report is that it the program appears to work, is being further tested and now considering putting it into the KLV-Airdale default root file system starting with sr18

Good work @fredx181

[dcung]

Maybe I don't understand well, anyway...
No repeating necessary IM0, probably works OOTB if you make a new build (including gvfs) with libglib2.0-bin and inotify-tools installed and add the startup script from here viewtopic.php?p=145405#p145405 in chroot/root/Startup/

I didn't feel it was 'justified' at the time for the extra space/CPU resources. For me I usually only run thunar-trust once. I didn't want the extra stuff/load,
Hence, I created a squashfs instead back then that I load/unload when I work on fresh install somewhere.
I'm pretty sure putting it in Startup the way you described will work.
I'm away atm, I will make a new build with your script at some point.

I came across XDG_DATA_DIRS while reading the net few days ago, and thought this is handy if it can work.
Hence I started experimenting. No loss from my point of view. I always learn something when I ask questions here,,,

Anyway, now I know there are few different ways to tackle this, with each pros and cons (for me).

[rockedge]

@fredx181

I tested the script in a KLV-Airedale-sr17 running on VirtualBox installed on the host Noblepup64 with good results. The VirtualBox I installed using the instructions from here -> viewtopic.php?p=145402#p145402

I inserted the script named as monitor_launchers in ~/Startup and restarted the VM and then dragged a launcher from the Whisker Menu to the desktop and there was no untrusted launcher messages at all