Gajim - 2016-12-20


  1. fm ok, i cleaned up the code and did what has been proposed in the pr comments
  2. fm lovetox, how do you prefer to continue? any thoughts on what I wrote at 22:50:55?
  3. lovetox hm
  4. lovetox no just push it to master should work
  5. lovetox Please push new commits to the source branch or use a different target branch.
  6. lovetox =)
  7. lovetox source branch is your master branch
  8. fm ok, pushed it. also "designed" an icon, which was still missing ;
  9. fm ;)
  10. lovetox johannes
  11. lovetox are you the one that runs gajim on mac?
  12. sendIP Hello, is there a possibility to send the provider IP of the server where gajim is running on to a certain user daily?
  13. sendIP sort of like a dyndns service
  14. lovetox i dont understand
  15. lovetox why is gajim running on a server
  16. sendIP well not server but normal desktop linux pc
  17. sendIP is what i mean
  18. lovetox you want to publish your current ip to other users
  19. sendIP yes
  20. sendIP like a dyndns service you know
  21. lovetox yes, its certainly possible to write a plugin that does this in gajim
  22. sendIP ah ok so there's no way gajim can do that and no plugin for that either?
  23. lovetox but out of the box, gajim cant do that, and also it would be against one idea of xmpp
  24. lovetox that the other user cant know your ip
  25. lovetox because you connecting over a server
  26. lovetox and not to each other
  27. sendIP I understand
  28. sendIP security is important indeed hm wonder if writing a plugin like that is hard
  29. lovetox why are you needing this if i may ask
  30. sendIP my linux pc is running at home but the ip changes and i can'T access it then
  31. sendIP over vnc
  32. lovetox so why not using an actual dns service?
  33. sendIP yes i thought about that but i don't know of any good ones, can you recommend some?
  34. sendIP see you have to think ;)
  35. lovetox yeah but only because i dont use one
  36. sendIP m2 normally
  37. lovetox free dns google gives many results
  38. lovetox for example this looks nice
  39. lovetox https://ddnss.de/
  40. sendIP ok and any tips on which openwrt thing i'd need to download?
  41. lovetox no sorry i dont have an idea
  42. zak country?
  43. sendIP ok, because there are so many results when i search for "openwrt dyndns"
  44. sendIP germany
  45. sendIP of course :D
  46. lovetox https://wiki.openwrt.org/doc/howto/ddns.client
  47. zak spdns.de
  48. sendIP other question: does xtightvncviewer encrypt by default? (let me know if such questions of off topic because this is a gajim room)
  49. sendIP got it, it's not, but https://wiki.ubuntuusers.de/VNC/#VNC-ueber-SSH solves it
  50. sendIP the problem using dyndns services is that one relies upon them
  51. linus If you have a server with a fixed IP you can host your own
  52. linus And a domain*
  53. sendIP had i one i wouldn't need a dyndns-thing :)
  54. sendIP feel like a plugin would be nice. yes it reveals ip
  55. linus The client can't even find its own IP by itself
  56. linus You need something like STUN to actually find it out
  57. linus Using dynamic DNS is a better solution
  58. sendIP i thought i could fun ifconfig from the plugin
  59. sendIP run*
  60. sendIP and grep the ip from there
  61. linus And there are so many out there that being tied to the provider isn't a problem
  62. linus No, that'll only get your IP address in the network you're connected to
  63. linus You're very likely to be behind a NAT which means your desktop doesn't even know its public IP
  64. linus The only ways that won't be the case is if your desktop is connected directly to a modem or if you have IPv6
  65. sendIP well, that was rather fast: i think you convinced me to go with the well known dyndns-service solution. this problem remembers me of how skype uses all kinds of techniques to get the ip (not that i would use proprietary skype).
  66. sendIP ah ok
  67. linus Skype can easily find your IP address because you connect to their servers
  68. linus No special techniques behind it
  69. sendIP I've read long ago there was something with skype and not and how skype goes through firewalls and stuff, idr what it was exactly
  70. sendIP lol you're right, ifconfig does now show provider ip xd my bad
  71. linus NAT traversal is necessary for anything peer-to-peer, and isn't really a privacy problem
  72. sendIP not*
  73. linus If revealing the IP address your provider gives you is a problem, it's quite a difficult problem to solve
  74. sendIP good to know that i don't need to code a plugin now xd
  75. linus You'd need to use a proxy service you trust, or tor, or similar
  76. sendIP the user where the ip is being sent would be me again, so no privacy issues
  77. linus Well it's also going to the dynamic DNS provider and anyone who knows the domain name you're using
  78. sendIP indeed
  79. sendIP but since the vnc is password protected, i guess there's not much to it?
  80. linus If it's for VNC, it's very important that the connection is encrypted
  81. sendIP yes, i found this https://wiki.ubuntuusers.de/VNC/#VNC-ueber-SSH tunneling the trafic through ssh
  82. linus Otherwise anyone who's forwarding the traffic can see your password
  83. linus Yeah, if it's through ssh it's fine
  84. sendIP "ow secure is TightVNC? Although TightVNC encrypts VNC passwords sent over the net, the rest of the traffic is sent as is, unencrypted"
  85. sendIP i think so
  86. sendIP so how could a plugin get the public ip again?
  87. linus Via STUN
  88. linus Which is just a way for a client to connect to a server and ask it "what's my IP"
  89. sendIP could it use https, go to a https://myip.xx site and grep the ip form there?
  90. linus So it also involves a third-party server
  91. JKing You can also possibly use uPnP or NAT-PMP.
  92. linus Yeah but that's more complicated than STUN
  93. linus JKing: I'd say that's less reliable
  94. JKing Depends on your set-up. For me it was easier. Agreed it's potentially less reliable, though.
  95. linus STUN will work from anywhere (unless there's a firewall configured to block that)
  96. sendIP i see, stun is supposed to do exactly what i want, when i read wikip.
  97. sendIP "Mit Hilfe von STUN lässt sich die derzeit öffentliche IP-Adresse des Anschlusses ermitteln." besser gehts nicht lol
  98. sendIP ok, thanks for your help i guess ( of course feel free to write a small plugin that gets the public ip and sends it to a certain chosen user :) )
  99. lovetox Link Mauve, linus
  100. lovetox https://dev.gajim.org/gajim/gajim-plugins/issues/165
  101. lovetox whats your opinion
  102. Asterix new plugin installer works nicely under win
  103. Asterix Thanks a lot guys!
  104. linus Cert pinning is good. Plugin signatures would be better.
  105. linus lovetox, whenever you get back ^
  106. boyska linus, how would you like plugin signatures to happen? I'm confused about it
  107. linus PGP signatures of the files
  108. linus Which would make it possible to mirror them without breaking the trust
  109. boyska and who will be signing the zip files? a central repo maintainer or plugin maintainer?
  110. linus Probably a gajim maintainer. Idk
  111. linus Wait, there are no signatures for gajim's source tarballs either? :|
  112. boyska indeed
  113. boyska the point is that, in that case, any plugin update must wait for this specific maintainer to sign the zip file
  114. linus Also, the source download still uses the mercurial icon
  115. boyska which is... less than optimal
  116. linus Doesn't necessarily have to be one specific person, could also follow a wot model. But some sort of signature that's independent of the transport would be good regardless.
  117. boyska it also makes me wonder how this developer(s) will checkout the plugin before signing it
  118. boyska so the point is: do you propose to get security in a transport-agnostic way? or to protect from adversaries that would be able to attack the plugin installer even with certificate pinning?
  119. boyska the second requires that strong verification is used all the way from push to a release
  120. linus Mostly the former.
  121. boyska the first can "easily" be done letting manifest.zip be automatically signed by a bot, instead of a real person
  122. Asterix gpg is not an option. We won't ask users to install gpg to download plugins
  123. boyska btw, signify is probably better than pgp for this specific task
  124. boyska Asterix, optional dependencies are easy and nice
  125. linus boyska: not really if it's key for plugin downloading
  126. boyska what is not easy is programmatically using gnupg; my experience is sooo bad
  127. Asterix none of the noobs will have that. So if we sign for 3% of users, that's useless. attacker will be happy to touch 97% of the users
  128. boyska linus, not really /what/
  129. boyska actually gpg is installed by default on so many linux distro
  130. boyska (because package managers use that)
  131. linus Having it as an optional dependency isn't really nice if it's used for securing plugin downloads
  132. boyska seriously, signify (regardless of which implementations) is much easier to deal with; the point is that you still have to deal with WoT, which is what noone ever wants to do
  133. boyska linus, I don't get how it can be worse than not signing at all :)
  134. linus Well I didn't actually mean wot, I meant a key hierarchy
  135. linus My bad
  136. boyska it still is a mess :)
  137. linus Eh, a safer mess than the global PKI :p
  138. boyska it ends up reimplementing a distro's package manager, plus all the practice for key sharing, signing, managing a special keyring only for gajim... urgh
  139. linus True
  140. boyska anyway, I'm happy to contribute with what I can; and I think that from a security standpoint, a strict configuration of HTTPS can be a pretty good improvement
  141. boyska I hardened it some more, requiring tls >= 1.2