Replace whitelist and blacklist commands with better terms
#3447
Comments
|
Are you kidding? |
|
@ClemMakesApps I appreciate the concern but let's don't go down this path. Our terminology is based upon the behavior/functionality of the code, nothing more, and reflects accepted terminology. There's no need to change code which is intrinsically neutral based upon non-existent connotations to the ratio of melanin in people's skin. |
|
@Fred-Barclay It doesn't matter what the original intent was. People do have a negative reaction to these terms. There is no justification for keeping it. Over time, although you may intend them neutrally they do have negative impact. Many projects and groups have moved to the equally descriptive terms that avoid making people uncomfortable but are still equally descriptive. see rails/rails#33677 "To compound the issue, it is also striking how often the term “whitelist” is used for a supposedly good, respectable, or safe list of publishers [20, 22, 27]. The racism in such “black is bad, white is good” metaphors is inappropriate and needs to cease. The black-white dualism explicit in these binary terms is often associated with Western thinking that is usually traced back to the work of Rene Descartes. Although the epistemological dualism of Descartes may be seen in earlier works by Plato and Aristotle, this way of thinking is often associated with the Enlightenment and the subsequent scientific revolution and industrial development [28–30]. Thus, a foundational ontological dualism accepted by many people in Western cultures includes the supposedly “natural” divides between subject-object, body-spirit, human-nature, and self-other. Such dualism extends into our conceptions of good-evil, sacred/divine-profane, and civilized-heathen/barbarian [31]." https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6148600/ |
Some do and some don't, it's all in the 'Eye Of The Beholder'. There's no justification for not keeping it either, if this is nothing more than a plea to change a few words and call it quits. The conclusions drawn, and the subsequent (disputable) history lesson on ontological dualism feel out of place. Quoting research examining the emerging literature surrounding Regardless of the philosophy one subscribes to (if any), I wonder if anyone here actually believes that changing terminology would make supported applications run any more secure? This project is open to PR's, which are always reviewed on their merit in relation to the goal: reducing potential privacy/security risks when using Linux applications on a daily basis. Feel free to open. Another option is forking, like glimpse-editor did for example. |
|
What is currently difficult?
In order to allow baz in this profile, you need to add My suggestion for simplifying:
Examples:Old: New: Still uncertainMaybe Reasons against itIt's a breaking change. |
|
Usually in security terminology |
|
@rusty-snake I for one would support the If I understand correctly, this wouldn't really be a breaking change, since we can just interpret the original commands and emit warnings to help users with the migration. Eventually, we could deprecate There could also be arguments having "whitelisting" / |
👍 We can the remove nodbus and these in 0.9.66.
I would favour BTW: such a whitelist on/off switch will be very usefull Related issues: (mostly affected through #504: whitelist in ~/.local/share and other (mostly dotfiles) subdirs of $HOME |
|
Sounds like some solid technical reasons for a change 😄 EDIT: assuming we made these changes EDIT 2: should we reopen this issue? |
It's a shame that the original premise wasn't deemed sufficient enough for a change but I'm glad this change is still happening even if it is for another reason. |
I would say yes. |
|
@ClemMakesApps Thanks for bringing it to our attention! Even if we disagree on the premises it seems a change was needed 😄 |
|
Let's wait for a while to see in what direction the big guys are going, so we don't have to change it again in a few months. Whitelist/blacklist are heavily used in various places:
|
|
With Examples from similar, rather old (1990s) software using
MAC systems:
Firewalls:
IMHO white and black are used in white/blacklists without much of a preference, both are "good" and the "evil" is not using either. Whitelisting is preferred in many cases, but there are also situations where blacklisting is better. |
|
Now this. It's going to be a hell of a summer this time around... |
As someone who has written firejail profiles since firejail 0.9.38 and STILL sometimes gets tripped up by this, if I could expand on @rusty-snake suggestion above? I'm glad something will be done about that. Though I have few technical concerns about the current suggestion as-is. For one, I'm not sure And IIUC the suggestion above would take away the possibility provided by current So here's a tweak of @rusty-snake suggestion that would
And the new directive to enable the functionality currently called "whitelisting": (I would think Taking the example above:
Suggested: there would be two ways to do this - or |
|
Add VMware to the list of major players seeing fit to step up. |
|
I recently thought about @laniakea64 ideas in #3447 (comment). Based on this I extend my #3447 (comment) draft with
About the implementation version. firejail 0.9.64 should not have it, it should be released in the next week (but not before the appimage bug is fixed). Then we can implement it. I have no problem when we replace it without backward-compatibility. And provide a transition-script/flag. We can then move from a felt 0.9.VERSION[.PATCH] version-shema to firejail 1.0 🎆 . |
|
+1 for |
|
So where are we?
If a file has a
In addition: Why do we need Examples: Old: New: |
I see this could be helpful for the typical case. But wouldn't it be confusing if someone wanted to allow a file that does not yet exist? With the current proposal, that would look like - That confusion could be alleviated by, in addition to |
|
or we use Now 0.9.64 is out. Let's go. |
|
There is now an industry wide effort |
|
I'll add this one from Linux kernel: |
|
Before I forget it again to comment. The old: new: |
|
Moving the discussion here: #4379 |
This reverts commit fe0f975. Note: This only reverts the changes from etc. The 4 aliases introduced on commit 45f2ba5 are mere, well, aliases. That is, they fail to address the different usability problems discussed on [netblue30#3447][3447] and in fact only make things more confusing (as has already been mentioned on [this][4379] and later comments). The main reason is that the aliases do not meaningfully map to the original commands. For example, the commands from each pair below seem like they would do the exact same thing: * `allow` and `nodeny` * `deny` and `noallow` Additionally, if these aliases are not the final commands, but only a test/work-in-progress, then keeping the wide-scale search/replace changes made on commit fe0f975 would only serve to cause confusion, as users of firejail-git, contributors and downstream projects might start changing the commands used on their profiles, only to later have to change them again, potentially to completely different commands. The sooner this is undone the better, as (besides the above reasons) the more profile changes there are between the original commit and the revert, the harder it is to e.g.: `git diff` versions of files across the following revision ranges: before the commit, after the commit but before the revert and after the revert. Note: This is still the case even if a commit is [ignored by `git blame`][4390]. So let us revert fe0f975 and only reapply similar large-scale changes once we have discussed and settled on better commands. How the revert was applied: Despite using the auto-generated message from `git revert`, to ensure correctness and to avoid conflicts the changes were reverted in different steps: Firstly, revert the files which can be safely reverted directly ("filestorevert"): # Find out which files have been changed on fe0f975, but have not # been changed afterwards and list them on "filestorevert" git show --pretty='' --name-only fe0f975 -- etc | LC_ALL=C sort >allfiles git diff --name-only fe0f975..master -- etc | LC_ALL=C sort >filestoignore comm -2 -3 allfiles filestoignore >filestorevert # Note: There are 3 extra files on filestoignore because they were # added after commit fe0f975 wc -l allfiles filestoignore filestorevert | head -n 3 # 797 allfiles # 8 filestoignore # 792 filestorevert # Automatically revert files in "filestorevert" # See https://stackoverflow.com/a/23401018/10095231 tr '\n' '\000' <filestorevert | xargs -0 git show fe0f975 -- | git apply --reverse printf 'Total files reverted:\n' git diff --name-only | wc -l # 792 Secondly, do some search/replace on the rest: tr '\n' '\000' <filestoignore | xargs -0 sed -i.bak \ -e 's/allow /whitelist /' -e 's/noallow /nowhitelist /' \ -e 's/deny /blacklist /' -e 's/nodeny /noblacklist /' \ -e 's/deny-nolog /blacklist-nolog /' find etc -name '*.bak' -print0 | xargs -0 rm Thirdly, verify the result. The following command shows the difference between all the changes in etc from before fe0f975 and this commit (inclusive): git diff fe0f975~1 -- etc From the output, it looks like all alias changes are fully reverted and that the other changes to etc (from after fe0f975) remain, so the revert seems to be done correctly. [3447]: netblue30#3447 [4379]: netblue30#4379 (comment) [4390]: netblue30#4390
This comment was marked as spam.
This comment was marked as spam.
Since
Whitelist/Blacklisthave connotations about value and map to racial terms, we should replace those commands in this project withAllowlistandDenylistor something similar.The text was updated successfully, but these errors were encountered: