Doesn’t automation of editing your hosts file potentially open people up to fairly insidious man in the middle attacks?

Isn’t that what cron is for?

Systemd has a cron system too.

I’m just guessing, but it might be easier to programmatically install a systemd cron job (and making sure it runs) than doing so for the old/conventional crond?

Just using cron is back compatible

Things you get with systemd that you don't get with cron unless you implement them in the script.

* Not running if the network is down.

* Not running if the download path isn't available.

* Running if the machine was off during the scheduled time.

* Monitoring and retry logic.

* Logging to syslog.

* Resource constraints.

* Random wait.

It ends up being a lot of code factored out of the actual application.

so instead of code in one place you have it in 2?

I don’t understand this logic. Can you explain why having code in more than one place is a bad thing?

For a simple script that does one thing, it's overkill.

Yes. So you keep that simple script simple, and you let systemd do the heavy lifting.

But systemd doesn't do any of the above listed things automatically... You'd need to write an entire script for sytstemd to take advantage of it. An entire script you could just have run with cron on boot.

He probably wants to learn more about systemd and needs/wants a project to do it.

Yes, obviously cron would work. If systemd can do what this dev needs, what's the harm?

You're right, but I like the extensibilty of Systemd. Things like running every week or whenever the next start is. Or only if the network is online.

If I considered constructing a botnet of Linux workstations, your software would be an excellent candidate.

You could say the same thing about Ansible, or Chef or Puppet or any of the other millions of systems automation tools available. There are lots of ways to misuse software, I don't think that that should preclude people from writing it.

I'm quite precise about about what these tools can and cannot do on my systems. Downloading random files form the Internet isn't on the list. When you hand over the control of the hosts file to someone else, you're basically transfer control of your DNS queries.

At least for HTTP, you're hopefully using TLS for anything important and failing if the certificate isn't valid. That certainly won't remove all the risks of losing control of your DNS, but it's one good safeguard.

Some of my favorite hacks in the last year have been about using valid certs for bad actions. When you can have a cert from Microsoft (Azure), there’s a lot of things people will trust.

Along similar lines, I think I heard that 30% of detected malware was signed with a “trusted” authority last year.