Please consider applying inclusive naming

[cpaelzer]

It might not be possible to discontinue the old key names in the config too quickly, but unattended-upgrades still uses non inclusive naming like blacklist/whitelist in config, output and code. At least some could be tackled without incompatibilities with old config files I guess?

Example:

$ sudo unattended-upgrade --verbose
Starting unattended upgrades script
Allowed origins are: o=Ubuntu,a=jammy, o=Ubuntu,a=jammy-security, o=UbuntuESMApps,a=jammy-apps-security, o=UbuntuESM,a=jammy-infra-security
Initial blacklist: 
Initial whitelist (not strict): 
No packages found that can be upgraded unattended and no pending auto-removals

[adam-vest]

Seconding the request! I came here to make the same suggestion after seeing it - would very much like to see the wording changed. allowlist/denylist are pretty standard go-to's for those.

Thanks!

[dchenbecker]

Usually this is handled with aliases, although this is more than just the configuration format, since there may be downstream scripts or processes that parse output. I think it could be done with separate aliases for configuration and an option for output strings. For context, here's a good explanation on why blacklist/whitelist are problematic: https://www.splunk.com/en_us/blog/learn/blacklist-whitelist-inclusivity.html