Gajim - 2014-05-20

  1. Darlan Who would have thought that Gajim 0.16 release would be delayed by over 9 - 10 months.
  2. Darlan is angry at himself for reporting on so many bugs and sending too many feature request tickets.
  3. guybrush88 Darlan, why so? bug reports and feature requests are nice for improving the software
  4. Darlan Yes, you are correct, guybrush88, but there are not enough developers who would handle these reports in shorter amount of time.
  5. Darlan Rest assured, Gajim would be the best GTK+ chat client, and one of the most desired chat clients on its next major release or the one after it.
  6. guybrush88 Darlan, at least when developers with some time will join the project will see what to work on ;)
  7. Darlan Yup.
  8. Darlan The main developers are Asterix (leader), dicson (developer and maintainer), and fedor.brunner (mostly encryption related code).
  9. Darlan I think we need developers who would work on code optimization of old code labeled as FIXME and on some UI enhancements.
  10. Darlan guybrush88, another problem is that Asterix is not active, as of now, for several weeks, which also postpones an official release.
  11. Darlan dicson, may you join Gajim's bot?
  12. dicson no
  13. dicson Darlan, I do not have access to a Asterix computer
  14. Darlan I thought it was a public bot :-P
  15. Darlan Thank you for your answer :-)
  16. SouL Oh
  17. heavymetal Hi, I sent a bugfix for the OTR plugin 4 months ago. I was wondering... what do I have to do in order to get it accepted? https://trac-plugins.gajim.org/ticket/89
  18. mathieui heavymetal, send it to the actual people maintaining it?
  19. mathieui the OTR plugin is not part of gajim.
  20. heavymetal Then, why do you manage it on trac?
  21. mathieui not sure
  22. mathieui (I’m not part of the gajim team, though)
  23. heavymetal Shouldn't the plugin authors being notified somehow of their bug reports?
  24. mathieui but the OTR plugin is there https://github.com/python-otr/gajim-otr
  25. heavymetal Ahm.
  26. heavymetal Opened an issue to clarify the matter. https://github.com/python-otr/gajim-otr/issues/7
  27. heavymetal How does gOTR know if the partner supports OTR?
  28. mathieui it doesn’t
  29. mathieui OTR is like that.
  30. heavymetal Cool, no wonder it is so widely used.
  31. heavymetal I wondered because every time I send a message to someone who does not use OTR the massage goes with an strange amount of trailing tabs and spaces.
  32. mathieui hmm?
  33. mathieui if you enable OTR and your contact does not, it will see some stuff about him not having OTR
  34. Holger heavymetal: That's OTR's poor-man's auto-negotiation.
  35. Holger heavymetal: See <https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html> -> "Tagged plaintext messages".
  36. mathieui (see also: OTR sucks)
  37. heavymetal I feared it...
  38. heavymetal It's ugly, breaks bots and annoys buddies.
  39. heavymetal Seriously, gajim XML-based E2E is *awesome*. Why every client went with the plaintext crap?
  40. mathieui because it’s mostly a hack, and doesn’t provide as many nice crypto properties as OTR
  41. heavymetal But it's usable.
  42. heavymetal Security without usability has... well, it has no use.
  43. mathieui But many people use OTR now, so this kind of defeats the point
  44. heavymetal Every gajim user gets a nice layer of protection against pasive attackers every time they talk with other gajim user.
  45. heavymetal I'm not sure, OTR implementations feel really buggy to be *that* used.
  46. heavymetal Indeed, I'm thinking about uninstalling mine and keep with Gajim OTR, but some buggy implementations can believe I do not use OTR any longer and I would lost conectivity with some contacts.
  47. heavymetal (particularly Bitlbee's)
  48. mathieui uh oh, bitlbee
  49. heavymetal Self hosted.
  50. heavymetal But you pick the point.
  51. mathieui Yeah, that doesn’t fix the bugs :°)
  52. heavymetal At least it would be nice if the protocol was eventually fixed.
  53. heavymetal e.g. make OTR negotiations in the control channel, not through the visible message channel.
  54. mathieui Link Mauve, everyone is waiting for XTLS! go go go
  55. heavymetal (as gajim does)
  56. mathieui heavymetal, yes, but there is the issue of the cryptographic analysis of the protocol, which I believe would change if we split stuff
  57. heavymetal What do you mean with split stuff?
  58. heavymetal And which is that cryptographic analysis?
  59. mathieui heavymetal, separate control/message
  60. heavymetal Ah, ok.
  61. Link Mauve Yeah, I will finish my XTLS work ~soon.
  62. mathieui though yes, the initial payload isn’t encrypted or anything, it just starts with ?OTR
  63. heavymetal hmmm... I don't think it should alter cryptographic properties.
  64. mathieui /that/ could be one thing to fix in a potential standardization of OTR
  65. heavymetal Just code as XML what before was coded as binary base64 or whatever.
  66. mathieui err
  67. mathieui the base64 is binary data, that’s the only way of sending binary data through an XML stream
  68. heavymetal I referred to the frame, not to the data itself.
  69. heavymetal That is, in XML you envelop your data (even if encoded in base64) in human and parser-friendly tags.
  70. heavymetal In the OTR protocol everything is sent as base64, I assume there is a protocol to identify kind of messages (given bits of the decoded data) and separate fields.
  71. heavymetal What's the difference between XTLS and OTR (apart from being different protocols)?
  72. mathieui OTR is protocol-agnostic, which makes it great and awful at the same time
  73. mathieui but XTLS is xmpp-centric, and creates an tunneled encrypted xmpp connection between two people
  74. mathieui and once that connection is set, you can send anything through, files, audio/video, message, etc
  75. heavymetal Cool.
  76. mathieui no implementation yet, though
  77. heavymetal Forward secrecy is achieved with Ephemeral DH?
  78. mathieui yes, just like TLS
  79. heavymetal (like in TLS)
  80. heavymetal Ok, it may be a good solution.
  81. mathieui (which is why we must nag Link Mauve until he finishes the implementation)
  82. heavymetal Altought the draft is expired in 2009 (?)
  83. heavymetal Didn't it get well reception?
  84. mathieui Well, specs are nice, but after that you have to implement it
  85. mathieui (moreover, for cryptographic stuff, you have to implement it right ^^)
  86. heavymetal No, you better do not implement it and use a library.
  87. mathieui well, you implement it in the library
  88. heavymetal (to the extent possible)
  89. mathieui but at some point, someone must do the work
  90. heavymetal OpenSSL could do a tunnel like this, couldn't it?
  91. mathieui and I must say most people are already quite happy with the current state of things when every point-to-point connection is decently encrypted, and you moderately trust the server (e.g. yours)
  92. mathieui Yes, we could and probably will use OpenSSL to encrypt the data and do the various verifications required by the protocol