Well, it's a good question. How can you trust someone who thought this was okay? Even if they're just too ignorant to realize what they were doing, that's also a good reason not to trust them. What else will they think is a good idea?

These are all legitimate questions, but when you phrase them that way and address them to the maintainer, consider how the message will be received. He is likely to consider it an attack, and will be tempted to mount a defense. Now, instead of a constructive problem-solving discussion, you have a destructive battle—one that does not move things forward towards the goals: removing the change and preventing further bad decisions.

There is no constructive criticism possible and no possible further relationship. If I'd been a user of this project, I'd be reformatting my PC and restoring from backups, and the nasty message I'd leave on github would only be intended to warn others away from this toxic person's code.

If someone conspired to enroll my computer in a botnet, constructive problem solving would not be the first thing on my mind, and in fact I don't see how it could be my responsibility. If I fuck up very badly and people are mad and unconstructive, that's unpleasant but the problem is my fuckup, not people being mad about it in the wrong way.

It seems to me that it's up to the author to explain why the project can still be trusted, they can't just do this and expect that people will still trust them just because they reverted it.

You are right.

everyone makes a mistake at some point and the fact that the dev used the ip hijacking service's name in the commit message to me signals that he wasn't aware of how shady it is

Even if he was, a comment like "I don't think this is acceptable and will fork" is a lot more appropriate than "don't talk shit"