Hi, and welcome back! 
They could be independent - while avoiding code duplication - by moving shared code to helper-scripts?
1 Like
I took a quick look at the changes. I think ultimately what we probably would want is the introduction of a new library (not sure what to call it, tor_manage or similar?), which would contain the shared code from both tools that each of them could call as needed. That could go into helper-scripts. In theory that would allow further frontends to be created in the future if need arose. I donât think itâs a good idea to copy code from anon-connection-wizard to tor-control-panel to separate them though, I think that will only create additional work.
(On an unrelated note, clicking the âNew identityâ button in tor-control-panel in Whonix-Gateway seems to do nothing, at least not anything visible. Tor Browser in the workstation remains open, no lines are printed to stdout, nothing changes as far as onion circuits, etc.)
1 Like
Both packages share share some code. The big difference being the way to generate torrc. In my dreamerâs view, the main reason to make TCP independent from ACW would be to have Tor Control Panel usable in plain Debian. For this, do you believe that any reference to Whonix home made external libraries would be accepted ? I might be wrong. @Patrick: Is there a chance for helper-scripts being accepted in Debian?
Do you mean additional work after they are separated? In that case, the only duplicate work I can foresee would be a change to tor bootstrap phases, and the maintenance of of bridges-default which, by the way, are outdated.
It would be great to have any / most / all package(s) by Kicksecure / Whonix in packages.debian.org.
I guess the same chances of getting ACW or TCP into Debian. Itâs very common for Debian to package libraries.
Should be specifically simple in case of ACW, TCP and helper-scripts as these are already have a /debian packaging folder for years.
The difficult part is finding an authorized uploader, Debian Developer, mentor or sponsor or becoming one oneself⊠References:
Yes. Code duplication creates additional work.
Good solutions are that donât duplicate code are:
- A) deprecate ACW, update TCP; all code in TCP; or
- B) deprecate TCP, update ACW; all code in ACW; or
- C) shared code in helper-scripts, keep ACW and TCP maintained
Personally I share @troubadourâs concern that helper-scripts probably wonât be accepted into Debian proper. A lot of its code is specific to Kicksecure/Whonix (such as sysmaint considerations in autologinchange, use of leaprun in some code, etc.). Whether by design or not, itâs become a âmore than one package needs this code? Great, letâs throw it hereâ multi-tool. Making it upstreamable would be nice, but we would likely need a ks-misc package or similar to receive all of the Kicksecure-specific bits.
Many Python applications in Debian depend on other libraries. Maybe the shared functionality of ACW and TCP can be placed into a new library, python3-torconfig or similar? Then both packages can depend on that library, That would avoid the problems with placing everything in helper-scripts. @Patrick would that work?
(With the topic of upstreaming, the current state of both ACW and TCP means that there is some Kicksecure-specific bits in there, like leaprun⊠perhaps it would be useful to have some code to check whether leaprun is available and only use it if so, otherwise fall back to pkexec like it used to use.)
1 Like
Is it realistic to clean up helper-scripts and make it suitable for inclusion into Debian?
The derivative specific parts would indeed be great if these were moved elsewhere.
Yet another option: Merge ACW and TCP into 1 package? Then we wouldnât need a shared package.
1 Like
We have a big dilemma here. Deprecating either package would be a pity. Solution C does not seem to be an option, according to the following posts.
As you mentioned, we would be left with privleap dependency. There is some work to revert to pkexec, if this is the solution.
Anyway, this an option to be weighted with
Do you mean merging a wizard and a controller? Considering the amount of shared code, It might be achievable , but there would have a choice for the user, to run either ACW or TCP, with a dialog box for example.
Any idea for the name of the new package?
1 Like
One package can ship multiple applications, so I think the start menu can be used to allow the user to choose which to launch, like we have now. Weâd just put the files of both packages into one package.
tor-config-progs? tor-config-utils? tor-control-apps? Not sure if any of those are good namesâŠ
1 Like
Alright, so letâs keep both.
We cannot use pkexec because we now have user-sysmaint-split on Whonix-Gateway.
But there could be if/else code. If there is user-sysmaint-split, use leaprun (privleap). Otherwise, use pkexec.
The Depends: privleap in debian/control can be removed. A Whonix-Gateway with user-sysmaint-split will come with privleap installed by default anyhow. So I am no worried about a missing dependency.
They can stay two different applications. Similar as theyâre looking right now.
The only simple thing I would do is:
Move all files from anon-connection-wizard to tor-control-panel. Done.
That would not change much. But then you could refactor / improve the code.
Possible but maybe not needed. (As per above.)
Yes. Either anon-connection-wizard or tor-control-panel.
No new name. No new package.
Just 1 thing gets merged into the other. Done. Simple.
Exactly.
Yes.
Iâd prefer not inventing any new package. Instead. the 2 packages ACW + TCP can be merged into a single one such as TCP only.
OK. For the moment, we use privleap and can decide later on the options.
To do firstly,
That was my original option. It might be not as simple as you word it, but we go for it and choose the name of the package tor-conrol-panel.
2 Likes
The merging of TCP and ACW is done.
There should be no change for the user, sdwdate-gui or whonix-gateway first installation.
There is still much redundant code, We are left with some refactoring in anon-connection-wizard, and some cleaning.
A couple of remarks:
Purging ACW (mandatory because of a leaprun conflict when building the new TCP) removes the Whonix meta packages. Trying to reinstall (say qubes-whonix-gateway) would reinstall TCP and ACW. I didnât look at he mechanics behind that, but I remember an similar old problem. @Patrick Is there any issue working without meta packages, since we can disable the check ?
sdwdate-gui imports tor_status from ACW. I didnât know the state of the refactoring/rewriting of sdwdate-gui in kicksecure. I forked it and installed it in the gateway to make the changes. No luck, there were tons of gui messages about socket not found or so in sys-whonix. Solution: purged and reinstalled with apt. I made the changes locally to get sdwdate-gui running.
1 Like
The packaging / meta packages are expected to cause zero issues. tor-control-panel debian/control file will be amended with Replaces: anon-connection-wizard.
Meanwhile if itâs an issue during development, use dummy-dependency. Example:
sudo dummy-dependency --yes --purge anon-connection-wizard
Weâll review and merge this after the initial release of Whonix 18.