We have been moving WHATWG standards to be deployed through GitHub and Travis CI. This way we can generate snapshots for each commit which in turn makes it easier to read older obsolete copies of the standard. The final step in our build process moves the resources to the server using SSH.
Unfortunately we have been doing this in a bad way. The documentation from Travis suggests to use
ssh_known_hosts and lots of other documentation suggests passing
-o StrictHostKeyChecking=no as argument. The risks of these approaches and their secure alternatives are not (always) outlined unfortunately. Both of these open you up to network attackers. You effectively do not know what server you end up connecting to. Could be the one you know, could be that of an attacker. Note also that in case of Travis’s
ssh_known_hosts it is not even trust-on-first-use. It is trust-on-each-use (i.e., trust-always). You can be attacked each time Travis runs. I filed issue 472 since what we need is trust-never, as the network is unsafe.
As far as I can tell this is not a big deal for WHATWG standards, since they are completely public and the worst that could happen is that an attacker stops publication of the standard, which they could do even if we had a proper setup (by terminating the network connection). However, it does set a bad example and we would not want folks to copy our code and have to know the limitations of it. It should just be good.
The easiest way to do Travis deployments securely that I have found is to create a
known_hosts resource and pass
-o UserKnownHostsFile=known_hosts as argument (thanks Tim). That ensures the
rsync -rsh="ssh" program will not prompt. However, rather than not prompting because you told it to bypass a security check, it is not prompting because everything is in order. Of course, this does require that the contents of
known_hosts are obtained out-of-band from a secure location, but you need to be doing that anyway.
The XMLHttpRequest Standard now makes use of that secure deployment process and the remainder of WHATWG standards will soon follow.
With that, if any of the following is true, you probably need to fix your setup: