why resets `desktop-file-edit` the permissions of a file?

let's say i have set the umask system-wide to 027 via a one-liner at /etc/profile.d/ on a multiuser-system. after some time resp. reboots i want to hide an existing desktop-file system-wide from the menu with the following commands:

# just in case the folder doesn't exist, create it:
sudo install -o root -g root -m 755 -p -d '/usr/local/share/applications/'

# copy the existing desktop file and preserve all attributes (which are permissions 644 for the old & new file):
sudo cp -vi --preserve=all '/usr/share/applications/application.desktop' '/usr/local/share/applications/'

# add or change the existing key to true:
sudo desktop-file-edit --set-key=NoDisplay --set-value=true '/usr/local/share/applications/application.desktop'

it kind of works, **but** not as intended: if you open alacarte this desktop-file is still activated but not shown in the menu! with a closer look at /usr/local/share/applications/ the reason can be found... the permissions of application.desktop are 640 instead of 644, so the file would still be shown but it can't be read by the normal user and hence it doesn't show up in the menu *(and therefore the correctly set NoDisplay=true does not really mater in this case)*. i even tried to the add the option -m 644 mentioned at the man page, but it seems to be exclusively for desktop-file-install. 1. is this behavior intended? and if so, why? 2. is there an easy workaround instead of using an appended chmod? 3. why does editing a file, change the permissions of it at all?!?