Open dadoug opened 9 years ago
The problem is that s.eff.org switched to use DigiCert in the last week. We need to add the appropriate certificate to /etc/ on the router image, or probably the full cacert list (since the downloaded file is verified using PGP anyhow).
After all the trouble-shooting, I suspected that this was the problem. It's a relief to hear that all my tinkering on the router didn't break the thing.
So, if I understand correctly, we are now in a situation where we can verify but not actually retrieve update metadata. Is it now true that no one can update their router, even if simply in order to obtain the new EFF cert?! This sounds like it could be a notable hiccup for the project, requiring us to push some kind of manual upgrade instructions. There are obvious ways of doing so, but none of them involve an easy "push this button" solution of the type that is so crucial for casual users, since the "button" is effectively broken. Perhaps we can, in the future, retrieve the update metadata in the clear (over Tor) since, as you point out, "the downloaded file is verified using PGP anyhow."
Alas, such is life in this tangled web of trust we weave ...
The issue
"Check for update" failed when executed both from the web interface and the (ssh) command-line:
A local fix
I downloaded a new ca-cert bundle, cacert.pem, and placed it in
/etc/ssl/certs/cacert.pem
on the router. I then changed line number 39 in /lib/update/update.py to point to the new ca-cert bundle and was able to successfully run an update check from both the web interface and the command-line.My Trouble-shooting Process
Is there a problem with
/etc/ssl/certs/StartCom_Certification_Authority.crt
? I've found zero bit-wisediff
erence between this file on the router and copies obtained elsewhere. So, ... no? It should be noted, however, that I am no expert when it comes to CA-certs, so this probably an avenue worth double-checking.Is s.eff.org presenting a new/different cert? Good question. I don't know the answer, but it's probably easy for a skilled someone to check. EDIT: Yep, this is the cause of the issue.
What about bare
curl
ing? I noticed that barecurl
also fails to retrieve the signed metadata. To wit,root@cerowrt:~# curl -v --socks4a localhost:9050 --cacert /etc/ssl/certs/StartCom_Certification_Authority.crt https://s.eff.org /files/openwireless/update.json.asc
gives:I tried many permutations and combinations of bare
curl
ing, to no avail:--socks4a localhost:9050
option--cacert ...
optiontor
on the routertor
relatediptables
from/etc/firewall.user
on the router-k
flag tocurl
"works", of course, but this is cheating big-time!My Version Information