I've read through the thread (though I admit not every bit of it) and I'm very surprised to see nobody has been concerned about whether this executable does any funky things like ever connect to the Internet at any point, read any files off disk, etc? Has anyone monitored it (long enough) for any of those things?
Looks nice, but all of a sudden someone anonymous just deciding to help everyone by providing a closed source executable should normally raise just a healthy dose of suspicion.
Multiple users have confirmed the process is accessing two IPs (2.21.242.213/2.21.242.237) over encrypted connection. Not sure why this is necessary.
Neither do I. The security concerns raised in this thread of using a seemingly random, closed-source binary which calls back to Akamai servers over an encrypted channel are legitimate. Until an explanation is provided by the developers for the usage of these two IPs, you can temporarily block your system(s) from reaching them by using the following:
Windows (as Administrator):
netsh advfirewall firewall add rule name="ETHlargement Callback" interface=any dir=out action=block remoteip=2.21.242.213
netsh advfirewall firewall add rule name="ETHlargement Callback" interface=any dir=out action=block remoteip=2.21.242.237
Linux (as root):
iptables -A OUTPUT -d 2.21.242.213 -j DROP
iptables -A OUTPUT -d 2.21.242.237 -j DROP
As far as I can tell, it has zero impact on the efficacy of the application nor the final hash rate.
I've read through the thread (though I admit not every bit of it) and I'm very surprised to see nobody has been concerned about whether this executable does any funky things like ever connect to the Internet at any point, read any files off disk, etc? Has anyone monitored it (long enough) for any of those things?
Looks nice, but all of a sudden someone anonymous just deciding to help everyone by providing a closed source executable should normally raise just a healthy dose of suspicion.
Multiple users have confirmed the process is accessing two IPs (2.21.242.213/2.21.242.237) over encrypted connection. Not sure why this is necessary.
Neither do I. The security concerns raised in this thread of using a seemingly random, closed-source binary which calls back to Akamai servers over an encrypted channel are legitimate. Until an explanation is provided by the developers for the usage of these two IPs, you can temporarily block your system(s) from reaching them by using the following:
Windows (as Administrator):
netsh advfirewall firewall add rule name="ETHlargement Callback" interface=any dir=out action=block remoteip=2.21.242.213
netsh advfirewall firewall add rule name="ETHlargement Callback" interface=any dir=out action=block remoteip=2.21.242.237
Linux (as root):
iptables -A OUTPUT -d 2.21.242.213 -j DROP
iptables -A OUTPUT -d 2.21.242.237 -j DROP
As far as I can tell, it has zero impact on the efficacy of the application nor the final hash rate.
This will be useless if in code dev is using fdqn as target address, but anyway what kind of concerns might be with traffic? Yes, probably it is good to know what dev sending back to their servers, but I personally dont care, as I have nothing saved on rigs, execpt OS and miners.
Cool, we have servers. Who knew? If you find their location, let me know, my spare one just slipped under the couch cushions.
If you want to know what those are accessing, go ask Microsoft. We didn't create watadminsvc.exe or svchost.exe. Or use the Linux version.