Gajim - 2018-04-26

  1. steven Does the Gajim history sync work with OMEMO? In the sense that if I use the "sync everything" function and I have an OMEMO key I've been using for the last years, will i be able to see all the history
  2. bot Nicolas Cedilnik created an issue in _gajim_ < >: #9098: < Remember collapsed state of MUC's participants >
  3. lovetox steven, you cant decrypt a message twice
  4. lovetox so no that would not work
  5. steven you can't decrypt a message twice??
  6. lovetox correct
  7. lovetox thats called forward secrecy
  8. lovetox even if your key gets stolen today, an attacker will not be able to read old messages
  9. steven lovetox, can I read about that in an OMEMO paper somewhere? seems like I need to read that :)
  10. lovetox you can google forward secrecy
  11. steven Well, I'm interested in OMEMO in general
  12. lovetox then you can read the libsignal whitepapers
  13. lovetox there is no omemo paper
  14. steven oh
  15. steven that's helpful, thanks!
  16. lovetox omemo is just the xmpp protocol it has nothing to do with cryptography
  17. lovetox omemo uses the signal protocol for encryption
  18. lovetox if you want forever available history on your server
  19. lovetox PGP is the way to go
  20. lovetox but in its current state its not that nice usability wise
  21. pep. lovetox: have you tried OX yet?
  22. pep. I haven't, I'm curious
  23. lovetox the xep in its current state is not good, and i have no time to do a merge request for it
  24. pep. OK, I'd be curious to hear about it when you have time
  25. lovetox why its bad pep.?
  26. lovetox it doesnt use metadata nodes to publish keys
  27. lovetox so on every start of your client you get all keys from all your contacts
  28. lovetox over and over again
  29. lovetox also it has because of that, a problem with invalidating old keys
  30. lovetox because *not* getting a key on start from pep, does not mean the key is untrusted
  31. lovetox it could mean server was restarted, or server has no persitent pep
  32. lovetox i recommended to follow the omemo xep with publishing keys
  33. lovetox author said he agreed, but does not have time to change it
  34. bot Licaon_Kter created an issue in _gajim_ < >: #9099: < Windows snapshot: `module 'gajim.gajim' has no attribute 'GajimApplication'` >
  35. bot Tobias Wolter created an issue in _gajim_ < >: #9100: < pep metadata AttributeError >
  36. bot Philipp Hörist closed an issue in _gajim_ < >: #9100: < pep metadata AttributeError >
  37. zuglufttier Just tried Ubuntu 18.04 in a virtual machine. "apt install gajim" will install omemo and pgp plugins by default, just need to be enabled. So, looking good over there ;)
  38. lovetox hm why need they to be enabled though, i dont know if this intentional
  39. lovetox debacle?
  40. concerto o/
  41. concerto Can Gajim do something so that unencrypted files sent/received via HTTP Upload are downloaded and opened with native programs (i.e. the same way as encrypted files), and one gets previews for images/videos sent this way?
  42. zuglufttier concerto, you mean like the file explorer in your OS? For that gajim would have to start office or a pdf viewer in the background.
  43. zuglufttier If you get documents like that.
  44. concerto zuglufttier: I just want it to present both encrypted and unencrypted files to the user in the same way.
  45. lovetox why are they not presented in the same way?
  46. lovetox we only preview pictures
  47. lovetox and they should be regardless if they are encrypted or not
  48. zuglufttier concerto, ah! There is a button "Enable HTTPS verification" in the image preview plugin.
  49. zuglufttier I guess, you'd have to disable that.
  50. lovetox why?
  51. zuglufttier I don't know the purpose of the button.
  52. concerto Currently, if you get an _encrypted_ file - 1. you see a preview if it's an image and you have URL Image Preview installed 2. you click it, it gets saved in ~/.local/share/gajim/downloads/ (=you can access it again in the future), and it opens with a native application (whatever is the system default) For _unencrypted_ files, though - 1. you always see a link, no preview 2. you click it, it opens in the browser (ew), you have to manually save it somewhere to access it again (ouch).
  53. lovetox why do you recommend then to disable it?
  54. zuglufttier I thought it might be the reason why unencrypted images are not displayed.
  55. lovetox concerto, this is because we only preview httpuploaded files
  56. lovetox not every link you send
  57. concerto
  58. lovetox we cant display videos inline
  59. lovetox you were talking about images
  60. concerto lovetox: that's okay (although it'd be nice to have) - but when one clicks them, can they atleast be downloaded and opened with the default application for them?
  61. lovetox its the preview plugin, we cant preview it so we do nothing with it
  62. lovetox but yeah in the great scheme of things someday we would display this as a file transfer
  63. lovetox downloading a encrypted link is not part of the preview plugin btw
  64. lovetox its part of the omemo plugin
  65. concerto Hm...
  66. concerto lovetox: should I create an issue?
  67. lovetox
  68. bot Philipp Hörist pushed 1 commit to branch _refs/heads/master_ of _gajim_ < >: *379a4b03* < > Fix Windows build
  69. bot Philipp Hörist closed an issue in _gajim_ < >: #9099: < Windows snapshot: `module 'gajim.gajim' has no attribute 'GajimApplication'` >
  70. bot Markus Wintermann updated a merge request for _gajim/master_ < >: Add support for dynamic reloading of plugins
  71. troom i struggled a bit with rebasing, but I hope that it did work in the end
  72. bot Philipp Hörist pushed 28 commits to branch _refs/heads/gajim_1.0_ of _gajim_ < >:
  73. lovetox troom, thanks
  74. lovetox instead of configpaths.get('PLUGINS_DIRS')[1]
  75. lovetox please use configpaths.get('PLUGINS_USER')
  76. lovetox the PLUGINS_DIRS will not be backported to 1.0.1
  77. troom that's great - I like it much more this way
  78. troom 'PLUGINS_DIRS')[1] is not very verbose
  79. troom but i didn't know PLUGINS_USER exists
  80. lovetox i refactored that code, if you look at the
  81. lovetox you see very fast now whats available
  82. troom I see
  83. troom if I need both dirs I write: configpaths.get('PLUGINS_USER'), configpaths.get('PLUGINS_BASE')
  84. troom ?
  85. troom line 111 in pluginmanager
  86. lovetox why?
  87. lovetox this has nothing to do with your commit or?
  88. troom yeah, you are right
  89. lovetox if you think this should be more verbose written, i agree
  90. lovetox but dont change that in this commit
  91. lovetox because that line does not exist like that in 1.0.1
  92. bot Markus Wintermann updated a merge request for _gajim/master_ < >: Add support for dynamic reloading of plugins
  93. lovetox and this makes it harder to backport then
  94. troom about the plugin_installer - is there a need to keep it compatible with older gajim versions?
  95. lovetox im not sure
  96. lovetox i dont think so
  97. lovetox this was originally in the python2 branch, and we wanted that the plugin installer works with python2 and 3 so people ca use it to upgrade the plugins when they migrate
  98. lovetox but 0.16 users dont use master branch plugins anyway
  99. lovetox so i think we can remove this
  100. troom in my patch i checked if the new function in pluginmanager is available
  101. troom i do it in git now and will just call the function
  102. lovetox yeah that we have to for sure
  103. lovetox no i think we misunderstood each other
  104. lovetox i thought you meant the import code at the top which is targeted at older gajim version
  105. lovetox you definitly have to check the attr, if we push a new plugininstaller version
  106. lovetox then everyone gets updated
  107. lovetox also users who dont have that code yet
  108. troom ok
  109. bot Markus Wintermann proposed a new merge request for _gajim-plugins/master_ < >: completly remove plugin on reload