Gajim - 2016-08-16

  1. Louise Hey. gajim.exe.log last line: AttributeError: 'Connection' object has no attribute 'received_message_hashes'
  2. lovetox no thats normal, http upload should have given another one
  3. Louise Traceback (most recent call last): File "src\common\", line 93, in raise_event File "src\common\", line 1123, in _nec_message_received File "src\common\", line 74, in push_incoming_event File "src\common\", line 1464, in generate AttributeError: 'Connection' object has no attribute 'received_message_hashes'
  4. lovetox ma ots mpt tjat pme
  5. lovetox na its not that one
  6. Link Mauve Louise, this error seems to happen if the connection never called _send_first_presence().
  7. Link Mauve That’s likely an implementation bug, because a client shouldn’t need to send an initial presence at all.
  8. lovetox its a bug of tmolitors message hash function
  9. lovetox but it doesnt have anything to do with crashes
  10. lovetox its because he defines the array
  11. lovetox at the end of this function
  12. Louise Is it with prosody?
  13. lovetox and not in the init
  14. lovetox self.received_message_hashes = []
  15. lovetox no its a gajim bug, but unrelated, everyone has these messages in the log
  16. de-facto how do i install emoticons? clicking on the checkbox and then install seems to be without any effect...
  17. q55 hello guys, xep-0146 is a nice feature but I find it extremely unsafe when you're not the server owner. Can I disable it in Gajim by switching remote_control in the advanced settings panel to disabled?
  18. de-facto im chatting with someone on adium and emoticons are only partly displayed by gajim, hence i hoped by installing the pidgin emoticons pack i could solve that
  19. cippaciong 1) Install the plugin 2) Install one or more emoticon packs from the plugin preferences 3) choose the emoticon pack you wanna use in Gajim preferences
  20. q55 although I really like the chance to download unread messages from another client forging stanzas from the server side is a risk I can't accept. Maybe adding a password to unlock those commands could be a nice thing, or anything preventing an attacker on the server side to execute commands on my Gajim. If you disagree please let me know, I want to learn
  21. q55 now I want to disable it, I guess disabling remote_control did the trick but I would like to ask you
  22. de-facto cippaciong, thanks that seems to work :D
  23. cippaciong 👍
  24. Anders q55 seems prudent to be sure that messages couldn't be forged. But what is stopping that from happening already?
  25. q55 Anders, I don't understand your message sorry. It should be possible to forge a protocol-legal message on the server side to interact with a client pretending to be a legit resource to that account and download unread messages
  26. q55 that's horrible, especially because the so-retrieved messages would also be plain-text versions of e2e encrypted messages, forwarded decoded to another client on an ad-hoc request
  27. Anders Yes. You said that was the reason you wanted to disable remote control xep-0146.
  28. Anders Would not remote control messages be encrypted too?
  29. q55 exactly, I assume that I could disable this Gajim feature by switching remote_control to disabled but I need to confirm that
  30. Anders The server /hacker would have to forge yourself. Does remote control work in plain text or only in omemo/otr mode?
  31. q55 I wasn't able to figure out if ad-hoc commands between clients are going through the c2s XML stream like normal stanzas or if that is a direct client-to-client connection like in Jingle interactions. Anyway, this doesn't diminish the danger of server-side forged ad-hoc commands. The XMPP protocol doesn't prevent a server to forge legal stanzas with tailored headers (like spoofing e-mails' sender)
  32. q55 OMEMO and OTR are indipendent encryption tools, they don't interact with the underlying XMPP and could be used anywhere else outside jabber
  33. mathieui OMEMO does require XMPP
  34. q55 really? I ignored that, sorry
  35. mathieui OMEMO is the adaptation of the double ratchet protocol "axolotl" to XMPP
  36. mathieui so it depends on XMPP, even if the underlying crypto does not
  37. q55 I thought it didn't, as a multi-party evolution of OTR I guessed it could be used outside jabber too
  38. mathieui it doesn’t have much to do with OTR
  39. mathieui other than being an e2e crpyto protocol
  40. q55 mathieui, did you read my remote_control question?
  41. mathieui I did now but I don’t use gajim so I don’t know
  42. mathieui (for the record, OTR is still being developed)
  43. q55 sorry, being you an admin I thought you were like a developer or so
  44. mathieui nah, it’s a bit random that I’m an admin here (mostly because I was the first to re-join on a server reset a few years ago)
  45. mathieui but as I am sometimes available enough to ban spammers, I guess it’s fine
  46. q55 ok fine
  47. q55 I'm waiting for help from someone very knowledgeable about Gajim, I really want to disable XEP-0146
  48. mathieui Link Mauve, ^ you’re more familiar with gajim than I am
  49. q55 Anders, in a nutshell ad-hoc commands for remote-control don't use OTR or OMEMO which are intended for messages
  50. q55 mathieui, he's actually the guy who informed me about this security hole. We talked about it today
  51. mathieui I know, I read that on prosody@
  52. mathieui (iirc)
  53. q55 lol, draconian
  54. SouL x)
  55. q55 sorry, it was meant for another window :D
  56. q55 mathieui, wo. It's a small world!
  57. q55 honestly I think XEP-0146 should include a password authentication feature or something.. it was a very irresponsible XEP and I can't understand how XMPP-savvy people could have forgotten about the ability for a server to forge critically dangerous stanzas against the implementation of this
  58. q55 very bad, or I'm missing something
  59. mathieui well, apart from e2e content, your server already has access to everything else
  60. q55 they're safe account-external interactions, or what do you mean?
  61. mathieui q55, first, the XEP was written in another time
  62. mathieui 12 years ago, people didn’t have the same preoccupations as now
  63. mathieui (last updated more than 10 years ago)
  64. mathieui second, as I said, apart from messages encrypted with GPG/OMEMO/OTR, there’s nothing the server doesn’t already have access to
  65. mathieui and one would expect a client to adequately protect those (even if apparently gajim doesn’t)
  66. mathieui even if I can see how the "setting options remotely" part could be a bit icky in case of adversarial server
  67. q55 mathieui, you have a point. After all the server delivered any content that is retrievable via this XEP, the only real protection in jabber is given by e2e encryption
  68. mathieui q55, can’t you go into the ACE and set the "remote_control" property to "false"?
  69. q55 I only think that this feature increases the chances to hack into a client
  70. mathieui I mean, that was your question, but does it work?
  71. q55 mathieui, I did. I was asking for confirmation if that is all I need to do. From my quick tests it seems to have sufficed but you never know for sure I fear
  72. q55 confirmation that*
  73. q55 confirmation that it is*, hope it's clear.. sorry about my English
  74. q55 I wouldn't say it's a stupid feature anyway, just too unsafe to be overlooked as it was first conceived
  75. q55 mathieui, testing now. I can still command Gajim remotely
  76. q55 remote_control : disabled didn't do the trick
  77. mathieui ok, sad
  78. q55 hopefully someone here will know what to do
  79. Link Mauve q55, mathieui, I don’t know anything about that specific part of Gajim; q55, if you want to disable it, better check for the command nodes defined in the XEP and disable the code inside of Gajim, if you do it properly please also send a patch so that it can be fully disabled upstream.
  80. ciblia What is the logic in "do you want to connect insecurely" and having checkbox "never ask me again" if I cannot answer "Never connect insecurely and never ask me again"?
  81. Link Mauve ciblia, you could apply
  82. Link Mauve And change this option accordingly.
  83. Link Mauve I’m mostly waiting for Asterix to come back so that he can fix it for every single existing user.
  84. ciblia Is this another Advanced Settings Editor thing or whatever it was?
  85. Link Mauve My change would only apply it to new Gajim users who never used it before.
  86. Link Mauve Yes, search for action_when_plaintext_connection and set it to disconnect.
  87. ciblia Thanks :) I must remember that with other systems which I have Gajim on.
  88. q55 there seems to be a bug with subscriptions status. I have to restart Gajim to see the subscription status update according to authorization changes or in the buddy window is going to look as if nothing happened (and this led me to issues with my contacts because I kept re-asking them for authorization and end up with unsubscribed buddies, which wasn't easy to figure out)
  89. q55 Link Mauve, unfortunately I don't think I could make that patch myself.. sorry
  90. Link Mauve q55, did mathieui’s suggestion of using remote_control work out?
  91. q55 no, it didn't
  92. q55 Link Mauve, ^
  93. q55 I can still control Gajim remotely after disabling that entry and restarting it
  94. Link Mauve That’s very weird.
  95. Link Mauve If it’s a per-account option, make sure you disabled it in the right account.
  96. q55 no, it's universally applied to the program
  97. Link Mauve Ok, weird then.
  98. Link Mauve Check where it is used in the code.