AnonSurf GTK is completely rewriten in Vala, which should provide more stable GTK experience
“Options” dialog is removed. User can still use /etc/anonsurf/anonrc like before
Enable AnonSurf at boot is now a “Switch”
Title bar is now showing status of AnonSurf (and errors as well). The “status” in title bar includes images like “status” before
System tray icon’s menu shows menu items base on AnonSurf’s status. For example: if AnonSurf is not running, it shows “start”, “check IP” and “quit”; but if AnonSurf is running, it shows “stop”, “change id”, “check IP” and “quit”. Please notice that it doesn’t work on Gnome.
anonsurf-cli no longer shows output in system notification
Known problem
Start / Stop from menu launcher works, however it doesn’t show any notifications.
Check IP from menu launcher doesn’t work
I didn’t test change id from menu launcher
Test scope
build time:
Detect any missing library at build time
Any compile errors
Any make package errors
installation time
Detect if make install doesnt work. (Make install should be compatible with other non-parrot distro)
I built the current branch on Kali. Starting the AnonSurf-GTK interface works. Starting anonsurfd itself seems to cause connection problems, but I can recover the connection when the interface is used to shut anonsurfd down. Tor Status is not working on my current build.
You must be joking LoL. Anyway, your log seems fine to me. It’s just build log so nothing special there. I assume this is something wrong when AnonSurf tries to start Tor (are you sure Tor service is running?).
Tor status is actually the nyx tool. I’m gonna change the name later. It’s not easy thinking about the name for the button LoL
p/s: journalctl could show something
This issue doesn’t need immediate attention (due to my use of a different OS). Everything appears OK in the journal logs. As you note, it’s probably a tor service issue.
Jun 03 18:46:06 shiva polkitd[1029]: Operator of unix-session:2 successfully authenticated as unix-user:a-men to gain TEMPORARY authorization for action org.freedesktop.systemd1.manage-units for system-bus-name::1.1778 [systemctl start anonsurfd.service] (owned by unix-user:a-men)
Jun 03 18:46:06 shiva systemd[1]: Started anonsurfd.service - “Anonsurf Daemon Service”.
Jun 03 18:47:05 shiva polkitd[1029]: Operator of unix-session:2 successfully authenticated as unix-user:a-men to gain TEMPORARY authorization for action org.freedesktop.systemd1.manage-units for system-bus-name::1.1784 [systemctl stop anonsurfd.service] (owned by unix-user:a-men)
Jun 03 18:47:05 shiva systemd[1]: Stopping anonsurfd.service - “Anonsurf Daemon Service”…
Jun 03 18:47:06 shiva systemd[1]: anonsurfd.service: Deactivated successfully.
Jun 03 18:47:06 shiva systemd[1]: Stopped anonsurfd.service - “Anonsurf Daemon Service”.
Interesting choice on vala. That is a super niche language you are using for the GUI. I can confirm tor is working fine on kali since the ‘ifa’ tool works perfectly now. Would like to test it on parrot but waiting on the OS support on pi5 as I use the hardware as my cybersecurity OS for isolation and flexibility… Gone are the days of ESXi hypervisor for me. That would be 100% supported.
I did notice the latest “Kali 2024.1” runs on Debian10 Buster, while “Parrot 6” runs of Debian12 Bookworm so that might explain the delay/incompatibility issues since parrotOS is using the latest version, therefore have to wait on the Debian developers upstream for Debian specific issues.
I’m going to download Kali and build AnonSurf on it (i’d be damned in hell for this lmao). Since AnonSurf should be much much easier building on other systems, it makes sense testing AnonSurf on Kali too.
In the other hand, I’m rewriting some logic in make_torrc, hopefully make the structure be much better (and support some more Tor’s config)
FWIW: I did a fresh pull\build\install on my (Debian Testing) system. AnonSurf does turn on tor now. I pressed the “My IP” (green, checkmark) and then the “Change ID” (red, cross) to create the upper right notifications.
Yeah I changed the authentication method to cookie authentication, hence change id and nyx doesn’t run properly. I got tired last night. They are my highest priority today. It’s strange because as i remember, I tested authentication and it worked fine for both Nyx and everything else.
On other side note, I added disable cache of nyx config. Quick brief: nyx creates a sqlite file at $HOME.
p/s: I think I found the error of nyx. In nyxrc, i set tor_chroot /var/run/tor/control/ and nyx crafted the full path of cookie authentication to /var/run/tor/control + /run/tor/control.authcookie`
Previous version used password as authentication to Tor’s control port. To be able to do it, I must save password in /etc/anonsurf/nyxrc. Password is randomly generated every time anonsurf starts. This method might not cause security issues, but it’s stupid by design. The current version is using Tor’s Cookie Auth. But this brings problem That current user is not able to authenticate to Tor’s control port. Change ID and Nyx (Tor status) are effecting by this problem. Damn this Beta testing is going to be a disaster because of it.
I rewrote change id for both CLI and GUI. They should work with Cookie auth mechanism. The only problem: Current user must be added to Tor’s group (debian-tor on debian-based distro).
Meanwhile Ubuntu is showing me this runtime error and i have no fucking idea what the fuck is going on. Run on PC gives me no errors at all.
I wanted to use a browser I don’t use (therefore not customized) just for that screenshot showing LibreWolf was on tor through the actions of AnonSurf.
The build I had tested earlier did not start up the tor service despite anonsurfd loading.
I removed option “bridge mode” in config. It’s using auto_bridge which is a bool value instead. I think it’s better for user because new user might not know correct value for enum. @Masmer can you help me test anonsurf again, pls? I assume that change id and nyx won’t work when other stuff works normally.
No u don’t need any debug parameter. This is expected because authentication cookie file only allows tor user (debian-tor) read the file. The other option is to enable group readable but it means current user must be added to debian-tor group. Either way requires little change in the system. The only way to read cookie file for authentication is to run read file functions (either Nim or Vala) as root. It’s the same technical difficulty as options dialog that I removed.
A solution for reading Tor’s cookie file is to use sticky bit as debian-tor user. However it works in CLI only. GTK doesn’t work like that. Very funny.
