Current State of Kloak?

This does not happen directly after boot. Only when manually run whonixcheck form terminal after boot.

kloak has already capability sys_ptrace, Therefore should be allowed already?

We need to understand why this happens. If it has a strange interaction with whonixcheck it might have a strange interaction with other applications too.

In worst case this could crash kloak or render it ineffective.

1 Like

This fixed it:

1 Like

No, the capability and apparmor ptrace rules are different.

That should be changed to ptrace readby,. Giving it all ptrace permissions is dangerous. It only needs readby.

1 Like

Using that now.

1 Like

1 Like
1 Like

Package build on the ARM hardware platform might be fixed in Debian bullseye and above:
arm support · Issue #25 · vmonaco/kloak · GitHub

Might try again on Debian bullseye.

arm support · Issue #25 · vmonaco/kloak · GitHub

1 Like

This will be solved with the addition of libsodium.

1 Like

I’m honestly really surprised that this commit hasn’t been added yet. He’s essentially done what was supposed to have been done years ago, make mouse fingerprinting hard and made it happen in Qubes.

If the upstream being dead is why, then why not just add the code into the next Whonix version? If you need help adding the lines of code in from the pull request, I can assist.

1 Like

Does look good to you?

Some activity here today:

Not easy for me. I don’t speak C and therefore I cannot accept major C contributions by new/anonymous contributors due the security risk. With tiny exception (Existing Ports of and Porting Whonix ™ to other Architectures), all C(++) code in Whonix comes from trusted sources such as or TBB from

So ideally:

  • common code paths make sense for non-Qubes and Qubes (if any of these are changed) so upstream is comfortable to merge them
  • Otherwise Qubes specific code paths stay out of the way for non-Qubes.
  • I need a trusted C code reviewer. Reviewing at least for non-maliciousness. Functionality testing we have testers here.
  • Hopefully upstream could review the Qubes specific code paths for non-maliciousness and then trust Whonix contributors to test functionality in Qubes. (I don’t have any indications that upstream is using Qubes and that’s a big ask.)

Unfortunately quote common that projects from academic backgrounds are unmaintained in the long run. General huge issue of code getting deprecated after a while in Open Source due to lack of contributors and non-existent business model.

A different approach would be for you to independently fork kloak and then get it merged into Tails or even better Maybe it doesn’t need to come to that. Let’s see how active upstream now is.

A wholly different idea: Any reason this must be written in C? Could this be rewritten in python or something?

I was pleasantly surprised that the C level suggestions in got a positive review from upstream.

Before I overload (low activity) upstream with more suggestions by chatgpt… (I wanted to wait until Multi-device support by vmonaco · Pull Request #38 · vmonaco/kloak · GitHub and are merged.9

Could I ask you please (apparently higher activity) to have a look at my GitHub - adrelanos/kloak at chatgpt2 branch. (Just increasing branch numbers by 1.) Has only 1 commit for now. Fix potential buffer overflow vulnerabilities · adrelanos/kloak@11f48c4 · GitHub

I am hoping it can fix grave usability issues such as starting kloak resets keyboard layout · Issue #12 · vmonaco/kloak · GitHub and keyboard randomly sometimes stops working · Issue #31 · vmonaco/kloak · GitHub by more defensive coding to fix some broken corner cases.

Not sure if you have access to chatgpt4 (version 4). But if you have, could you run it through chatgpt4 please to see if it can find (and even fix) some more code issues (in upstream dev branch or your branch)?

quote myself in Multi-device support by vmonaco · Pull Request #38 · vmonaco/kloak · GitHub

Forgot to mention, I tested this + #49 in Whonix today and it was working fine.

This is now in Whonix developers repository.