Gajim - 2016-12-13


  1. lovetox Holger
  2. lovetox though is the label wrong?
  3. lovetox or was it really the password field above?
  4. Holger It was really the password field.
  5. lovetox Holger which server
  6. lovetox its a form we get sent from the server
  7. lovetox i can not reproduce it on any server it seems
  8. lovetox meh half of the time gajim crashes when we get send a form
  9. Holger "Oh." My private development server (jhweiss.de) :-)
  10. Holger There's no (easy) way to have the XML console show the IBR stanzas, right?
  11. lovetox hm no i dont think this show up in the console
  12. lovetox as its not tied to any specific account
  13. lovetox but i think there are many things wrong with the account creation wizard
  14. lovetox so this is probably the tip of the iceberg :)
  15. Link Mauve Holger, you can start gajim with -v and then every stanza will get printed to stdout.
  16. Holger Ah, thanks.
  17. baitisj Hi all. I have a patch that supports GnuPG KEY_CONSIDERED, and updates gnupg.py to the latest release from vsajip
  18. baitisj Well, two patches.
  19. baitisj https://paste.gajim.org/view/0c345dbd
  20. baitisj https://paste.gajim.org/view/595ab28a
  21. lovetox hi, we use gitlab now, you could make merge requests in the future
  22. lovetox also i think we will move away from including gnupg in the build
  23. lovetox we did this already for the gtk3 branch
  24. lovetox https://dev.gajim.org/gajim/gajim/commit/995a154c59b544341bb07073e493827c36244839
  25. lovetox also where did you pull your repo
  26. lovetox your files seem outdated
  27. lovetox we dont use this version of gnupg anymore
  28. lovetox and KEY_CONSIDERED was patched already in 0.16
  29. linus lovetox: re "in 99% of all cases you will open that file because it comes from a trusted source" Not necessarily. See what Martin said
  30. lovetox i dont see what martin said that contradicts that
  31. lovetox if you send me a image, and tell me look at it
  32. lovetox i will most certainly do
  33. lovetox gajim cant change that
  34. linus re "and on that matter in general, how do other chatapplication handle this? never saw a download button in whatsapp" WhatsApp is a bit of a different matter, at least as far as privacy is concerned: all the images go through their servers so there's no messing about with 3rd party HTTP URLs
  35. lovetox i wouldnt mix privacy arguments with security arguments (that you get infected with malisous software)
  36. linus They can also sanitise for malicious images on the server side (no idea if they do)
  37. lovetox priavcy wise i fully agree, to request random images is not private
  38. linus Well privacy is part of security
  39. lovetox how do you decide if a image is malisious?
  40. linus By looking at known exploitable vulnerabilities in image-processing libraries and seeing if the image would trigger such a vulnerabiliry
  41. lovetox and gajim should do this?
  42. linus Of course not
  43. linus But WhatsApp might
  44. lovetox then why do you mention it in the context
  45. lovetox or should i refrase, how should gajim decide?
  46. lovetox we cant, we can only make a good policy like, only open pictures from trusted sources
  47. lovetox thats as much security as we can implement in my opinion
  48. linus Well we could also make sure to use a library that takes security seriously
  49. linus Like graphicsmagick
  50. lovetox of course im all up for using the most secure library :)
  51. lovetox there are other people though that have the opinion an additional dependency is worse :D
  52. linus Well, it also means introducing a new dependency
  53. lovetox i for one dont care about dependencys because i just pack them into the windows installer and nobody cares :)
  54. lovetox linux people are more sensitive about that issue
  55. linus But tbh I don't think anyone who's paranoid enough to worry about which image library to go with would touch gajim with a ten-foot pole
  56. linus It's a general maintenance problem, not specifically for linux
  57. lovetox in that case, pixbuf has probably the most chance of staying maintained and its not a additional dependency
  58. lovetox i think how the image preview plugin right now is is not what was planned originally
  59. lovetox it started out as a plugin that can display images from random links, not really needed for anyone, more like a fun plugin
  60. lovetox then httpupload came
  61. lovetox without a proper way to mark a httpupload file transfer
  62. linus Yeah, I personally wouldn't put in the effort to switch to graphicsmagick
  63. lovetox so people want so see pictures inline that are sent from httpupload
  64. lovetox but because there is no way to differentiate between random links and httpupload
  65. lovetox suddenly we are in this rather bad position
  66. lovetox when i discussed this with tmolitor lately, we agreed that displaying random internet links should stay in a plugin, but httpupload filetransfer and displaying of these files should move into core
  67. lovetox but right now we miss the xeps that make it possible to differentiate between httpupload and random internet links
  68. lovetox it is possible though, conversations sends meta data of httpupload transferes with OOB
  69. lovetox but to use this was not possible until a recent patch from tmolitor, now we can save oob data to the db and pull it and use it to decide if we display the image
  70. lovetox one would catch the message incoming event, parse the oob data and write it to the "additional_data" attribute of the message obj.
  71. lovetox afterwards in the extension point passes the additional_data to the plugin
  72. lovetox and then you can decide to display it or not
  73. lovetox you could add this if you want and make it so that only httpupload filetransfers with oob data is displayed, that guarantees in a way that user actively selected a file to send
  74. lovetox and not that its a random internet link
  75. lovetox i think that would be enough security
  76. baitisj hi lovetox: $ git remote -v origin https://dev.gajim.org/gajim/gajim.git (fetch) origin https://dev.gajim.org/gajim/gajim.git (push)
  77. baitisj git branch -r shows origin/HEAD -> origin/master
  78. baitisj should I be tracking origin/gtk3?
  79. baitisj Nevermind, looks like all is good with origin/master... I submitted a pull request to py-gnupg
  80. baitisj All is good, as best I can tell
  81. lovetox baitisj, master is gtk3 branch (not released), gajim_0.16 is currently released branch
  82. linus Yeah we should really delete the gtk3 branch on gajim repo
  83. linus It creates so much confusion, especially with the plugins repo having a gtk3 branch that *is* actively used
  84. linus And developed
  85. lovetox so much confusion around the 4 people that contribute :D
  86. lovetox but yeah plugin repo is confusing
  87. lovetox they should be the same
  88. lovetox for main repo, gtk3 is the one actively developed, 0.16 only bugfixes, so it kind of makes sense
  89. linus Well there was recently a release of the 0.16 branch
  90. linus Also, apparently GTK4 is in the works -_-
  91. lovetox yeah though we use so few actual GTK3 features, that it probably will be no problem to switch to GTK4 ^^
  92. lovetox the deprecation will be a problem
  93. lovetox yeah not enough time
  94. lovetox too much code in gajim :)
  95. linus Yeah
  96. linus https://blogs.gnome.org/desrt/2016/06/13/gtk-4-0-is-not-gtk-4/ this sounds like a disaster
  97. johannes I see, GTK wants to join the "let's do a new windowing toolkit every nth year" of qt
  98. linus We should switch to xlib
  99. johannes I guess meanwhile one can count the continued API compatibility of cocoa in decades...
  100. jere linus: lovetox GTK4 is not on the roadmap https://wiki.gnome.org/Projects/GTK+/Roadmap
  101. linus Or of xlib ;)
  102. linus jere: the 3.90 bit looks like work towards GTK 4.x to me, it even links to an article about it
  103. lovetox maybe we should wait until gtk3 is finished
  104. linus Lol
  105. lovetox then switch :)
  106. lovetox from that blog post it seems like the current GTK version is more like a development version
  107. lovetox that changes often
  108. lovetox The first option is to target a specific version of the Gtk API, appearing once per two years, that stays stable forever.
  109. linus A version that cannot be built on the same machine as more recent versions. Sounds great
  110. linus Last comment: "Just as an example, Windows XP apps will run pretty much perfectly in 2016, 15 years later; with little or no modifications. That’s what we should be aiming for." Weeeell it's a little less clear-cut than that. But yeah we should switch to winapi and make support wine for running on Linux xD
  111. jere gajim-qt would sound better πŸ˜ƒ
  112. linus In terms of the numbers they're sort of doing a linux
  113. linus Except Linux has the golden rule to never, EVER break user space
  114. linus "This is bad and you should feel bad. People know what alpha, beta, release candidate, and stable mean. They don't know that gtk4 starts at 4.6, or that gtk 4.0 through 4.5 are broken and that they should not use them. Introducing the number 4 is going out of your way to be confusing, but I'd say that it's the least surprising project to have made this sort of decision. Surely there are simpler ways to push people to using other toolkits. I mean, just say "Hey guys, we wrote this toolkit for Gnome so please stop using it in your apps" would way less passive-aggressive.” Hahaha
  115. linus GTK is for GNOME, people. Let's switch to Empathy
  116. linus Ooh or we could use java swing :p
  117. lovetox but we dont have to switch always to the newest thing
  118. lovetox gtk3 has everything a xmpp client ever will need
  119. linus Exactly, hence xlib
  120. lovetox what is xlib
  121. linus Been around since 1985 or so
  122. linus https://en.m.wikipedia.org/wiki/Xlib
  123. linus Hm. One (set of) API(s) that has remained very stable, at least in terms of backwards compatibility, is HTML/CSS/JS
  124. linus Then again, implementations of it are horrendously large (Chromium is ~300MB)...
  125. johannes actually, javafx is not that bad...