Thread on TAILS’ plans to use Gajim Using Gajim in Tails (#8796) · Issues · gajim / gajim · GitLab
2 posts were split to a new topic: Managing programs without Tor DNS Support
8 posts were merged into an existing topic: Managing programs without Tor DNS Support
Sure. For 1) you want me to lookup how to manually specify a user/password?
Done with 2:
https://bugs.debian.org/902237
Where do I file the .d config request? I think its an upstream feature more than a Debian thing If so can you please create an account on their bugtracker because I don’t want to be profiled by their Google Captcha
HulaHoop:
Sure. For 1) you want me to lookup how to manually specify a user/password?
It entails asking the gajim developers if gajim automatically sets a
socks user/password if using Tor.
The simple stream isolation implementation is socks support.
Next level is socks with socks user name support.
Best level is a different socks user name per account for not even
application level separation but account level separation.
Btw I don’t think I wrote HulaHoop is investigating the details.
. I
guess you did by that time. Dunno.
2)
- Stretch has Debian -- Error has
0.16.6-1.1
. - https://bugs.debian.org/902237 already got a reply saying
Marked as fixed in versions gajim/0.16.8-4
. - There is now a separate package for Debian -- Error.
Not sure what happened. They already fixed it but didn’t have a bug report beforehand perhaps. Not sure they’ll upload to stretch
. Probably not. Now that this is sorted in a clean way in a future version, I try make it work in stretch based Whonix by config-package-dev hide
/usr/share/gajim/plugins/plugin_installer
.
conf.d request
, yes, it’s an upstream feature request. On Sign in · GitLab see at the bottom under sign in:
Sign in with
And then you should see a github symbol. Account security is unimportant here imo. [*]
Does that work for you? Otherwise I’ll use the login with github and pass on the feature request once written.
[*]
(The remote risk of github being hacked and the account being impersonated on the gajim issue tracker is a risk I am willing to take. Very low impact if an attacker would post nonsense there.)
Should we install xmpp support package Debian -- Details of package python-nbxmpp in stretch by default?
Other packages for default installation: gajim gajim-omemo gajim-httpupload
Any other gajim related packages we should install by default?
I found another issue which is hopefully just temporary due to me failing to properly configure gajim.
- forget about automation / scripting the config, we’re not there yet
- this question is from a users’s perspective
How do I configure gajim to use Tor by default?
Once I think I did that, and then create a new account, you have to click “advanced” first. By default it’s set to None
meaning “not using Tor” (for us: no stream isolation). Users would have to manually select Tor for each account they are setting up. I haven#t found out how to delete None
from network settings. Can you make head or tail of my description? Could you figure out how to configure using Tor as default network setting?
Ah I see. I didn’t notice I could do that last time. I consider my Github account very low value and GPG signing should negate any trust issues for code commits.
I went ahead and opened tickets for both features:
Yes please add it. Its ideal for XMPP GUI client performance:
https://camaya.net/api/gloox-0.9.9.12/index.html#block_conn_sec
Other useful addons:
gajim-antispam
gajim-rostertweaks
gajim-triggers (let me know what you think about this one because I’m unsure if it means running arbitrary commands)
We should not install image previewing because of security and privacy reasons:
gajim-urlimagepreview
i have more than one problem with gajim:
1- not intended for security/anonymity focused app
2- not for any DE , its specifically for GNOME
3- lack of stream isolation
including it in whonix not really worth the headache as if even the upstream will not help us for e.g if there will be problem of gajim and kde …
Test it with OMEMO and let us know how it works and how encryption is enabled, We could be able to ship a config that forces it by default.
As long as it runs on KDE I don;t see the problem. Who cares if its style doesn’t match? There are plenty of GNOME centric software that is pretty useful to have.
Not as bad as you think. We are working on it and coming up with a solution to deal with this for all future software that is not stream isolation friendly.
Gajim with a separate plugininstaller is available from stable backports according to the maintainer.
It has. It has socks proxy settings. I am working on enabling socks proxy settings for gajim by default.
So far so good… Current issue… Could you please look into this one? @HulaHoop
socks username and password configured here:
/home/user/.config/gajim/config
proxies.Tor.bosh_wait_for_restart_response = False
proxies.Tor.useauth = False
proxies.Tor.bosh_useproxy = False
proxies.Tor.bosh_http_pipelining = False
proxies.Tor.bosh_content = text/xml; charset=utf-8
proxies.Tor.bosh_uri =
proxies.Tor.bosh_wait = 30
proxies.Tor.host = localhost
proxies.Tor.user =
proxies.Tor.pass =
proxies.Tor.bosh_hold = 2
proxies.Tor.type = socks5
proxies.Tor.port = 9050
Assuming Socksport/HTTP isolation works for Gajim’s DNS, nothing else needs to be done (needs to be tested however).
If you are worried about torrent clients burning down the network then I recommend installing a bittorrent client by default and configuring it to use Tor’s HTTP Connect, then enabling IsolateDestAddr for SOCKS?
Both measures would be a stop gap until we ideally have the namespace solution you suggested.
Edit -> accounts -> active -> connection -> proxy is set to none by default (but should be set to Tor by default)
Same if you add another account.
New account -> advanced -> proxy is set to none by default
Can you confirm this issue?
then enabling IsolateDestAddr for SOCKS?
We can safely enable IsolateDestAddr (and port) for gajim’s SocksPort if that is what you meant.
…or SocksPort. Same effect. You may be over interpreting HTTP Connect vs Socks.
According to the references listed under Filesharing and Torrenting it’s an unwelcome use case. Therefore we shouldn’t install one by default. I don’t think HTTP Connect changes anything about that at all. But please feel free to rehash the bittorrent discussion at Tor Project since a few years have passed since these statements were made.