Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[question] why are the default "enabled" host aliases excluded when fetching updates? #6

Open
sudoforge opened this issue Oct 20, 2018 · 1 comment

Comments

@sudoforge
Copy link
Contributor

sudoforge commented Oct 20, 2018

The default hostsfile for stevenblack/hosts, as of 15 Oct 2018, contains the following default entries:

127.0.0.1 localhost
127.0.0.1 localhost.localdomain
127.0.0.1 local
255.255.255.255 broadcasthost
::1 localhost
::1 ip6-localhost
::1 ip6-loopback
fe80::1%lo0 localhost
ff00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
0.0.0.0 0.0.0.0

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.

@sudoforge 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
@pigmonkey
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants