prerequisite_check works with te_pe_tb_check (thanks )
The error messages from te_pe_tb_check are passed to sdwdate-gui as is, without formatting. It seems that the script is used by sdwdate only. As far as I understand, whonixcheck calls tor_bootstrap_check.bsh and tor_enabled_check directly. The question is: can we modify the messages in te_pe_tb_check with some HTML, for better output in sdwdate-gui?
modify prerequisite_check: accordingly. The message in the log is shown with new lines like in sdwdate-gui, because of the “ ” “\n” substitution in strip_html. That could be removed, but in case of timesanitycheck failure, the whole (long) message would be on a single line, not very readable.
renam /etc/sdwdate.d/30_sdwdate_default.conf to /etc/sdwdate.d/30_default.conf.
re-add the comment for custom .d files.
one shot logging in prerequisite_check (safelog)
[quote=“Patrick, post:171, topic:1137”]Cannot use port 9108 for everyone by default. Won’t work on plain Debian. Only 9050 is available there by default. (And editing torrc is not allowed for packages.)
IP / port should be overwriteable when using it config. Currently:
PROXY_IP
PROXY_PORT
(We can consider to comment those out by default for making it easier to have the built in defaults.)[/quote]
Wondering how to implement that. In an external file? In /etc/sdwdate.d?
Had to change the ssh key in github because of this:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Please contact your system administrator.
Add correct host key in /home/USER/.ssh/known_hosts to get rid of this message.
Offending key in /home/USER/.ssh/known_hosts:1
RSA host key for stash.customer.com has changed and you have requested strict checking.
Host key verification failed.
fatal: The remote end hung up unexpectedly
Made a quick search, not really conclusive. Have you ever experienced that?
yes, I saw this in my life before either because I migrated ssh user data from one system to another and messed up something or because remote changed the fingerprint
that happens if remote (here: github) changed their ssh key. But they did not. At least not for the servers I am reaching. (They could be using ssh round robin, different data centers with different ssh keys.)
you creating a new key should not be necessary
just verify that the ssh fingerprint you are receiving is the one that you are expecting
– here: Connecting to GitHub with SSH - GitHub Docs - relevant part: "
The authenticity of host ‘github.com (207.97.227.239)’ can’t be established.
RSA key fingerprint is 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48.
"
could really be a man in the middle attack. In that case nothing too bad happened except for the denial of service. In that case no changes on your system required. Just an outgoing connection that does not tamper with connections. Perhaps just another Tor exit?
Added proxy settings (commented) in /etc/sdwdate.d/30_default.conf.
A new module proxy_settings.py returns the settings (from conf or auto detected) to sdwdate.
sdwdate_loop pass the settings to remote_times.
In check for general errors only on first fetching iteration (three urls… · troubadoour/sdwdate@81e9e6b · GitHub, general_proxy_error and general_timeout_error are checked on the first iteration only (or if three urls are requested). There was a bug popping a general_timeout_error once in a while, and it’s more logical to do it that way. Modified [no_valid_time returned from pool] message for the case tor or internet goes down during an acquisition cycle.
Looks good so far, but the port auto detection needs more work.
if port_number == '':
port_number = '9108'
That should default to 9050 to support non-Whonix distributions where Tor by default lists only on 9050. And above the fallback code, if Whonix is detected (i.e. if folder /usr/share/whonix exists) -> port -> 9108.
[hr]
prerequisite_check message should start with “prerequisite_check:” or something like this so we can identify, that messages are coming form that check.
I think temp_dir needs to be deleted afterwards. Otherwise we create a million of those. It would be best to create it just once globally during startup and delete it on exit.
Do we want to support with/without having anon-shared-helper-scripts installed?
– If no -> needs “Depends: anon-shared-helper-scripts”
– If yes -> Skip if that file is not executable.
– Support outside of Whonix would be difficult, since setting up ControlPort access would have to be set up, which is difficult in the absence of the tor.d config folder feature.
[quote=“Patrick, post:189, topic:1137”]Looks good so far, but the port auto detection needs more work.
if port_number == '':
port_number = '9108'
That should default to 9050 to support non-Whonix distributions where Tor by default lists only on 9050. And above the fallback code, if Whonix is detected (i.e. if folder /usr/share/whonix exists) → port → 9108.[/quote]
The script follows the same logic for ip and port settings, that is:
if PROXY_IP commented in configuration (ip_address = ’ ') → autodetect ip, else use PROXY_IP value.
if PROXY_PORT commented in configuration (port_number = ’ ') → use Whonix default 9108, else use PROXY_PORT value.
We should revert the logic to make it default to 9050.
- prerequisite_check message should start with "prerequisite_check:" or something like this so we can identify, that messages are coming form that check.
- I think temp_dir needs to be deleted afterwards. Otherwise we create a million of those. It would be best to create it just once globally during
startup and delete it on exit.
Do we want to support with/without having anon-shared-helper-scripts installed?
– If no → needs “Depends: anon-shared-helper-scripts”
– If yes → Skip if that file is not executable.
– Support outside of Whonix would be difficult, since setting up ControlPort access would have to be set up, which is difficult in the absence of the tor.d config folder feature.
Why not implement this at the python level? In conceptual term, the idea is to call te_pe_tb_check the prereqisite_check. Sdwdate obtains the results from prereqisite_check. Then to mark that sdwdate did not obtain the messages itself, these are prefixed with "Prerequisite check:". But prefixing should be up to sdwdate. Because te_pe_tb_check could return no output or strange output (errors) which it would not prefix itself. Also then the prereqisite_check is more configurable, modular. Only the path to the script would have to be replaced, nothing else.
prereqisite_check run only if "/usr/lib/anon-shared-helper-scripts/te_pe_tb_check" exists (instead of [if file executable]).
Can we make this if executable? The idea is being able to easily disable the check for testing purposes.
As far as I can see, next could be a test unit for devs, to check all the servers, and I still have to try custom .d configuration files
Plus, on top from what you might want to change or add, there is some cleaning and pep8 checks before it can be prereleased.
Sorry, but I think I messed something up. The Tor/gateway IP detection. It actually got quite complex. Non-Qubes-Whonix vs Qubes-Whonix + Qubes gateway vs Qubes workstation + Qubes gateway-template + Qubes workstation-template vs no net-vm configured.
So maybe in sdwdate-python we could implement it as this:
if folder /usr/share/whonix exists + if file /usr/lib/anon-shared-helper-scripts/settings_echo is executable + then run /usr/lib/anon-shared-helper-scripts/settings_echo and set ip_address = $TOR_CONTROL_HOST.