Decide how to sensibly handle the execute bit (with regard to #443)
Arising from #443, there is a sort-of blocker for implementing that proposal.
It is unclear whether to fully trust an executable with the "execute" bit set or not. This is because, in some cases the user must set this bit manually, sometimes it is there without user intervention.
In cases where the user sets the bit manually, perhaps this indicates they trust and wish to execute the program. Certainly this is part of the workflow when a user intentionally enables and runs a program, assuming the bit had not already been set.
On the other hand,
.tar.gz archives and similar archiving formats preserve the execute bit if it was set before the file(s) were archived/compressed. This is a case where the end-user may not be indicating any trust or "intent to execute" toward the contents of the compressed archive.
Suggestions (see #443) have included:
- "Always trust an executable if the execute bit is set"
- Same, but with modifications to File Roller and other programs as needed, so as to warn the user about execute bit and the dangers of running unknown or untrusted programs, etc
- A whitelisting system that knows which executables are trusted/may be executed from Nautilus (And probably a way to trust an executable / add it to the whitelist from Nautilus GUI itself)
- Variations on the previous bullet, with debate over whether metadata should be added to the file, whether there should be a central whitelist, or might I suggest: metadata adjacent to the file in the same subdirectory?