XSF Discussion - 2020-05-10


  1. j.r has left

  2. j.r has joined

  3. j.r has left

  4. j.r has joined

  5. stpeter has left

  6. mukt2 has left

  7. j.r has left

  8. j.r has joined

  9. debacle has left

  10. debacle has joined

  11. neshtaxmpp has left

  12. neshtaxmpp has joined

  13. debacle has left

  14. debacle has joined

  15. xsf has left

  16. neshtaxmpp has left

  17. xsf has joined

  18. moparisthebest has left

  19. Neustradamus has left

  20. Neustradamus has joined

  21. lorddavidiii has left

  22. debacle has left

  23. karoshi has joined

  24. moparisthebest has joined

  25. karoshi has left

  26. mukt2 has joined

  27. karoshi has joined

  28. sonny has left

  29. sonny has joined

  30. sonny has left

  31. sonny has joined

  32. karoshi has left

  33. karoshi has joined

  34. mukt2 has left

  35. pdurbin has joined

  36. govanify has left

  37. govanify has joined

  38. govanify has left

  39. govanify has joined

  40. sonny has left

  41. sonny has joined

  42. pdurbin has left

  43. govanify has left

  44. govanify has joined

  45. mukt2 has joined

  46. sonny has left

  47. sonny has joined

  48. stpeter has joined

  49. govanify has left

  50. govanify has joined

  51. mukt2 has left

  52. alexis has joined

  53. stpeter has left

  54. govanify has left

  55. govanify has joined

  56. arc has left

  57. arc has joined

  58. calvin has joined

  59. arc has left

  60. arc has joined

  61. govanify has left

  62. govanify has joined

  63. govanify has left

  64. govanify has joined

  65. alexis has left

  66. lorddavidiii has joined

  67. sonny has left

  68. sonny has joined

  69. mukt2 has joined

  70. govanify has left

  71. govanify has joined

  72. govanify has left

  73. govanify has joined

  74. pdurbin has joined

  75. paul has left

  76. govanify has left

  77. govanify has joined

  78. mukt2 has left

  79. calvin has left

  80. moparisthebest has left

  81. Yagiza has joined

  82. sonny has left

  83. sonny has joined

  84. arc has left

  85. arc has joined

  86. karoshi has left

  87. adiaholic_ has left

  88. adiaholic_ has joined

  89. arc has left

  90. arc has joined

  91. mukt2 has joined

  92. adiaholic_ has left

  93. adiaholic_ has joined

  94. sonny has left

  95. sonny has joined

  96. mukt2 has left

  97. sonny has left

  98. sonny has joined

  99. stpeter has joined

  100. DebXWoody has joined

  101. neshtaxmpp has joined

  102. govanify has left

  103. govanify has joined

  104. arc has left

  105. arc has joined

  106. adiaholic_ has left

  107. adiaholic_ has joined

  108. stpeter has left

  109. govanify has left

  110. govanify has joined

  111. govanify has left

  112. govanify has joined

  113. sonny has left

  114. sonny has joined

  115. bear has left

  116. arc has left

  117. arc has joined

  118. govanify has left

  119. govanify has joined

  120. sonny has left

  121. sonny has joined

  122. adiaholic_ has left

  123. adiaholic_ has joined

  124. govanify has left

  125. govanify has joined

  126. sonny has left

  127. sonny has joined

  128. govanify has left

  129. govanify has joined

  130. bear has joined

  131. govanify has left

  132. govanify has joined

  133. paul has joined

  134. govanify has left

  135. govanify has joined

  136. mukt2 has joined

  137. govanify has left

  138. govanify has joined

  139. mukt2 has left

  140. Jeybe has joined

  141. neshtaxmpp has left

  142. Half-Shot has left

  143. Half-Shot has joined

  144. stpeter has joined

  145. Jeybe has left

  146. Jeybe has joined

  147. arc has left

  148. arc has joined

  149. stpeter has left

  150. lovetox has joined

  151. andy has joined

  152. Yagiza has left

  153. goffi has joined

  154. mukt2 has joined

  155. Jeybe has left

  156. lskdjf has joined

  157. Jeybe has joined

  158. Tobias has joined

  159. Nekit has joined

  160. krauq has left

  161. Jeybe has left

  162. Jeybe has joined

  163. krauq has joined

  164. govanify has left

  165. govanify has joined

  166. krauq has left

  167. xecks has joined

  168. xecks has left

  169. xecks has joined

  170. rion has left

  171. karoshi has joined

  172. karoshi has left

  173. eevvoor has joined

  174. xsf has left

  175. stpeter has joined

  176. flow

    larma, I think we are probably saying the same: you may can deduce RFC compliance from the schema, you can not deduce non RFC compliance from violating the schema

  177. flow

    larma, I think we are probably saying the same: you may can provide a indication of RFC compliance from the schema, you can not deduce non RFC compliance from violating the schema

  178. debacle has joined

  179. flow

    larma, I think we are probably saying the same: you may can provide a "hint" towards RFC compliance from the schema, you can not deduce non RFC compliance from violating the schema

  180. Zash

    Deriving intent from the schema?

  181. krauq has joined

  182. krauq has left

  183. krauq has joined

  184. Shell has joined

  185. flow

    I think I do that all the time, e.g. when it is unclear if the value provided by the xml-layer should be an integer or a string

  186. flow

    or if a certain element or attribute is required

  187. sonny has left

  188. sonny has joined

  189. sonny has left

  190. sonny has joined

  191. waqas has left

  192. Zash

    That seems fine to me. Isn't it primarily when the text and the schema disagree that the text takes priority? Like with examples.

  193. stpeter has left

  194. Jeybe has left

  195. Jeybe has joined

  196. sonny has left

  197. sonny has joined

  198. Mikaela has joined

  199. lorddavidiii has left

  200. lorddavidiii has joined

  201. Shell has left

  202. Shell has joined

  203. mukt2 has left

  204. Shell has left

  205. Shell has joined

  206. debacle has left

  207. debacle has joined

  208. debacle has left

  209. debacle has joined

  210. LNJ has joined

  211. LNJ has left

  212. arc has left

  213. LNJ has joined

  214. arc has joined

  215. lovetox has left

  216. werdan has joined

  217. lovetox has joined

  218. werdan has left

  219. lovetox has left

  220. debacle has left

  221. debacle has joined

  222. Shell has left

  223. Shell has joined

  224. APach has left

  225. APach has joined

  226. Shell has left

  227. Shell has joined

  228. emus has joined

  229. mukt2 has joined

  230. vanitasvitae has left

  231. vanitasvitae has joined

  232. lovetox has joined

  233. Yagiza has joined

  234. mimi89999 has left

  235. mimi89999 has joined

  236. Steve Kille has left

  237. lovetox has left

  238. Shell has left

  239. Shell has joined

  240. Steve Kille has joined

  241. mukt2 has left

  242. mukt2 has joined

  243. flow

    That certainly is the case. Although, I'm not sure about meaning of the "primarily" part, sometimes the text underspecifies the wire protocol, and the schema helps

  244. debacle has left

  245. debacle has joined

  246. debacle has left

  247. jonas’ has left

  248. sonny has left

  249. jonas’ has joined

  250. sonny has joined

  251. jonas’ has left

  252. jonas’ has joined

  253. debacle has joined

  254. j.r has left

  255. j.r has joined

  256. adiaholic_ has left

  257. adiaholic_ has joined

  258. debacle has left

  259. debacle has joined

  260. jonas’ has left

  261. jonas’ has joined

  262. jonas’ has left

  263. jonas’ has joined

  264. stpeter has joined

  265. jonas’ has left

  266. jonas’ has joined

  267. karoshi has joined

  268. Daniel has left

  269. !XSF_Martin has left

  270. Daniel has joined

  271. !XSF_Martin has joined

  272. !XSF_Martin has left

  273. !XSF_Martin has joined

  274. stpeter has left

  275. jonas’ has left

  276. jonas’ has joined

  277. mukt2 has left

  278. mukt2 has joined

  279. Maranda has left

  280. Maranda has joined

  281. Maranda has left

  282. Maranda has joined

  283. karoshi has left

  284. karoshi has joined

  285. Zash has left

  286. sonny has left

  287. sonny has joined

  288. LNJ has left

  289. Zash has joined

  290. adiaholic_ has left

  291. adiaholic_ has joined

  292. chyna has joined

  293. Shell has left

  294. mukt2 has left

  295. sonny has left

  296. sonny has joined

  297. Jeybe has left

  298. Shell has joined

  299. rion has joined

  300. karoshi has left

  301. karoshi has joined

  302. mukt2 has joined

  303. Jeybe has joined

  304. debacle has left

  305. sonny has left

  306. mukt2 has left

  307. sonny has joined

  308. mukt2 has joined

  309. stpeter has joined

  310. sonny has left

  311. sonny has joined

  312. Dele Olajide has joined

  313. pdurbin has left

  314. Dele Olajide has left

  315. Dele Olajide has joined

  316. krauq has left

  317. krauq has joined

  318. stpeter has left

  319. mukt2 has left

  320. mukt2 has joined

  321. sonny has left

  322. sonny has joined

  323. jonas’ has left

  324. jonas’ has joined

  325. sonny has left

  326. sonny has joined

  327. Max has left

  328. DebXWoody has left

  329. Max has joined

  330. Yagiza has left

  331. jonas’ has left

  332. jonas’ has joined

  333. mukt2 has left

  334. j.r has left

  335. j.r has joined

  336. karoshi has left

  337. mukt2 has joined

  338. adiaholic_ has left

  339. karoshi has joined

  340. adiaholic_ has joined

  341. Jeybe has left

  342. Max has left

  343. jonas’ has left

  344. jonas’ has joined

  345. Max has joined

  346. mukt2 has left

  347. lovetox has joined

  348. Yagiza has joined

  349. stpeter has joined

  350. pdurbin has joined

  351. Max has left

  352. pdurbin has left

  353. stpeter has left

  354. DebXWoody has joined

  355. nyco has left

  356. nyco has joined

  357. DebXWoody has left

  358. Shell has left

  359. robertooo has left

  360. robertooo has joined

  361. mukt2 has joined

  362. karoshi has left

  363. karoshi has joined

  364. Nekit has left

  365. Dele Olajide has left

  366. mukt2 has left

  367. mukt2 has joined

  368. lovetox has left

  369. calvin has joined

  370. eevvoor has left

  371. Zash has left

  372. Zash has joined

  373. calvin has left

  374. calvin has joined

  375. chyna has left

  376. david has left

  377. david has joined

  378. adiaholic_ has left

  379. adiaholic_ has joined

  380. j.r has left

  381. j.r has joined

  382. Jeybe has joined

  383. Jeybe has left

  384. Jeybe has joined

  385. pdurbin has joined

  386. stpeter has joined

  387. calvin has left

  388. pdurbin has left

  389. calvin has joined

  390. stpeter has left

  391. Kev has joined

  392. Neustradamus has left

  393. Neustradamus_ has left

  394. LNJ has joined

  395. Neustradamus has joined

  396. Neustradamus_ has joined

  397. debacle has joined

  398. calvin has left

  399. DebXWoody has joined

  400. Jeybe has left

  401. Jeybe has joined

  402. calvin has joined

  403. mukt2 has left

  404. arc has left

  405. arc has joined

  406. sonny has left

  407. sonny has joined

  408. emus has left

  409. emus has joined

  410. adiaholic_ has left

  411. adiaholic_ has joined

  412. werdan has joined

  413. chyna has joined

  414. sonny has left

  415. sonny has joined

  416. sonny has left

  417. sonny has joined

  418. mukt2 has joined

  419. lovetox has joined

  420. karoshi has left

  421. karoshi has joined

  422. adiaholic_ has left

  423. calvin has left

  424. j.r has left

  425. j.r has joined

  426. Jeybe has left

  427. Jeybe has joined

  428. adiaholic_ has joined

  429. pdurbin has joined

  430. stpeter has joined

  431. pdurbin has left

  432. stpeter has left

  433. govanify has left

  434. govanify has joined

  435. karoshi has left

  436. karoshi has joined

  437. adiaholic_ has left

  438. adiaholic_ has joined

  439. Nekit has joined

  440. xsf has joined

  441. lorddavidiii has left

  442. lovetox has left

  443. larma

    flow, not sure if I missed something in the channel binding discussion, but what would be wrong with `<mechanism xmlns='urn:xmpp:channel-binding' type='tls-exporter'>SCRAM-SHA-1-PLUS</mechanism>`. This looks a lot cleaner to me...

  444. Daniel

    i didn’t read the whole thread (just the initial xep proposal) but i like that solution

  445. flow

    larma, as special case for a hypothetical sasl mechanism channel binding type? I think I would rather go with a child element of <channel-binding/> to signal that. But again, I don't see why it should be signalled at all

  446. andrey.g has left

  447. flow

    larma, as special case for a hypothetical sasl mechanism exclusive channel binding type? I think I would rather go with a child element of <channel-binding/> to signal that. But again, I don't see why it should be signalled at all

  448. moparisthebest has joined

  449. Shell has joined

  450. larma

    flow, I thought it wasn't properly defined which type to use and that is an issue, isn't it?

  451. flow

    larma, no, the issue is that you do not know which cb types the remote endpoint supports

  452. flow

    -PLUS just signalls that cb is used, but not which cb type

  453. flow

    all currently registered cb types with IANA are currently available for all -PLUS sasl mechanisms

  454. flow

    and tls-server-end-point should be (basically) always available

  455. flow

    but tls-unique may not

  456. flow

    so if a client tries to do -PLUS with tls-unique, then things get a bit ugly

  457. Zash

    My understanding is that PLUS being advertised means channel binding is supported, and then negotiated in a header in a header in SCRAM.

  458. flow

    Zash, yes, but the server has no way to signal the supported cb types to the client

  459. flow

    IIRC there is no negotiation in gss api

  460. Zash

    Yes

  461. flow

    the client just says, I do cb type x and hopes the server support x

  462. flow

    the client just says, I do cb type x and hopes the server supports x

  463. Zash

    Right, which is weird and why it's good to try to solve that.

  464. flow

    correct, and I think my proposal solves that in a neat and clean way

  465. karoshi has left

  466. karoshi has joined

  467. calvin has joined

  468. lovetox has joined

  469. arc has left

  470. arc has joined

  471. calvin has left

  472. larma

    flow, I like yours more than the original proposal. But looking at the specs again, I was just wondering if instead of signaling it we could just define that a) in TLS < 1.3, only tls-unique may be used, b) in TLS 1.3 only tls-exporter may be used (although we'd probably want to wait for it to be IANA registered before defining that)

  473. sonny has left

  474. sonny has joined

  475. sonny has left

  476. sonny has joined

  477. calvin has joined

  478. flow

    why only tls-unique for tls 1.3? and why close the door for tls-server-end-point? all other cb's are probably blocked or at least stalled until the TLS APIs provide a way to extract the cb data, tls-server-end-point should usually be easily implementable and is probably better than performing no channel binding at all

  479. flow

    larma, ^

  480. flow

    also why no cb type agility? if something the past has shown is that cb types are not easy to get right

  481. Zash

    flow, funny tho that in Prosody, tls-unique is already implemented and my attempts at tls-server-end-point is stalled by not having access to the needed info

  482. larma

    flow: according to scram rfc, tls-unique is the default and must be implemented by servers. So as client, it's safe to use it even without further negotiation.

  483. stpeter has joined

  484. flow

    larma, unfortunately, I think, the reality is different

  485. flow

    larma, that is, chances are higher that you find tls-server-end-point than tls-unique

  486. flow

    Zash, isn't tls-server-end-point just the hash of the certificate?

  487. Zash

    flow, go read the rules for what hash algorithm to use, then try to implementing it given only an opaque binary blob

  488. goffi has left

  489. flow

    wheras tls-unique requires you to get the tls finial message, which is often not exposed (as raw bytes) by TLS APIs

  490. waqas has joined

  491. Zash

    I would be happy if TLS libs could have an API to tell what channel bindings are supported and then return the data for those by channel binding name.

  492. larma

    flow: so you are saying servers in practice are not rfc compliant?

  493. flow

    Zash, IIRC the rules just say "use whatever the cert uses as hash algorithm, unless if it is MD5 or SHA-1, in this case use SHA-256"

  494. Zash

    It's exposed by OpenSSL and LuaSec.

  495. flow

    larma, yep, there is always a discrepancy between whoe specifications writers wish the world would be, and how the world actually is

  496. Zash

    The hash algorithm of a certificate is not exposed however.

  497. flow

    Zash, it being the tls finished message?

  498. Zash

    Yes.

  499. Zash

    Interestingly it also does this for TLS 1.3

  500. Zash

    I have some WIP somewhere that just always uses SHA-256, and since that's what all certificates use it'll probably work until the day someone gets a SHA-512 or SHA-3 certificate.

  501. flow

    Zash, don't you have another way to get a hold of the whole certificate, as far as I understand it, the hash algorithm used is noted there

  502. calvin has left

  503. calvin has joined

  504. Zash

    are you telling me to implement another ASN.1 parser?

  505. flow

    anyway, last time I checked the situation in java land was the opposite: you can not get the tls finish message, but doing tls-server-endpoint is easy

  506. Zash

    I'd very much rather not.

  507. flow

    (with the standard Java SE API)

  508. Daniel

    Agility if it can be achieved with reasonable Syntax (and I like flows proposal in that regard) should be preferred to convention

  509. Daniel

    Yes in Java Standard api that's correct

  510. Daniel

    That's why I never implemented it

  511. Zash

    Sure, that'd be good. (why data in attributes tho?)

  512. flow

    Zash, data in attributes?

  513. Daniel

    Conscrypt does support unique. But then came tls1.3

  514. Daniel

    Zash: flows. Not Marvin's

  515. Zash

    flow, `<cb name='tls-unique'/>` instead of `<cb>tls-unique</cb>`, but this is a nit

  516. Zash

    Daniel, ?

  517. flow

    Zash, right, I actually think the latter should be considered an anti-pattern when designing xmpp wire protocol

  518. flow

    because <cb name=""/> alows us to extend <cb/> with child elements if that ever becomes necessary

  519. Zash

    No, that's the opposite of what it is

  520. Daniel

    Ah. Sorry. I was confused

  521. Daniel

    Yeah I don't care

  522. Zash

    In general data should go in text nodes and metadata in attributes.

  523. flow

    so this was a deliberate design choice, and I think pattern to list something as cdata in elements should be avoided

  524. flow

    Zash, because?

  525. Zash

    Because.

  526. Zash

    General XMPP or XML design advice that I don't remember the exact location of

  527. mukt2 has left

  528. flow

    well I think keeping the door open to child element based extensibility is a better argument than some handwaving rule ;)

  529. stpeter has left

  530. mukt2 has joined

  531. flow

    that design advice *may* is sensible if you allow mixed content, but we do not allow mixed content

  532. Zash

    Also because `stanza:get_child_text()` in Prosody is the best API ever :)

  533. DebXWoody has left

  534. flow

    Zash, I am sure your get_attribute_value() API is of similar quality ;)

  535. Zash

    There's no such thing.

  536. flow

    because it's a map (or table?)

  537. flow

    because it's a map (or table?)?

  538. Zash

    yes

  539. larma

    If it was <mechanism name='SCRAM-SHA-1-PLUS' /> we could do <mechanism name='SCRAM-SHA-1-PLUS'><cb type='tls-unique' /></mechanism> now, so I'm totally on flows side to prefer attributes for extensibility

  540. Zash

    Then why isn't it like that in SASL2?

  541. adiaholic_ has left

  542. adiaholic_ has joined

  543. larma

    If it's not clear that extensibility is not needed of course.

  544. flow

    larma, yep, that is the point. but i really like to stress that there is no reason to list cb types per sasl mechanism, and that this is also verly likely to be true in the future

  545. flow

    Zash, good point, guess someone would need to convince dave to change it

  546. Zash

    <mechanisms> <mechanism> <name>PLAIN</name> <channel-bindings> <channel-binding> <name>tls-unique</name> </////>

  547. werdan has left

  548. flow

    using a <name/> element has the drawback that there could be multiple, whereas there can only be one attribute with the name 'name'

  549. Zash

    You can't extend attributes either tho.

  550. flow

    right, but I can extend the element they are declared at

  551. larma

    flow: well I agree that cb is unlikely to be specific to a single mechanism, on the other hand, one typically also doesn't support multiple mechanisms with channel binding either. And the supported cb are clearly related to that mechanism and not related to all of them.

  552. flow

    larma, wait, one typically also does not support multiple mechanisms with channel binding either? I'd assume quite the contrary to be the case, given that SCRAM-SHA-256 starts to gain popularity

  553. flow

    the server presents you with a list of sasl mechanism currently. my propsal adds another list with supported cb types alongside the sasl mechanism list. the client is free to choose the combination he deems to be best

  554. larma

    Well, a server that supports SCRAM-SHA-256 is not better in any regard if it also supports SCRAM-SHA-1

  555. moparisthebest has left

  556. flow

    I am not sure if this is true. you are probably hinting towards that the server also has to store the auth data using the weaker hash

  557. larma

    Yes.

  558. Zash

    If you see a Prosody offering both then it is most likely storing the password in plain text.

  559. Zash

    Or someone implemented a way to store two credentials without me knowing

  560. flow

    I think there are lot of cases where the password is stored in plain text server side, but does that mean that those servers should continue to offer only scram sha-1 for eternity?

  561. Yagiza has left

  562. flow

    larma, I see, of course, your point. but this is not an argument to closely couple the sasl mechanisms and the cb types in the sasl mechanism stream feature

  563. Zash

    currently it's a matter of whether the sasl mechanism supports gss-api, or somesuch.

  564. flow

    Zash, please clarify 'it'? I'd assume that every -PLUS mechanism supports gss-api (or maybe I confuse gss-api with something different)?

  565. larma

    flow: it's scram that supports gssapi, no?

  566. Zash

    SCRAM supports GSS-API. GSS-API supports channel bindings.

  567. Zash

    Or something like that.

  568. flow

    IIRC I did gss-api stuff when implementing the -PLUS variants of scram

  569. Zash

    Point is that there's some indirection.

  570. flow

    yes, the whole existence of -PLUS is a design weakness

  571. larma

    And -PLUS is just a dirty hack to announce that the server supports cb

  572. flow

    not sure if it was because channel binding came after SASL was initialy invented

  573. flow

    if the RFC SASL profile would also allow for a list of supported cb types, alongside the list of supported sasl mechanisms, then gss-api would be sufficient to negotiate cb

  574. Zash

    Redefine PLUS to mean `tls-unique`? Invent a new SCRAM-SHA-256-PLSCRT for tls-server-endpoint? :D

  575. Zash

    Wait that's basically what Sam proposed

  576. Zash

    Almost.

  577. lovetox has left

  578. arc has left

  579. arc has joined

  580. larma

    Given that `tls-unique` is a MUST on servers that do -PLUS and SHOULD on clients, it's not even incompatible to define -PLUS = `tls-unique` ;)

  581. Zash

    Mmmmmm `SCRAM-SHA-256-DOUBLEPLUS`

  582. Zash

    Except it's too long

  583. larma

    I like -PLUSPLUS more :D

  584. Zash

    SCRAM-SHA-2-PLUSPLUS is 20 chars

  585. bear has left

  586. Tobias has left

  587. larma

    Or maybe we just should stop with -PLUS, because if we announce cb types anyway, we don't need -PLUS anymore

  588. Zash

    True

  589. LNJ has left

  590. LNJ has joined

  591. karoshi has left

  592. Jeybe has left

  593. Jeybe has joined

  594. Jeybe has left

  595. Jeybe has joined

  596. karoshi has joined

  597. LNJ has left

  598. sonny has left

  599. sonny has joined

  600. Nekit has left

  601. Nekit has joined

  602. fredpunk has joined

  603. fredpunk has left

  604. bear has joined

  605. govanify has left

  606. govanify has joined

  607. stpeter has joined

  608. govanify has left

  609. govanify has joined

  610. calvin has left

  611. calvin has joined

  612. pdurbin has joined

  613. Mikaela has left

  614. robertooo has left

  615. robertooo has joined

  616. sonny has left

  617. sonny has joined

  618. sonny has left

  619. govanify has left

  620. govanify has joined

  621. govanify has left

  622. govanify has joined

  623. xecks has left

  624. xecks has joined

  625. debacle has left

  626. debacle has joined

  627. pdurbin has left

  628. xecks has left

  629. xecks has joined

  630. Daniel has left

  631. sonny has joined

  632. debacle has left

  633. Daniel has joined

  634. karoshi has left

  635. lskdjf has left

  636. calvin has left

  637. karoshi has joined

  638. andy has left

  639. Jeybe has left

  640. Seve has left

  641. arc has left

  642. arc has joined

  643. stpeter has left

  644. krauq has left

  645. krauq has joined

  646. xecks has left

  647. calvin has joined

  648. govanify has left

  649. govanify has joined

  650. sonny has left

  651. sonny has joined

  652. arc has left

  653. arc has joined

  654. Shell has left

  655. chyna has left

  656. pdurbin has joined

  657. karoshi has left

  658. karoshi has joined