Gajim - 2017-02-03


  1. kalkin So i have successfully deployed omemo on gajim-gtk3
  2. kalkin weirdly it shows the omemo button only in anonymous muc
  3. kalkin Interestingly it shows in log No devices for XXX. But XXX definitely have device keys uploaded
  4. kalkin now it works
  5. kalkin it just took some time to get the device keys I guess
  6. lovetox the button is only showed for mucs constantly
  7. lovetox on 1:1 chat it is only shown when device keys are avaiable
  8. lovetox thats a ui issue that has to be solved :)
  9. kalkin lovetox: it also tries to query anonymized muc rooms for devicelists
  10. kalkin lovetox: i "fixed" httpupload so it works with gajim-gtk3 (by changing version number), but it displays only links instead of pictures inside chat. Do I need a different plugin for pictures in the history or is it a bug and I should go searching for the fix?
  11. lovetox httpupload only uploads files, it does not display them
  12. lovetox image preview would do this
  13. kalkin ohh, ic
  14. lovetox but i dont think its ported to gtk3
  15. lovetox and if, only for non encrypted
  16. kalkin I just symlinked gajim-plugins (gtk3) repo to ~/.local/share/... and gajim printed a list of plugins which are incompatible. Is there somewhere a list of them, or should i create one? If I should create one, where should this be done?
  17. bot Yann Leboulanger pushed 2 commits to branch _refs/heads/master_ of _gajim_ <https://dev.gajim.org/gajim/gajim>: *38581b70* <https://dev.gajim.org/gajim/gajim/commit/38581b7080c16e6b4caf8a76de4ebbcd6a0b337e> Fix roster popup menu. Replace Gdk.Event with Gdk.Event.new, so that event is constructed with correct type information. This fixes showing a roster popup menu when launched using keyboard shortcut (Menu key or Shift-F10). *92f52bbc* <https://dev.gajim.org/gajim/gajim/commit/92f52bbcbdefbeac72d2534e35fda870430402ce> Merge branch 'roster-popup-menu' into 'master' Fix roster popup menu. See merge request !49
  18. kalkin lovetox: can you allow me to fork projects @ dev.gajim.org?
  19. kalkin I'm getting the error: Limit reached Personal project creation is not allowed. Please contact your administrator with questions
  20. lovetox its because you logged in with github
  21. lovetox i can make that but only when im home
  22. lovetox which will be later
  23. kalkin k
  24. kalkin no rush
  25. lovetox or you create a own account
  26. lovetox kalkin, it shows incompatible
  27. lovetox if the version number in the manifest.ini
  28. lovetox the max version number is to low
  29. lovetox normally all plugins in gtk3 branch should be ported
  30. lovetox and runable
  31. kalkin lovetox: right, but there might be other issues with it. i.e. httpupload needed to change byte handling, because of python3
  32. lovetox but it is likely that they dont have the same fixes as master branch
  33. lovetox i know linus started long ago work on porting that
  34. lovetox but i dont know how far hes gotten
  35. lovetox for me the plugin needs not only porting, also major refactoring
  36. kalkin lovetox: refactoring is good if you have the manpower for that. IMHO you should concentrate on finishing up gajim gtk3. the plugins will be ported over by people who care about it
  37. lovetox its not readable code with methods inside methods inside methods
  38. lovetox yeah thats why its not done ^^
  39. lovetox for me gtk3 branch is usable
  40. lovetox do you experience problems?
  41. lovetox non plugin problems
  42. kalkin Not really
  43. johannes Hi people, this PR for gajim-plugins just got in GitHub https://github.com/gajim/gajim-plugins/pull/1
  44. kalkin But i probably use onlu 20% of gajim features
  45. johannes Also, have a look at the last line in the description.
  46. lovetox maybe he thought he can clone on github and pull request on dev.gajim.org
  47. lovetox thats not going to work with any kind of permission
  48. lovetox yeah i will make my comments for the PR, but it seems not good
  49. lovetox the pictures are not saved in cache
  50. lovetox because they are not cached there
  51. lovetox people want to have pictures they download potentially forever
  52. lovetox not in a .cache folder that maybe gets deleted regulary
  53. lovetox .cache says to me, "not permanent"
  54. lovetox yeah though renaming only the folder should be good
  55. lovetox but thats really cosmetic ...
  56. kalkin lovetox: +1 images should be kept indefinitely. Disk space is cheap
  57. zak didn't read everything, but I think they should be stored along with the history for example
  58. lovetox i think the problem people are having is that url_image_preview also downloads images, not send with http upload
  59. lovetox random links in that sense
  60. lovetox so thats the main problem here i think
  61. lovetox why junk ends up in there picture folder then
  62. kalkin I think httpupload and image preview should be part of the core
  63. kalkin And enabled by default
  64. zak +1 and omemo of course :-)
  65. Ge0rG nobody really needs omemo.
  66. mimi89999 Ge0rG: ?
  67. mrDoctorWho I do
  68. zak Ge0rGβ€Ž: Is it so bad?
  69. mimi89999 I also...
  70. Ge0rG e2ee mostly creates a false sense of security and introduces a huge number of UX problems.
  71. zak So we just get rid of it?
  72. mimi89999 Ge0rG: What UX problems?
  73. Ge0rG zak: it's an awesome encryption protocol. But normal people don't want that, and don't even need that in many cases.
  74. Ge0rG mimi89999: ever got a "I just sent you an OMEMO encrypted message"?
  75. mimi89999 Ge0rG: So they should let the server admins and NSA read their messages?
  76. zak Ge0rGβ€Ž: That's different. "Normal people" (whoever 'normal' people are), are still people I do want to exchange messages with.
  77. zak And "normal people" do usually not maintain their own secure Jabber server.
  78. zak And I don't want to just trust the server myfriend@some.server.i.dont.know.
  79. Ge0rG mimi89999: OMEMO won't stop the NSA.
  80. zak So?
  81. gmj Wait what? The whole point of signal/OMEMO/whatber good encryption protocol is there to help the public have a better UX and be secure.
  82. zak A bicycle helmet won't protect me against a truck. Do you say I should keep it at home as well?
  83. Ge0rG gmj: but OMEMO doesn't solve the UX problem at all.
  84. zak So why not work at the UX problems?
  85. zak Just stop and abandon OMEMO because it seems to difficult?
  86. mimi89999 Ge0rG: I didn't have any UX problems with OMEMO. With OTR always.
  87. Ge0rG zak: there is a large number of UX problems in XMPP, and many of them cause people to get frustrated and quit before they even come into the place where OMEMO would help them
  88. mimi89999 Ge0rG: Where do you see those UX problems?
  89. kalkin Ge0rG: look at conversations its solved the ux problems around encryption well enough so I could migrate my family and parents to it
  90. zak You may be right in the problem, but I don't agree with your conclusion
  91. Ge0rG mimi89999: nerds joining one of the many MUCs and asking things like "why can't I have OMEMO in my MUC? Do I need to have all participants on my roster?"
  92. Ge0rG kalkin: did you also migrate them to your own private server?
  93. zak This all can be adressed. I don't think it's impossible.
  94. kalkin Ge0rG: domain at conversations.im because I'm lazy
  95. gmj Ge0rG: I have a an OMEMO MUC with my family. I've had only one time (when encryption by default got turned off) where that was an issue. We have a great time using OMEMO without issue.
  96. Ge0rG gmj: yes, but only if everybody is using [Conversations, Gajim] and after you have invested some time into getting everybody joined and trusted.
  97. Ge0rG gmj: and then one of them loses their phone and the fun begins anew
  98. kalkin Speaking about false sense of security: I know a bunch of smart security people using signal. Its all about the feeling of being secure not about security for most people πŸ˜‘
  99. zak I think it's valid to discuss UX issues here. But as I said, just abandoning E2E encryption and giving up solving these issues is in my opinion totally wrong here.
  100. kalkin zak: +1
  101. bot kalkin: You can't change karma!
  102. Ge0rG kalkin: the feeling of security can be easily created by adding a padlock and a "verisign certified" logo to the chat window.
  103. kalkin Ge0rG: this is exactly my issue with anything depending on google play and on one central authority, like signal
  104. Ge0rG Besides, OMEMO isn't OMEMO at all. There is the XEP with OLM and the implementations with axolotl.
  105. kalkin Ge0rG: I think we will talk about this today and Andy wanted to update the xep
  106. kalkin Also there are like half dozen of omemo developers, once we change the xep we can all agree on a switch day
  107. gmj Ge0rG: uhhh... You use a slider button that says to trust their new key. Verifying out of band isn't hard.
  108. Ge0rG gmj: it is if you don't see them often.
  109. kalkin lovetox: do you think we can convince asterix to drop the current s2s in favor of delivering omemo by default?
  110. mimi89999 Do we want: 1. Abandon OMEMO 2. Get OMEMO in more clients so that users of other clients don't have a problem with it... ?
  111. Ge0rG mimi89999: 3. make OMEMO actually mean OMEMO before too many people are using it
  112. Ge0rG kalkin: the concept of "switch day" is really really really scaring me.
  113. mimi89999 Ge0rG: Heh... Good point...
  114. Ge0rG kalkin: besides, how do you downgrade from OMEMO to plaintext.
  115. mimi89999 Somebody needs to either correct the XEP or the clients...
  116. zak Ge0rGβ€Ž: I'm happy that I get the idea that you don't seem to be against OMEMO in general but certain ongoing problems. And here I am with you again.
  117. mimi89999 Ge0rG: > kalkin: besides, how do you downgrade from OMEMO to plaintext. Why would one want to do that?
  118. kalkin Ge0rG: I think downgrading is a bad idea. If you really need downgrading you really have to think through your ux
  119. kalkin mimi89999: Andy is working on updating xep
  120. zak I am afraid of this "switch day" as well. It will generate a lot of hickups for so many "normal" users...
  121. mimi89999 zak: πŸ‘
  122. mimi89999 kalkin: πŸ‘
  123. Ge0rG mimi89999: I'm using multiple clients, and my main ones don't support OMEMO at all. Now I installed & tested Conversations, and everybody tries to OMEMO me.
  124. gmj The logic of *not* using e2ee is crazy. Every family, couple, work group, study group, etc. Deserves to have a *private* communication.
  125. kalkin zak: there are only two clients supporting omemo and both have an update mechanism.
  126. kalkin Ge0rG: patch your client?
  127. mimi89999 Ge0rG: Change to another client?
  128. zak kalkinβ€Ž: Just two? Conversations, ChatSecure, Gajim... I count three. And manymany ongoing work of experimental plugins which all test with the current versions of the aforementioned clients.
  129. mimi89999 kalkin: I have a contact still running Conversations 1.12.4
  130. zak And yes: People don't just update immediately.
  131. mimi89999 zak: The Pidgin plugin. Very recent.
  132. Ge0rG gmj: OMEMO won't prevent your server admin from doing nasty things to you :P
  133. Ge0rG Pidgin, the client still not supporting Carbons?
  134. zak Don't get me wrong, I see the need for some change there, but it should be done with a lot of respect, and hopefully only once!
  135. mimi89999 zak: 100% agree.
  136. kalkin mimi89999: they should upgrade. Its stupid to use such an old and unsupported versions (sorry for being bluntL
  137. mimi89999 kalkin: She got it from F-Droid, uninstalled F-Droid and doesn't see a reason to update because she is almost not using it... And doesn't know how to install F-Droid.
  138. gmj Ge0rG: it won't?
  139. Ge0rG gmj: it merely reduces the number of nasty things.
  140. kalkin mimi89999: I'm sorry, but this is an issue no one can solve beside the person it self
  141. gmj Ge0rG: citation needed.
  142. mimi89999 kalkin: I know.
  143. mimi89999 kalkin: I tried...
  144. Ge0rG gmj: the server could replace all of your contacts with other ones, redirect/omit messages, send messages to you, delete your OMEMO pre-keys etc.
  145. lovetox Yes Kalkin i thin we can include it per default as soon as we have a good number of clients that support OMEMO
  146. mimi89999 Ge0rG: But then one will notice and change servers...
  147. gmj Ge0rG: I thought OMEMO keys were device based. How could the server manipulate those
  148. gmj ?
  149. mimi89999 gmj: Announce other keys...
  150. Ge0rG gmj: the server could provide different keys to the other side and MITM you, unless you manually verify the keys OOB
  151. lovetox if the pidgin plugin is released, and jitsi probably also gets it i think there is no reason to have the old encryption standard set to default anymore
  152. kalkin lovetox: define good number. The previous e2e implementation is supported only by gajim
  153. kalkin lovetox: is there any roadmap for what needs to be done to release gajim gtk3
  154. lovetox no, actually we have one problem only with the roster, than i would release the first version
  155. lovetox not everything has to work perfectly i think
  156. zak Ge0rGβ€Ž: I still don't get it why your proposal because of some problems is, to stop implementing E2E encryption at all.
  157. lovetox most basic things should though
  158. kalkin Call it rc
  159. gmj Ge0rG: wait, I thought INPUTmice trust model prevented that. If not, enlighten me.
  160. mimi89999 lovetox: The shift+enter works?
  161. kalkin lovetox: according to Daniel no one is working on jitsi omemo
  162. lovetox yeah it should mimi
  163. lovetox kalkin yes indirect
  164. Ge0rG gmj: the trust model only prevents it once you have manually verified a contact out-of-band
  165. lovetox jitsi uses smack xmpp lib
  166. lovetox and there is one implementing omemo into smack
  167. kalkin lovetox: the smack omemo guy is currently sitting next to me :)
  168. lovetox say hi from me :)
  169. zak from me too ;-)
  170. Ge0rG zak: I didn't propose that. I merely said that the importance of e2ee is greatly overstated.
  171. kalkin lovetox: according to daniel jitsi uses a very old smack versions and it doesn't seem like they have an intention to update
  172. zak Ge0rGβ€Ž: Okay.
  173. lovetox hm ok :/ so who uses smack?
  174. mimi89999 kalkin: Jitsi is complete shit (sorry for the word)
  175. kalkin lovetox: paul also says hi
  176. Ge0rG lovetox: yaxim uses smack.
  177. kalkin lovetox we are starting talking about omemo, you could join the cisco video conference
  178. kalkin and the summit room
  179. Ge0rG but merely having a library that implements something doesn't mean it's easy to integrate
  180. kalkin https://go.webex.com/go/j.php?MTID=m54f3c531233347009126b430ece6c024
  181. lovetox kalkin sorry im at work
  182. lovetox have to go know, i think you guys will do this fine without me :)
  183. lovetox just tell me what i should implement afterwards ^^
  184. kalkin lovetox: πŸ‘πŸ˜€
  185. mimi89999 kalkin: Who can watch the conference?
  186. kalkin everyone
  187. mimi89999 What language is it?
  188. kalkin english
  189. kalkin btw current working version of the new Omemo XEP published by andy http://home.halifax.rwth-aachen.de/~strb/xep-0384.html
  190. kalkin by working i mean andy is working on it :)
  191. zak So, to become a little more constructive again... regarding the OMEMO/E2E-encryption UX: 1. In my opinion there is an important premise: To have *good* E2E encryption, the user just has to be aware of some knowledge regarding key/fingerprint verification. This just cannot be left to any application, no matter how good the UX is. The user just *has* to know, that he *needs* to verify this in some way if he wants this additional bit of security. 2. But: I think it's completely valid for most common users to just not carry this to the extremes, really verify the keys everytime and to just "trust" that the generated key and its exchange has happened sufficiently secure. He might of course even disable E2E if he doesn't care. 3. Still, there is the case where A wants to communicate with B, while A is security aware and knows about fingerprints and such, while B does not. In this case the application should still support E2E encryption and give A the possibility to stay secure in this regard. My conclusion is then, to support E2E as good and unintrusive as possible and make a good separation between "encrypted, but not verified which is okay" and "you can do more if you want and understand". It should on the one hand not create a false sense of security, but on the other hand not hide that there can be done more if the user is willing to engage in this matter. Daniel's concept handles this (not perfect) but very well I think.
  192. zak Dammit... wasn't finished.
  193. zak But it's okay I think.
  194. mimi89999 kalkin: Hmm... I see some people, but I don't hear anything...
  195. johannes lovetox: some nice begins on the gtk-general-menu case
  196. lovetox actually i think its 95% working
  197. lovetox do you have any issues with it?
  198. johannes also, I've seen some travis.yml files somewhere geared towards usage with mac, tell me if you like to have them activated with the GitHub mirror repos
  199. johannes there appear to be a lot of dead menu entries / strangenesses. but there appear to also be some issues with a recent release of the omemo plugin's database too
  200. lovetox i just tested something, generelly it would be possible i think to build a installer with it, but travis is to slow to test this without having a complety working buildscript already tested on a mac
  201. johannes We'ld need some real functional testing cases but it appears that there are no really useful, maintained options here currently
  202. lovetox johannes when did you fetch HEAD?
  203. lovetox i did some updates yesterday
  204. johannes I'll have a look
  205. johannes better slow than nothing I guess
  206. johannes there's indeed new stuff, I'll come back to you once I've tested them
  207. lovetox every menu entry shoud work ecept privacylist and archiving preferences
  208. lovetox and if you add a new account you have to restart to get the new account menu, didnt have time to trigger that on adding, only have the menubuild on start for now
  209. lovetox for the packaing for mac, i dont think i can do this without a mac
  210. lovetox just costs too much time
  211. lovetox but what i thought someone could do more easily
  212. lovetox could we not make a brew recipe, that installs every dependency and everything on "brew install gajim"
  213. lovetox ?
  214. johannes brew approach: first it would spoil your python path and the likes without usage of a thing such as virtualenv. and if one's going down that road, you could directly package it as well. second: brew has a facility for gui and bunldes programs called cask. I have not seen any serious mac gui package that would be in standard brew
  215. johannes also, brew is not that common
  216. johannes you'll probably find it on any developer minded box and likely on some scientist's boxes but definitly nowhere else
  217. Ge0rG BTW, https://wiki.xmpp.org/web/XMPP_IM_Client_Design_Guidelines was highlighted today during the summit
  218. zak Hmm... "Do not to encode any semantics into the resource, let the server generate a resource for you" ... I often find it useful to identify one of my own contacts from different devices.
  219. Ge0rG zak: I'm not in love with that point either, which is why https://dev.gajim.org/gajim/gajim/issues/8499
  220. Ge0rG Having /Gajim actually broke the experience if you had two PCs with Gajim running at the same time
  221. zak Yes that's true. But the Guideline specifically says *not* to include semantics into the resource. I think we have two issues here: Is the resource only a technical distinction? Then it should of course be randomized _and_ hidden for the user. Or should it describe the contacts end point in some way as well?
  222. zak As I said I think it can be of advantage to know which contact belongs to which device. Even when sending files by Jingle for example. I wouldn't want to try and guess.
  223. Ge0rG zak: I'm with you here, but the XSF isn't.
  224. johannes zak indeed. losing semantics from the client is an issue especially if different clients have different capabilities and thus ability to actually show a message. and with more or less accurate carbons implementations
  225. johannes also more or less sane use of priorities. and cabilities of devices to show or enter content
  226. Ge0rG johannes: there is no sane way to use priorities.
  227. Ge0rG whenever I install an XMPP client, I set prio=-5 and enable carbons.
  228. zak Maybe this should be split somehow? A description on the one hand for the user and a unique idea for the technical distinction. The description mustn't even be unique then.
  229. Ge0rG zak: users shouldn't ever see the resource string.
  230. zak okay, than some semantic information elsewhere?
  231. zak then
  232. Ge0rG zak: identity info in Caps.
  233. zak Don't know that, probably new and not widely supported for now I guess? But if it works I am for it.
  234. Ge0rG zak: http://xmpp.org/extensions/xep-0030.html#info-basic <identity>
  235. zak Like this then: <identity category='client' type='pc' name='Gabber'/>
  236. zak Looks good.
  237. Ge0rG zak: yes, like that.
  238. johannes that sounds saner. also and indication of which client is used would be nice
  239. Ge0rG I remember some client having icons of other common clients for this purpose.
  240. johannes this one, for example
  241. johannes at least with the matching plugin
  242. Ge0rG yaxim got a new icon now. Time to update the plugin :D
  243. zak Ge0rGβ€Ž: Do you know if yaxim 0.9 show up on F-Droid sooner or later as well?
  244. zak +will
  245. Ge0rG zak: I suppose it will get there in less than a week from now. I'm keeping back the git source because of a CVE I fixed in the code that isn't published yet.
  246. zak Ah, okay.
  247. Ge0rG Now is the time for an awesome spin: DO NOT USE YAXIM FROM F-DROID! ITS INSECURE!
  248. zak :-D I only have it installed to see when the next version is available.
  249. zak So, the playstore version 0.8.8 was secure?
  250. Ge0rG zak: nope
  251. Ge0rG 0.8.6 - 0.8.8 are vulnerable
  252. lovetox_ kalkin you can now fork
  253. kalkin lovetox_: ❀
  254. Ge0rG lovetox ❀ kalkin = forked child process? :>
  255. kalkin Ge0rG: πŸ˜€
  256. lovetox_ :D
  257. lovetox_ about http upload, i hope we soon get some way to embed this into some standard that gives metadata and tells us thats is a filetransfer
  258. lovetox_ i hope this new SIMS xep is that
  259. lovetox_ i think i will implement this
  260. picknick where can i disable in a chatroom the notifications for "somebody has joined the chatroom" ?(don't know exactly in english, german: "... hat den Chatraum betreten")
  261. lovetox_ preferences -> advanced -> advanced config editor
  262. lovetox_ there search for "print_status_in_muc"
  263. juan I have seen an accesible togle in the config menu
  264. lovetox_ no there is none
  265. juan If you go to 'manage bookmarks'
  266. picknick thanks, that's it
  267. lovetox_ you are right
  268. lovetox_ but there you have to set it for every muc you join
  269. lovetox_ separatly
  270. lovetox_ the config value disables it for all
  271. juan@sormani.com.ar http://i.imgur.com/UswgXXG.png