Please note by far the quickest way to get a new feature is to file a Merge Request.
In light oh the MitM attack which is going around XMPP communities over the past few days, I suggest that gajim warns the user when the server fingerprint changes and forcing them to manually acknowledge this change.
Claws mail does this when the server fingerprint changes. I feel this would be a first point at which a MitM attack could be caught, if a certificate is renewed too soon (say if it still has 60 days left on it, it would be pretty unusual to renew it until it hits 30 days).
Please first check if another issue has been opened for your problem
No warning and be able to enable the plugin.
Warning symbol next to the PGP plugin (legacy) about missing dependencies despite these dependencies existing:
/usr/bin/gpg
exists
/usr/lib/python3.10/site-packages/gpg.py
exists (installation path defined by the arch linux python package)
I still get told one or both of the dependencies are missing...
Ok its working now using gajim
from official repository, seems like it was an issue with gajim-git
AUR package, but I can not confirm that.
I will close this issue as I can no longer reproduce this in the latest version of gajim
, thanks the the suggestions anyways :)
Sorry for the late response, I forgot to respond after reading the notification while busy.
@andre See output below:
~ on ☁
❯ pip list | grep gnupg
python-gnupg 0.5.0
Seems it has been installed by pip, but pacman has also installed as well (because it is a dependency):
~ on ☁
❯ pacman -Q python-gnupg
python-gnupg 0.5.0-2
Also PYTHONPATH
is unset:
~ on ☁
❯ echo $PYTHONPATH
What do you suggest I do? Gajim picks up the other packages from the directory arch installs its python libraries (/usr/lib/python3.11/site-packages
) for example, from the AUR gajim-plugin-omemo
is installed to this directory and is picked up by gajim, so I do not see why gnupg is not!
It might have been the fact that gajim was outdated on Arch Linux, it was updated a few days ago when the python 3.11 build was finished, I will attempt to activate the plugin again now and see if that fixes it :)
Have you ever been in a MUC, with someone who is mean to you, and nobody plans to stop them?
You have them blocked, you have tried to cut communications with them and yet they still are making small insults towards you and you just want to forget about them?
Introducing /ignore, the ability to not have to read peoples insults, would be a neat feature don't you think?
I have inspected the codebase:
find_gpg() returns 'gpg2' which is not None, and thus should not be invoking the error message.
I have also tried importing gnupg, and again this does not throw and error so ERROR should remain False, yet still this message is popping up and preventing me from enabling the PGP plugin.
Please first check if another issue has been opened for your problem
No warning and be able to enable the plugin.
Warning symbol next to the PGP plugin (legacy) about missing dependencies despite these dependencies existing:
/usr/bin/gpg
exists
/usr/lib/python3.10/site-packages/gpg.py
exists (installation path defined by the arch linux python package)
I still get told one or both of the dependencies are missing...
I think this should not be reinstated, personally I prefer if it was page-up and page-down to scroll, however that is just because I am used to scrolling using them, and not the arrow keys.
Ctrl + up is now used to edit comments as far as I am aware.
@wurstsalat That is applied to all messages stored in the Gajim database, XEP-0446 defines a method of making a single message ephemeral, not the entire database of messages.
This would be a good feature, however good old ">" is sufficient still, however it does have the IRC reply issue where it can be difficult to follow a conversation which I assume is why this XEP was created.
Ah,
this is already in the process of being patched. Sorry for wasting your time I guess.
Would you like this issue to remain open until the patch is merged, or should I close it?
Unfortunately, the dependency tree needs to be traversed, downgrading gupnp needs downgrading of GNU libraries, which I do not want to do, as it could compromise my system or cause other applications to stop working.
So the outcome of this is that farstream either needs to be patched to remove gupnp as a fixed dependency and make it optional (and rely on STUN/TURN or manual port forwarding for communication). This would provide a temporary situation, but unfortunately I do not think it is as easy as it sounds.
I assume the entire farstream codebase is built around both upnp and other methods of establishing peer to peer connections, such as NAT traversal, therefore this patch would not be feasible.
Unfortunately, as stated in one of the first comments, it does not seem there is any feasible work around and we will just need to wait for the rewrite to libsoup3.
What sections of the codebase currently need transition from libsoup2 --> libsoup3?
Oh sorry I misunderstood
So the issue is that farstream depends on gupnp, which in turn depends on libsoup3, and you currently have coded the http logic to use libsoup2, therefore these two conflict.
Is there any forks of farstream which attempts to not use gupnp?
I will test downgrading gupnp see if that fixes it :)
Gajim supports STUN/TURN for NAT traversal, so upnp is not essential
Now this makes me question why Gajim uses upnp, I internally disable this on my router as it is insecure and allows any application to request a port to be forwarded without informing the user.
Maybe a fix could be to disable gupnp, making it an optional dependency? Then the libsoup2 error can be postponed until there is time for a developer to patch it?
we use libsoup2 for all kind of http activities, so we have to port them, and yes its non trivial.
I do not know the Gajim codebase, but I know that file upload is done over http, what over XEPs require http?
If http activities uses libsoup2, then how come http upload still works?
It seems Farstream the lib which we use for audio also uses this lib.
I downgraded Farstream all the way back to 0.2.8-2, same problem still exists!