You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
All of these, save for the last line (0.0.0.0 0.0.0.0), are explicitly excluded from /etc/hostsctl/remote.hosts:
hosts_fetch_updates() {
# ...# Only allow entries in the new remote file which begin with the blocking IP# address.
match_string="$(echo $ip| awk '{print substr($0,0,3)}')"
hosts=$(awk "{ if ( substr(\$0, 1, 3) == \"$match_string\" ) print \$0 >> \"${tmpfile0}\" }""${tmpfile}")# ...
}
What is the reasoning behind this exclusion? I think it makes sense to include the default "enabled" entries from the upstream file; this is the expected usage by the project author, and I would argue that it is the expected usage of consumers of hostsctl as well.
The text was updated successfully, but these errors were encountered:
sudoforge
changed the title
Hosts which are enabled in the remote hostsfile(s) should be included.
[question] why are the default "enabled" host aliases excluded when fetching updates?
Oct 20, 2018
This is to reduce the level of trust needed in the remote file. With this behavior, users can blindly run hostsctl update and know that the worst case scenario is a host they care about becoming blocked. Without some sort of check, the remote file could insert an entry like 123.456.789.1 accounts.google.com, compromising the Google account login page.
I'd accept a pull request to also allow entries beginning with 127.0.0.1 and ::1, though I think most distributions include those entries in their default /etc/hosts, so we would probably end up with duplicate entries. In this case, the duplicates wouldn't hurt anything, but are annoying.
The default hostsfile for
stevenblack/hosts
, as of 15 Oct 2018, contains the following default entries:All of these, save for the last line (
0.0.0.0 0.0.0.0
), are explicitly excluded from/etc/hostsctl/remote.hosts
:What is the reasoning behind this exclusion? I think it makes sense to include the default "enabled" entries from the upstream file; this is the expected usage by the project author, and I would argue that it is the expected usage of consumers of
hostsctl
as well.The text was updated successfully, but these errors were encountered: