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