XSF logo XSF Discussion - 2017-09-25


  1. Guus has left
  2. winfried has joined
  3. jjrh has left
  4. Guus has left
  5. Valerian has joined
  6. jere has joined
  7. Guus has left
  8. stefandxm has left
  9. Tobias has joined
  10. SamWhited has left
  11. Tobias has joined
  12. efrit has left
  13. jere has joined
  14. Zash has left
  15. Zash has left
  16. Zash has left
  17. Zash has left
  18. Zash has left
  19. Zash has left
  20. Zash has left
  21. Zash has left
  22. Zash has left
  23. Zash has left
  24. Zash has left
  25. Zash has left
  26. Zash has left
  27. Zash has left
  28. Zash has left
  29. Zash has left
  30. Zash has left
  31. Zash has left
  32. Zash has left
  33. Zash has left
  34. Zash has left
  35. Zash has left
  36. Zash has left
  37. Zash has left
  38. Zash has left
  39. Zash has left
  40. Zash has left
  41. Zash has left
  42. lskdjf has joined
  43. daniel has left
  44. daniel has joined
  45. daniel has left
  46. stefandxm has joined
  47. Guus has left
  48. daniel has joined
  49. daniel has left
  50. stefandxm has left
  51. la|r|ma has left
  52. daniel has joined
  53. Guus has left
  54. daniel has left
  55. la|r|ma has joined
  56. Valerian has left
  57. Valerian has joined
  58. lskdjf has joined
  59. daniel has joined
  60. Yagiza has joined
  61. stefandxm has joined
  62. Alex has joined
  63. uc has joined
  64. Valerian has left
  65. daniel has left
  66. daniel has joined
  67. stefandxm has left
  68. jjrh has left
  69. jjrh has left
  70. Alex has left
  71. waqas has left
  72. tim@boese-ban.de has left
  73. emxp has joined
  74. efrit has joined
  75. stefandxm has joined
  76. jere has left
  77. stefandxm has left
  78. Guus has left
  79. Guus has left
  80. Zash has left
  81. Zash has left
  82. SamWhited has left
  83. Guus has left
  84. ralphm has left
  85. daniel has left
  86. daniel has joined
  87. Guus has left
  88. Steve Kille has left
  89. tim@boese-ban.de has joined
  90. tim@boese-ban.de has joined
  91. Wiktor has joined
  92. Wiktor has joined
  93. Guus has left
  94. efrit has left
  95. tim@boese-ban.de has left
  96. Guus has left
  97. andrey.g has left
  98. daniel has left
  99. daniel has joined
  100. stefandxm has joined
  101. tim@boese-ban.de has joined
  102. winfried has joined
  103. stefandxm has left
  104. Ge0rG Is it possible to test XEP-0368 Direct TLS without actually creating the DNS records? You can't put SRV into hosts files :(
  105. Guus has left
  106. jonasw Ge0rG, test the implementation at the client or at the server?
  107. Ge0rG jonasw: test a server deployment
  108. Kev Ge0rG: dnsmasq running locally.
  109. jonasw most clients allow to specify a port
  110. jonasw and a host to connect to explicitly
  111. jonasw so you’d use that
  112. Ge0rG Yeah, I once enabled it in Gajim with a dozen clicks or so.
  113. Yagiza has left
  114. Wiktor has joined
  115. Wiktor has joined
  116. zinid guys, what string should be put in SNI in the case of IDN domain? original or pynnycoded?
  117. jonasw zinid, interesting question, that I’d like to know too :-)
  118. zinid ah, found in RFC6066
  119. zinid "HostName" contains the fully qualified DNS hostname of the server, as understood by the client. The hostname is represented as a byte string using ASCII encoding without a trailing dot. This allows the support of internationalized domain names through the use of A-labels defined in [RFC5890].
  120. zinid so should be punnycoded
  121. jubalh has joined
  122. jonasw mhm
  123. daniel has left
  124. Ge0rG I wonder if I should move the yax.im A records to point to the XMPP server instead of the web server, so that clients that fail SRV will still properly connect.
  125. Guus has left
  126. Ge0rG It looks like 15% of client connections ignore SRV for yax.im
  127. daniel has left
  128. edhelas Hi, I'd like to know the state of this PR ? https://github.com/xsf/xeps/pull/500
  129. jonasw edhelas, I think some council votes are pending, I haven’t processed last council meetings minutes yet, sorry
  130. jonasw edhelas, most efficient will be if you ping me on the PR, I’ll take care of it when I get home
  131. edhelas okay
  132. Guus has left
  133. edhelas I'm also planning to do other PR on 0060, maybe today
  134. dwd has joined
  135. Guus has left
  136. valo has joined
  137. valo has joined
  138. Flow has joined
  139. Guus has left
  140. goffi has joined
  141. Wiktor has joined
  142. ralphm has left
  143. daniel has left
  144. valo has left
  145. Guus has left
  146. valo has joined
  147. Wiktor has joined
  148. Wiktor has left
  149. Wiktor has joined
  150. Wiktor has left
  151. Wiktor has left
  152. Wiktor has left
  153. Wiktor has left
  154. zinid has left
  155. Wiktor has left
  156. daniel has left
  157. dwd has left
  158. dwd has joined
  159. Guus has left
  160. Wiktor has left
  161. stefandxm has joined
  162. edhelas jonasw what is your github account nickname ?
  163. jonasw edhelas, @horazont
  164. edhelas danke
  165. jonasw de rien
  166. daniel has left
  167. dwd has left
  168. dwd has joined
  169. jubalh has joined
  170. edhelas I'm also planning to do another PR on 0060, but I'd like to get some feedbacks here before
  171. edhelas I'd like to expose the access_model of the nodes in their metadata
  172. edhelas I'm wondering if this could brings issues
  173. edhelas basically adding pubsub#access_model there https://xmpp.org/extensions/xep-0060.html#entity-metadata
  174. lovetox has joined
  175. daniel has left
  176. stefandxm has left
  177. Zash has left
  178. daniel has left
  179. daniel > It looks like 15% of client connections ignore SRV for yax.im Would be interesting to know what clients those are and whether or not they are using Tor
  180. jjrh has left
  181. daniel conversations.ims numbers are equally high. Maybe even closer to 20%
  182. Wiktor has left
  183. Wiktor has joined
  184. daniel has left
  185. lumi has joined
  186. Ge0rG I'll do some version logging for the next days.
  187. jonasw Ge0rG, how are you going to track that?
  188. jonasw also, I’ve seen clients fall back to A/AAAA if they try to connect before DNS is up
  189. Ge0rG jonasw: modified mod_query_client_ver in prosody. Non-SRV connections to yax.im all come through a NAT on the web server
  190. jonasw the SRV lookup fails (and they cannot necessarily distinguish the reason) and go on with A/AAAA, which may then pass :/
  191. Ge0rG I've had very often "Connection refused" errors from my own yaxim instance for a week or so, and then I realized the NAT rule got reset.
  192. jonasw I think that the A/AAAA fallback may be doing more harm than good
  193. jonasw I’ve had very confusing certificate errors for weeks until I realized that A/AAAA pointed to a test instacne which wasn’t supposed to be live where the certificates had expired. I don’t even want to know what happened *before* the certificates expired ...
  194. Ge0rG jonasw: it's clearly a bug, the question is just _where_.
  195. jonasw the root cause is probably that applications cannot (do not?) distinguish between "network errors" and "records don’t exist"
  196. Ge0rG Yeah.
  197. jonasw with validating resolvers, you’ll also always rather see a generic validation error in favour of a NXDOMAIN if the backedn experienced network errors
  198. jonasw so that isn’t going to go away
  199. jonasw well, okay, that actually improves things.
  200. jonasw if the API exposes the difference
  201. tim@boese-ban.de has joined
  202. Ge0rG It looks like most Non-SRV connections are from yaxim, followed by Conversations. And then some Pidgin and Cackle.
  203. Ge0rG However, the stats are skewed because I query on new connections, and those happen far more often on mobile
  204. tim@boese-ban.de has joined
  205. jonasw and your userbase is probably also skewed
  206. jonasw towards yaxim
  207. Ge0rG No way! I'm a neutral server operator!
  208. jonasw that may be, but are you also a neutral app developer? ;-)
  209. daniel cackle is just a Conversations fork though
  210. daniel or theme
  211. Ge0rG There also was one MAXS.
  212. jonasw MAXS <3
  213. MattJ MAXS <3
  214. Flow
  215. Ge0rG daniel: did you change the DNS records for conference.siacs.eu around noon on Saturday? My prosody wasn't able to resolve the server in the morning, then came up with an old(?) IP aroung 11:15, and then failed to resolve again.
  216. winfried has joined
  217. fp-tester has left
  218. fp-tester has joined
  219. Wiktor has joined
  220. daniel Ge0rG, we switched over on friday at ~23:45
  221. daniel i don't think i've touched the records since
  222. Ge0rG daniel: I'm sure this was a weirdness in prosody's DNS code, but I wanted to be 100% sure with that.
  223. Ge0rG daniel: and 78.47.217.197 was the old IP?
  224. daniel sounds about right
  225. Ge0rG daniel: I'll quote you on https://prosody.im/issues/issue/1001 if that's ok.
  226. la|r|ma has joined
  227. daniel i just created srv records. but that doesn't seem to help
  228. tim@boese-ban.de has joined
  229. winfried has left
  230. daniel or maybe it did and just takes some time to propagate https://status.conversations.im/reverse/conference.siacs.eu/
  231. daniel let's wait and see what happens
  232. Ge0rG prosody has some strange bugs in handling CNAMEs.
  233. lskdjf has joined
  234. Wiktor has left
  235. goffi has left
  236. goffi has joined
  237. xnyhps has joined
  238. xnyhps has left
  239. Ge0rG has left
  240. jcbrand has joined
  241. andrey.g has joined
  242. jcbrand has left
  243. zinid has left
  244. daniel creating the srv record did in fact fix it
  245. Ge0rG daniel: ...worked around ;)
  246. Ge0rG has left
  247. daniel semantics
  248. Ge0rG The XSF is 90% about semantics.
  249. stefandxm has joined
  250. tim@boese-ban.de has joined
  251. Guus has left
  252. sonny has left
  253. sonny has joined
  254. Wiktor has left
  255. jabberatdemo has joined
  256. jabberatdemo has left
  257. dwd CNAMEs are really odd. They shouldn't work (but might) in combination with SRV records, for a start.
  258. Ge0rG Yeah, but they don't even work without SRV.
  259. dwd Ge0rG, Arguably they shouldn't - RFC 6120 § 3.2.2 only says A or AAAA. That probably implies CNAME (and DNAME), though.
  260. jonasw DNAME is entirely DNS-server-side anyways, isn’t it?
  261. dwd Ge0rG, You *can* - in principle - use CNAMEs for, say, _xmpp-server._tcp.example.org. Just not for whatever the hostname it looks up to is.
  262. daniel has left
  263. dwd jonasw, There's a fallback to do that, but I think there's an EDNS0 flag for handling them client-side.
  264. Ge0rG dwd: but the service name is a CNAME, and it doesn't resolve
  265. dwd Ge0rG, What do you mean by the service name?
  266. Ge0rG dwd: conference.siacs.eu. 300 IN CNAME xmpp-hosting.conversations.im. xmpp-hosting.conversations.im. 300 IN A 91.250.85.114
  267. Alex has joined
  268. dwd So that only works is the process looking up decides it'll use gethostbyname/getaddrinfo, or else do DNS directly but follow CNAMEs.
  269. dwd Neither is spelt out in RFC 6120 § 3.2.2.
  270. Guus has left
  271. Ge0rG I'm not sure RFC6120 is the right place to define how DNS should work.
  272. Ge0rG However, with the wording you referenced, I could blame daniel for not following the RFC, instead of blaming prosody for having a broken CNAME lookup mechanism.
  273. stefandxm has left
  274. jonasw given that we have SRV, I don’t see the reason for CNAMEs in any case.
  275. jonasw (as mentioned earlier, I think the A/AAAA fallback does more harm than good)
  276. stefandxm has joined
  277. Ge0rG jonasw: SRVs happen to be black magic from the future for many DNS providers.
  278. jonasw what
  279. Holger So the Prosody people broke their CNAME caching in order to strictly follow RFC 6120?
  280. zinid lol
  281. Ge0rG jonasw: with some DNS operators, you can't add SRV entries.
  282. Guus has left
  283. MattJ Holger, just for the record... no :)
  284. jonasw Ge0rG, I understood, but I am horrified
  285. jere has joined
  286. zinid so these providers don't follow RFC6120?
  287. zinid we need to notify them
  288. Ge0rG zinid: oh, they do.
  289. Ge0rG it's the others that don't.
  290. Holger jonasw: You might have the CNAME record for other services anyway. Apart from that you might want to maintain the SRV targets in a single record and have multiple CNAMEs pointing to that.
  291. Guus has left
  292. Holger dwd: I agree with Ge0rG that 6120 sounds like the wrong place to specify such things. But if it's the right place, then missing CNAME support sounds like an obvious 6120 bug to me.
  293. dwd Holger, I don't think it is specifying how DNS works. I do think it ought not to be quite so precise in the lookups involved.
  294. Guus has left
  295. Alex has left
  296. Holger Just sounds wrong to me that each and every protocol that uses DNS names should specify "yes we also resolve CNAMEs like everyone else".
  297. Holger As opposed to just specifying the parts that are *specific* to this protocol.
  298. Alex has joined
  299. pep. has left
  300. sonny has left
  301. jonasw I bet there’s some wording in the document defining CNAME that resolvers (including stub resolvers) MUST follow CNAMEs transparently or so
  302. Yagiza has joined
  303. Yagiza has joined
  304. daniel has left
  305. daniel has joined
  306. sonny has joined
  307. sonny has joined
  308. Guus has left
  309. Guus has left
  310. Flow > ‎[14:07:11] ‎jonasw‎: (as mentioned earlier, I think the A/AAAA fallback does more harm than good) Given the amount of DNS implementations not supporting SRV RRs, I doubt that this is true
  311. Flow what Holger said
  312. zinid just let's use NAPTR to break things completely :)
  313. jonasw Flow, is there a list of such popular services?
  314. jonasw and IM services hosted there? they should apply some pressure.
  315. Flow jonasw: I'm not only talking about services, more about all things DNS
  316. jonasw the issue with the fallback is that it forces services using SRV records to also have valid A/AAAA records or at least it constraints what you can do with the A/AAAA of the domain.
  317. Flow jonasw: It doesn't force them
  318. Flow but yes, for maximum connectivity you want to have your XMPP domain also resolve A/AAAA
  319. jonasw Flow, no, if there are intermittent issues which makes the client believe that the SRV records don’t exist, they fall back to A/AAAA
  320. jcbrand has left
  321. jonasw and that’s an issue
  322. Flow it's an issue if there are no A/AAAA records
  323. jonasw or if the records point to something which isn’t the XMPP service you wanted to connect to
  324. Flow but how would not having the A/AAAA fallback improve the situation
  325. jonasw if there are no A/AAAA records, it is more or less obvious to clients that they should re-try later because it’s most likely network
  326. jonasw (or a configuration error)
  327. jonasw but if end up in the fallback (e.g. on a transparent stream-managmeent reconnect) and the fallback is not the XMPP service you’re looking for, a lot of funny stuff can happen, from certificate errors, over stream errors to authentication failed
  328. jonasw all of which will probably nuke the clients state
  329. jonasw that’s what I mean by "harm"
  330. jonasw (I had that once with an unfortunately configured A/AAAA record which pointed to another XMPP service)
  331. jonasw (took me weeks to figure out what the reason for those errors were)
  332. SamWhited has joined
  333. Valerian has joined
  334. Ge0rG has joined
  335. winfried has joined
  336. goffi has left
  337. mimi89999 has joined
  338. goffi has joined
  339. daniel has left
  340. daniel has joined
  341. waqas has joined
  342. Wiktor has joined
  343. Flow jonasw: I see, but without the fallback you wouldn't even be able to connect as soon as SRV breaks for some reason
  344. daniel has left
  345. daniel has joined
  346. mimi89999 has joined
  347. jjrh has left
  348. SamWhited has joined
  349. jonasw Flow: yes, and treating it as a network error would do the right thing (retry soon)
  350. Flow jonasw: Not if it's your resolver lib not being able to perform SRV lookups
  351. Flow or you home router resolver
  352. jonasw but you can't distinguish a wrong A/AAAA you should never have seen from incorrect credentials or something
  353. jere has left
  354. jere has joined
  355. Flow incorrect credentials should return a well defined error, no?
  356. Flow but, yes, the situation is not ideal
  357. stefandxm has left
  358. jonasw Flow: sure it does, but you can get such an error when connecting to the wrong xmpp service due to A/AAAA lookup
  359. jere has left
  360. jere has joined
  361. Wiktor has left
  362. Wiktor has joined
  363. Wiktor has joined
  364. Flow i see
  365. Valerian has left
  366. sonny has joined
  367. sonny has joined
  368. Guus has left
  369. dwd has joined
  370. dwd has joined
  371. Ge0rG When I send a MUC join and lose my connection, so that it will be closed by a 0198 timeout, prosody will send error responses to all queued stanzas, including individual MUC participants. Is that good / bad / ugly / all of the above?
  372. la|r|ma has joined
  373. jonasw Ge0rG, I think MUCs won’t route error messages back. sending back error presences is the right thing.
  374. Ge0rG Except that some funny MUC implementation will also kick all my MSNs
  375. Ge0rG or is that NMSs?
  376. jonasw sure, but that are broken MUC implementations then
  377. jonasw not sending unavailable presence would be desastrous
  378. Ge0rG jonasw: it's okay to send presence-unavailable to my own nickname, but to all the participants?
  379. jonasw oh!
  380. Ge0rG or rather, presence-error.
  381. Guus has left
  382. jonasw to the participants doesn’t seem right to me
  383. dwd Ge0rG, I'm not sure I understand what the problem you're describing is.
  384. Ge0rG it's right from the 0198 session destruction context, though.
  385. Holger What's the downside with just dropping all presence stanzas on 0198 timeout?
  386. Holger How does the error stanza help anyone?
  387. MattJ If you send presence to someone, do you expect an error if they don't ever receive it?
  388. dwd Ge0rG, So you have an existing local session connected to a local MUC, in a 198-detached state, and then this times out?
  389. Holger MattJ: I don't.
  390. Holger MattJ: Because how would I handle that error?
  391. dwd Holger, Giant modal dialog box of course.
  392. Holger Hehe.
  393. dwd Holger, I'm surprised you had to ask.
  394. Ge0rG dwd: I'll try again: 1. I send a join presence to a MUC 2. I disappear into the void 3. The MUC sends everything that's sent on join to my 0198 cache 4. my 0198 session gets destroyed, so my server sends an error response for each individual stanza in the cache, including all the participant presences.
  395. dwd Ge0rG, Ah, OK. And what's wrong with that?
  396. Ge0rG dwd: the flood of presence errors to MUC participants.
  397. dwd Ge0rG, Ah, OK. And what's wrong with *that*?
  398. Ge0rG dwd: that was the point of my question. Is it wrong or just ugly.
  399. Holger Being useless?
  400. dwd Holger, Useless is OK, or at least it's nothing bad, surely?
  401. Holger It's nothing bad.
  402. jonasw I’m not sure
  403. jonasw sending presences to other MUC participants is at least weird
  404. dwd Ge0rG, I think it's right. Although I don't think the MUC should be broadcasting presence errors - it should juts error you out fo the MUC and broadcast that.
  405. jonasw because that’s normally how you join/change nicknames
  406. Valerian has joined
  407. Ge0rG dwd: I don't know what the MUC does with the flood, to be honest
  408. Valerian has left
  409. dwd Ge0rG, If it just absorbs it, that's fine. I think.
  410. Ge0rG dwd: sounds reasonable to me.
  411. dwd Ge0rG, The problem is that to stop it, we'd need to track not just the stanzas, but the semantics of those stanzas.
  412. dwd And that's really the MUC entity's job, I think.
  413. jonasw shouldn’t all MUC presences have an <x/> in them which makes it easy to find?
  414. dwd (At least, wherever possible)
  415. Holger Nah.
  416. Ge0rG jonasw: and <x/> specific code in 0198 as well, now?
  417. jonasw Ge0rG, *shrug*
  418. Holger My question was: My not just silently drop *all* presence stanzas on 0198 timeout?
  419. Ge0rG Let's fix 0045 first.
  420. Holger No matter whether MUC-related or not?
  421. goffi has left
  422. goffi has joined
  423. Holger Is there a single use case where the originator of the presence would handle the error message in any other way than ignoring it?
  424. dwd Holger, I don't think that's needed, or desirable. If an error would be generated immediately on session close, then it should be generated on 198-closure.
  425. Holger It would not be generated without 0198, no?
  426. jonasw does one get presence-errors when sending a presence to an unavailable entity?
  427. Holger This is a 0198 (mis)feature.
  428. Holger No.
  429. dwd jonasw, Ah, that's a "sort of". You get a presence error if your sending the presence causes an error to be detected.
  430. dwd Speaking of 198, what are people setting the timeout to these days?
  431. jonasw I have it set at 5 or 10 minutes I think
  432. jonasw I have it set at 10 minutes.
  433. dwd jonasw, Any statistics on hit/miss of resume attempts?
  434. Ge0rG On my personal server I set it to 2h, because when on bad mobile my data connection might get interrupted for so long due to a phone call
  435. jonasw dwd, I don’t think I have logs with enough detail, also my userbase is approximately 10.
  436. SamWhited Ge0rG: Is that a CDMA thing that your data gets cut off when you're on a call?
  437. Ge0rG SamWhited: no, it's a 2G/LTE thing.
  438. Holger When I looked some years ago, my impression was that most resumptions happen within 5 minutes. Which seems to be a common default.
  439. dwd thinks hit/miss statis would be amazingly interesting.
  440. Ge0rG SamWhited: 3G can route voice and data at the same time, the others can't
  441. Holger I.e. increasing the timeout significantly won't increase the resumption rate significantly.
  442. Alex has left
  443. Ge0rG dwd: there might be false negatives due to client restarts (e.g. OOM conditions)
  444. SamWhited Ge0rG: I'm reasonably sure LTE can, no? Maybe my phone is using both or something to get around that restriction. I should look into this.
  445. dwd Ge0rG, That wouldn't give a resume attempt, no?
  446. Ge0rG SamWhited: only if you have VoLTE
  447. Ge0rG SamWhited: otherwise, your phone will fall back to 3G or 2G, whatever's there.
  448. SamWhited Oh! Right, forgot that was a thing.
  449. dwd Ge0rG, I mean, it would give a resource conflict and killing the original detached session.
  450. Ge0rG dwd: right
  451. jonasw (for now).
  452. Ge0rG until people start using random resource IDs.
  453. dwd has a 198 resumption patch for Openfire, but it's not timing out yet - like, at all.
  454. SamWhited Or rather, I forgot CSFB was a thing. Ge0rG: You're in the U.S. no? Do some providers not support SVLTE or VoLTE?
  455. Ge0rG SamWhited: I'm in Germany. VoLTE support is rather spotty here, and you need a manually selected "compatible" phone.
  456. Holger dwd: That's how Cisco Jabber did it initially.
  457. SamWhited Ge0rG: Good to know; thanks. I wrote about this stuff a bit in the mobile considerations XEP, but obviously don't actually know what I'm talking about
  458. Ge0rG unbounded 0198 sessions guarantee awesome UX
  459. dwd Ge0rG, But quite high memory usage, I suspect.
  460. Holger (And when the client didn't resume for some reason and tried to open a new session with the same resource, the new session was rejected.)
  461. Ge0rG dwd: memory consumption is something usually not seen by your users. An "online" buddy that doesn't react for days, and where all the messages vanish, does.
  462. Ge0rG Holger: yeah, that's awesome!
  463. SamWhited Depends who your users are.
  464. jonasw I wonder whether unbounded sessions are indeed possible with some tricks
  465. SamWhited If you make an appliance that someone else runs, your users notice high memory usage.
  466. Ge0rG jonasw: possible - maybe. practical - nope.
  467. jonasw like: instead of storing messages in some memroy buffer, refer to MAM. apply CSI rules to drop messages.
  468. jonasw presence is trickier, IQs too
  469. dwd jonasw, The problem is what other users see.
  470. jonasw dwd, is it? is presence even a relevant thing anyomre?
  471. dwd jonasw, Although we could do some magic there, even, by triggering unavailable presence but leaving the session open. MUC dies, of course, but MIX would stay live.
  472. dwd jonasw, Yeah, it's relevant. Conversations notwithstanding, there's lots of IM applications where presence is as vital as it always used to be.
  473. jonasw dwd, while I have you here: a friendly reminder that there are still missing votes from you on the last council meeting :)
  474. dwd jonasw, Oh, yeah. Weird bug hit me, so I was in the room but not seeing anything. I need to track that one down.
  475. Ge0rG dwd: maybe you weren't in the room at all then?
  476. Ge0rG 0045 has a nice set of desync issues.
  477. ralphm has left
  478. Guus has left
  479. Ge0rG has left
  480. Guus has left
  481. blabla has joined
  482. lumi has left
  483. stefandxm has joined
  484. Guus has left
  485. Alex has joined
  486. tim@boese-ban.de has joined
  487. Flow has joined
  488. tux has joined
  489. daniel has left
  490. jjrh has left
  491. jjrh has joined
  492. lskdjf has joined
  493. jere has joined
  494. jubalh has left
  495. mimi89999 has left
  496. MattJ has left
  497. waqas has left
  498. mimi89999 has left
  499. MattJ has joined
  500. jere has joined
  501. lumi has joined
  502. MattJ has left
  503. MattJ has joined
  504. waqas has joined
  505. blabla has joined
  506. goffi has left
  507. dwd Ge0rG, Oh, I was. Got the presence, too. Just not the messages. I've half a feeling I've cocked something up somewhere. I've literally no idea what build I've been running.
  508. Guus has left
  509. jubalh has joined
  510. Ge0rG has left
  511. mimi89999 has joined
  512. Guus has left
  513. blabla has joined
  514. Guus has left
  515. jubalh has left
  516. Guus has left
  517. jjrh has left
  518. jjrh has joined
  519. jjrh has left
  520. jjrh has joined
  521. Guus has left
  522. jjrh has left
  523. jjrh has joined
  524. Ge0rG has left
  525. daniel has left
  526. daniel has joined
  527. jjrh has left
  528. jjrh has joined
  529. jere has left
  530. jere has joined
  531. daniel has left
  532. mimi89999 has left
  533. Guus has left
  534. daniel has joined
  535. ralphm has left
  536. mimi89999 has left
  537. Guus has left
  538. SamWhited Brand new web client, first field I tried was an XSS and naturally I can't find a security contact.
  539. jonasw SamWhited, excellent!
  540. SamWhited I give up. I should just go blackhat, it would be way easier.
  541. waqas SamWhited: But it's shiny!
  542. waqas Honestly, I've given up reviewing JS/HTML XMPP clients, and will fail to trust any unless I write one myself
  543. waqas I suppose that's not limited to XMPP clients...
  544. emxp has joined
  545. SamWhited For the sake of my sanity I should do the same.
  546. waqas And the shinier and fancier they are, typically the worse the lack of even slight thought put into security hardening
  547. jonasw waqas, that’s my impression, too
  548. jonasw and I haven’t even tried to pentest anything :)
  549. SamWhited On the plus side, 3 seconds (if that) from login to XSS might be a new record. I am not happy about this, record, but I guess it's nice to have a new personal record?
  550. waqas SamWhited: I admit, I haven't broken one in 3 seconds yet :)
  551. jonasw SamWhited, is it free or open source software? post to oss-security ;-)
  552. jonasw SamWhited, congrats, too
  553. SamWhited waqas: I literally logged in, pasted a stupid simple XSS into the first field I saw, and sure enough it worked.
  554. jonasw how can you even have such things if you do XML
  555. jonasw that sounds as if you could also paste raw XML into the XML stream
  556. waqas jonasw: Interpret it as HTML, obviously
  557. SamWhited jonasw: Probably. In this case that's not what was happening (it was a roster group name being decoded and inserted into the DOM as HTML)
  558. waqas SamWhited: I'd bet it's string concat. blah.innerHTML += "<div>" + text + "<div>";
  559. jonasw SamWhited, sure, but ... but ... I can’t even. so they used innerHTML?!
  560. jonasw the world is bad
  561. Wiktor has joined
  562. daniel has left
  563. mimi89999 has left
  564. Guus has left
  565. Valerian has joined
  566. tim@boese-ban.de has joined
  567. Guus has left
  568. Ge0rG SamWhited: but roster groups are only visible to yourself!1!
  569. moparisthebest has left
  570. moparisthebest has joined
  571. SamWhited has joined
  572. Valerian has left
  573. stefandxm has left
  574. jjrh has left
  575. jjrh has joined
  576. blabla has joined
  577. jubalh has joined
  578. jubalh has left
  579. jjrh has left
  580. jjrh has joined
  581. Guus has left
  582. emxp has joined
  583. Guus has left
  584. valo has joined
  585. valo has joined
  586. daniel has joined
  587. Guus has left
  588. Alex has left
  589. Alex has joined
  590. Guus has left
  591. sonny has joined
  592. sonny has joined
  593. Guus has left
  594. moparisthebest has joined
  595. moparisthebest has joined
  596. Guus has left
  597. jubalh has joined
  598. sonny has joined
  599. tim@boese-ban.de has joined
  600. Guus has left
  601. Ge0rG has left
  602. Guus has left
  603. stefandxm has joined
  604. tux has joined
  605. jubalh has left
  606. SamWhited Ge0rG: Yah, that particular one might not be the worst attack vector since they'd have to have access to your client anyways I guess. Either way, it probably means there are others.
  607. Alex has left
  608. Ge0rG Yeah. That's probably true. Sad, but true.
  609. SouL has left
  610. Guus has left
  611. stefandxm has left
  612. stefandxm has joined
  613. Guus has left
  614. tim@boese-ban.de has joined
  615. valo has joined
  616. lovetox has left
  617. jere has left
  618. jere has joined
  619. waqas has left
  620. waqas has joined
  621. jabberatdemo has joined
  622. Alex has joined
  623. blabla has joined
  624. jabberatdemo has left
  625. goffi has joined
  626. valo has joined
  627. waqas has left
  628. zinid has left
  629. jonasw isn’t there a way to share roster items? ;-)
  630. valo has joined
  631. valo has joined
  632. Tobias has joined
  633. Zash jonasw: roster item exchange?
  634. mimi89999 has left
  635. valo has joined
  636. daniel has left
  637. valo has joined
  638. valo has joined
  639. Guus has left
  640. Guus has left
  641. uc has joined
  642. blabla has joined
  643. daniel has left
  644. jubalh has joined
  645. tux has joined
  646. Valerian has joined
  647. Valerian has left
  648. Valerian has joined
  649. jubalh has left
  650. jubalh has joined
  651. daniel has left
  652. daniel has joined
  653. Valerian has left
  654. Guus has left
  655. Valerian has joined
  656. valo has joined
  657. Guus has left
  658. winfried has left
  659. Guus has left
  660. Ge0rG has left
  661. Ge0rG has left
  662. Ge0rG has joined
  663. waqas has joined
  664. tux has joined
  665. valo has joined
  666. winfried has joined
  667. uc has joined
  668. uc has joined
  669. emxp has left
  670. SamWhited has left
  671. zinid has left
  672. jjrh has left
  673. jjrh has joined
  674. jjrh has left
  675. jjrh has joined
  676. goffi has left
  677. jjrh has left
  678. Guus has left
  679. jjrh has joined
  680. jjrh has left
  681. jjrh has joined
  682. andrey.g has left
  683. valo has joined
  684. blabla has joined
  685. valo has left
  686. jjrh has left
  687. jjrh has joined
  688. andrey.g has joined
  689. Alex has left
  690. Valerian has left
  691. Valerian has joined
  692. Valerian has left
  693. valo has joined
  694. jjrh has left
  695. jjrh has joined
  696. jjrh has left
  697. jjrh has joined
  698. waqas has left
  699. waqas has joined
  700. Valerian has joined
  701. Valerian has left
  702. Alex has joined
  703. Valerian has joined
  704. Valerian has left
  705. daniel has left
  706. fp-tester has joined
  707. jubalh has left
  708. tim@boese-ban.de has joined
  709. blabla has joined
  710. tim@boese-ban.de has joined
  711. valo has left
  712. daniel has left
  713. daniel has joined
  714. SamWhited has joined
  715. valo has joined
  716. Lance has joined
  717. moparisthebest has joined
  718. moparisthebest has joined
  719. Lance has left
  720. Zash has left
  721. la|r|ma has left
  722. lumi has left
  723. daniel has left
  724. daniel has joined