XSF Discussion - 2019-09-10

  1. jonas’

    pep., ask a vegetarian

  2. flow

    ralphm, if I am not mistaken, the current rules of rfc7622 disallow unassigned to in resourceparts, domainparts and probably also localparts

  3. flow

    i'd say the spec is sound and as sensible as possible, it is the implementations that do not follow the rules and so, once in a while, an invalid jid slips through. That's the main motivation for creating the jid/xmpp strings testframework and the valid/invalid jid corpus

  4. jonas’

    flow, except that RFC 7622 does not pin the unicode version

  5. jonas’

    so one entity running on Unicode 10 could consider something as legitimate which an entity on Unicode 9 would not

  6. flow

    jonas’, right, but as I said earlier, I would consider this to be very rare. But I could be wrong. And I don't think there is a better solution, happy to be proven wrong though

  7. flow

    That is, I think the tradeoff of not pinning the unicode version is justified

  8. flow

    At least the troubles we had so far are not caused by not pinning the unicode version, as far as i can tell

  9. Ge0rG

    No, but they have the same symptoms

  10. ralphm

    Isn't my example a sign of why this is a problem? Emoji are all Symbols (So), I believe, and as such valid in parts of JIDs. Differing Unicode versions have different ideas on newer codepoints, so also on validity of JIDs?

  11. Ge0rG

    If we don't want to break the experience for everybody when somebody employs new unicode, we need to accept unassigned as valid from remote entities

  12. ralphm

    The problem with that, though, is unassigneds that become prohibited.

  13. ralphm

    Like U+061C.

  14. ralphm

    Since the foremost expert on this is Peter, I suggest someone write an email about this to standards@. He's busy, but it's more likely he can respond there.

  15. Ge0rG

    I'm not sure he'll be able to solve that problem either ;)

  16. ralphm

    No, but he can at least confirm we have this problem and/or know about strategies.

  17. jonas’

    07:07:12 Ge0rG> If we don't want to break the experience for everybody when somebody employs new unicode, we need to accept unassigned as valid from remote entities

  18. jonas’

    that’s only a partial solution

  19. jonas’

    codepoints may change categories and stuff between unicode versions

  20. jonas’

    and an unassigned codepoint in one version may well be a RTL-codepoint in another version

  21. jonas’

    so by accepting unassigned input, you may accept something which someone else will consider invalid.

  22. jonas’

    unicode is a mess.

  23. jonas’

    ah, ralphm said that alread

  24. jonas’

    ah, ralphm said that already

  25. flow

    well, since the problem is mostly in resourceparts, localparts and domainparts forbid emojis, we should probably establish a pattern that resourceparts are not user-configurable nor user-visible. Shame on you xep45! I wonder what the state in MIX is

  26. flow

    And we should probably add a note to xep45 that the use of certain unicode categories is discouraged

  27. flow

    But I don't want to be the person to discourage emojis in muc usernames…

  28. jonas’

    flow, passwords and such are also affected.

  29. flow

    jonas’, how's that?

  30. Ge0rG

    localparts can be Emoji as well.

  31. jonas’

    flow, passwords are also passed through stringprep/precis

  32. flow

    Ge0rG, localparts are UsernmaeCaseMapped profile of the IdentifierClass, and that class forbids symbols under which emojis fall, no?

  33. flow

    Maybe not all emojis, haven't check them all

  34. ralphm

    In MIX, nicks are an attribute of a participant, not part of their identity. However, it also says you have to follow https://tools.ietf.org/html/rfc7700

  35. ralphm

    Which in turn depends on Precis FreeformClass, and thus has the same issues as resources.

  36. flow

    guess users just want emojis in their nickname

  37. flow

    maybe there is a reserved for future emojis unicode range?

  38. jonas’

    there’s still the problem that you can’t do proper normalisation if you don’t know the codepoints

  39. flow

    well if the reserved range also states the properties of the eventually assigned codepoints?

  40. jonas’

    that won’t work

  41. jonas’

    then they could just be assigned

  42. jonas’

    stuff like how they combine with fitzpatrick modifiers

  43. flow

    No because you don't now yet what they are assigned to

  44. flow

    but if this codepoint is assigned to, then it has the following properties

  45. flow

    btw, there is an excellent post about this topic at https://hsivonen.fi/string-length/

  46. Ge0rG

    flow: I have a user ♥@ツ.op-co.de

  47. flow

    Ge0rG, I am not suprised that you do, if that's the question

  48. ralphm

    flow: no, when we think of as emoji is all over the place in several Unicode blocks.

  49. flow

    ralphm, I suspected that to be the case

  50. Ge0rG

    flow: I'm not aware of it being illegag.

  51. Ge0rG

    flow: I'm not aware of it being illegal.

  52. ralphm


  53. flow

    Anyhow, yes the situation is not perfect, and I am happy if we could improve it. I just don't know how, and I can probably live with the status quo

  54. ralphm

    I like the one on chess symbols: https://www.unicode.org/charts/PDF/Unicode-12.0/U120-1FA00.pdf

  55. ralphm

    Actually https://tools.ietf.org/html/rfc7564#section-12.3 spells out the issue quite clearly: “Strings that conform to the FreeformClass and many profiles thereof can include virtually any Unicode character. This makes the FreeformClass quite expressive, but also problematic from the perspective of possible user confusion. Protocol designers are hereby warned that the FreeformClass contains code points they might not understand, and are encouraged to profile the IdentifierClass wherever feasible; however, if an application protocol requires more code points than are allowed by the IdentifierClass, protocol designers are encouraged to define a profile of the FreeformClass that restricts the allowable code points as tightly as possible.”

  56. ralphm

    (there's a similar remark in the interop section 13.

  57. ralphm


  58. jonas’


  59. flow

    sad that the emoji which could express my feelings right now is only coming in unicode 13: Smiling Face With Tear

  60. flow

    But is the situation really that bad? Implementation could get the latest unicode standard over some sort of data network once in a while. You don't even have to update the involved libraries etc.

  61. jonas’

    flow, is that true?

  62. jonas’

    I think that highly depends on the libraries

  63. jonas’

    I’m not sure how to update python unicodedata for example without updating python

  64. ralphm

    There are libraries that still do just resourceprep instead of Precis, simply because RFC 6122 is directly linked from RFC 6120, even though it is obsoleted by RFC 7622.

  65. ralphm

    One example is Twisted, which I am author of.

  66. ralphm

    One could argue that with resourceprep being more restrictive, just having that is at least a bit clearer as an interop goal.

  67. ralphm

    To be honest, I don't know what the best course of action is in this regard.

  68. jonas’

    stay with unicode 3.2 forever

  69. Ge0rG

    ralphm: be liberal in what you accept and strict in what you emit

  70. Zash

    s/emit/allow users to send/

  71. jonas’

    would a MUC service be strict or liberal, regarding nicknames for example? :)

  72. ralphm

    Ge0rG: my argument here is that this means that something like U+-061C causes problems.

  73. Ge0rG

    Zash: yes, I implied that

  74. ralphm

    It was unassigned before (so not valid), then assigned (but still invalid).

  75. ralphm

    But 🥓 was unassigned before (so not valid), and now assigned (but valid)

  76. Ge0rG

    ralphm: yes, but if the MUC service accepts it, other servers or clients receiving it from the MUC shouldn't freak out

  77. Ge0rG

    i.e. a MUC service can strictly police the nickname, but not the resourcepart of the users' real JID.

  78. jonas’

    ralphm, it’s not invalid, it’s only invalid if used with LTR characters :)

  79. ralphm

    A MUC service is not something magical. It is just another server that connects to other servers over s2s and uses JIDs in addressing of stanzas.

  80. ralphm

    jonas’: it is invalid as it is a control character.

  81. Ge0rG

    ralphm: a regular server should police the resourcepart of local users, but not of remote users.

  82. ralphm

    jonas’: (for FreeformClass)

  83. jonas’

    ralphm, ah, fun

  84. ralphm

    Ge0rG: well, that might be sensible approach, indeed. I'm not sure how well that works with mapping on new code points, and what kind of normalization issues arrise from that, but ok.

  85. ralphm

    In any case it deserves some wider attention. Maybe even to the XMPPWG mailing list.

  86. Ge0rG

    ralphm: framed differently: you shouldn't police any JIDs that you don't have the authority over, except when they are illegal in a breaking way, i.e. contain " or '

  87. ralphm

    does that include localpart?

  88. Ge0rG

    ralphm: what?

  89. ralphm

    Ge0rG: should a server do precis processing on localparts of a remote JID?

  90. ralphm

    Ge0rG: also, for resourcepart, should it a) use incoming JIDs as is (no processing), b) allow unassigneds, but still do Precis, c) something else.

  91. Ge0rG

    ralphm: I'm not sure yet where the point of no return between a and b is, for either localpart or resourcepart

  92. Ge0rG

    If you do a, that probably opens up some very interesting ways to break your clients

  93. jonas’

    I think it boils down to: treat JIDs as opaque if you don’t have authority over them

  94. ralphm

    Yep, things like IV and Ⅳ.

  95. jonas’

    don’t do normalisation on them, or any processing at all, just treat them as opaque sequences of codepoints

  96. ralphm

    (I followed by V, vs. ROMAN NUMBER 4)

  97. Ge0rG

    ralphm: I don't think _that_ would break things

  98. jonas’

    it is the domain authorities responsibility to ensure that stuff is valid and comparable when it is emitted from there

  99. flow

    jonas’, I think so. You sure could bulid an python library that does so

  100. ralphm

    but you can then have different people with arguably the same nick

  101. Ge0rG

    ralphm: this is something the MUC has authority over.

  102. Ge0rG

    ralphm: if you try to enforce that on your user's server, your user will get kicked

  103. ralphm


  104. flow

    > jonas’> ralphm, it’s not invalid, it’s only invalid if used with LTR characters :) I think it is invalid regardless the context with rfc7622

  105. ralphm

    But I definitely don't want to be so lenient for localpart

  106. jonas’

    ralphm, why?

  107. Ge0rG

    ralphm: just tear down s2s and blacklist the remote server as incompliant.

  108. ralphm

    flow: it is invalid in resourceprep because unassigned in 3.2, and invalid in Precis FreeformClass because it is an a prohibited class

  109. Ge0rG

    Conveniently, it also prevents you from contacting the server admin

  110. ralphm

    jonas’: because (bare) JIDs are identity

  111. jonas’

    ralphm, from whose perspective are you currently arguing?

  112. ralphm

    jonas’: I don't want to accept incoming stanzas that fail precis processing on localpart

  113. jonas’

    as a client? as a MUC service? as a server? as anyone?

  114. ralphm

    all, I guess

  115. jonas’

    I see

  116. flow

    > jonas’> don’t do normalisation on them, or any processing at all, just treat them as opaque sequences of codepoints That would probably open up another box of issues

  117. flow

    Since Unicode does us so much good, I'l like to suggest that the XSF adopts a character (for as little as 100$, but maybe we could got for silver) before matrix does it: https://www.unicode.org/consortium/adopted-characters.html

  118. jonas’


  119. jonas’

    flow, send this to board

  120. flow

    on my way

  121. jonas’

    and find a good character thing to sponsor

  122. flow

    U+1F5E9 probably

  123. flow

    but I am open for suggestions

  124. Ge0rG

    I propose U+1F926

  125. Ge0rG

    💡 U+1F4A1 would be too obvious, right?

  126. jonas’


  127. Seve

    Would be nice to havethe logo as a character :D

  128. Seve

    Ge0rG, nope :(

  129. Seve

    flow's suggestion makes more sense ;)

  130. Ge0rG

    Seve: that can only mean you are too young.

  131. jonas’

    Seve, https://www.jabber.org/

  132. Seve

    Nah, but I want to go forward!

  133. jonas’


  134. Seve

    Gaze at our bright future, my friends!

  135. Ge0rG


  136. jonas’

    same here

  137. jonas’

    we’re the future!

  138. jonas’

    (a.k.a. WTF)

  139. Ge0rG

    Looks rather like a SEMI OPAQUE RECTANGLE

  140. ralphm

    flow: Discourse already has Gold on U+1F4AC, so yeah.

  141. ralphm

    To be honest, funny as it is, I don't think we should spend any money on this.

  142. pep.

    What's the conclusion of all this btw?

  143. pep.

    (Not the Unicode sponsoring bits)

  144. jonas’

    pep., everything is terrible

  145. jonas’

    I think the most sensible statement is around 08:38:12 ralphm> In any case it deserves some wider attention. Maybe even to the XMPPWG mailing list.

  146. pep.

    Can somebody(tm) put that to the agenda if they think it's appropriate?

  147. pep.

    So that we don't get stuck here and realize we still have the same issues in 4 years

  148. Zash

    Gotta have this discussion every 4 years

  149. flow

    hmm, I wonder if there is a backstory behind the pile of poo gold sponsor: https://www.unicode.org/consortium/adopted-characters.html

  150. Guus

    I'd like to think that friends of Jason raised the money and did this behind his back.

  151. Ge0rG

    Maybe that name is a kind of pseudonym with a secondary meaning?

  152. Guus

    Random quote found through google: "that's a shitty way to spend 5000 USD"

  153. Ge0rG

    I suppose there are enough rich brogrammers in the valley

  154. ralphm

    For those involved in the Unicode discussion: I wrote to the XMPPWG mailinglist: https://mailarchive.ietf.org/arch/msg/xmpp/a-WhzOTyOq168GujQHgzQ1-DURI

  155. pep.


  156. jonas’

    <3 thanks

  157. jonas’

    where do I subscribe?

  158. ralphm


  159. Zash

    thanks ralphm!

  160. ralphm

    and beware IETF Note Well https://www.ietf.org/about/note-well/

  161. pep.

    "there are implementations and deployments performing the obsoleted stringprep." you mean all (at least public) implementations? :P

  162. Kev

    I raised this sooooo long ago (back when we were discussing using precis for JIDs in the first place).

  163. Kev

    The opinion then, as I remember it, was mostly to not worry about it and assume it won't cause practical interop problems that people might be talking different versions of unicode.

  164. jonas’

    given that we had a fun unicode version interop problem the other day, I think we can safely bury that assumption

  165. Kev

    That's ok, I didn't believe it at the time :)

  166. jonas’

    good :)

  167. ralphm


  168. Ge0rG

    🤖 will disagree on that

  169. jonas’

    that is also PRECISely my problem with it.

  170. jonas’

    someone had to say this, and now it’s out of the way, you can all thank me.

  171. jonas’


  172. ralphm


  173. ralphm

    Kev: I guess that was all before we got gazillions of emoji that are valid in resources.

  174. Ge0rG

    Yeah, somebody hijacked the Unicode consortium to do things actually relevant to the bigger populace

  175. Zash


  176. jonas’

    where was this repository where Daniel explains how the push service for Conversations works and which data is passed to google exactly?

  177. jonas’

    ah, found it

  178. jonas’


  179. Zash

    Cool story bro

  180. pep.

    > 𒈜 What was that

  181. Zash


  182. Guus

    Hmm, I'm missing the message to which Zash responded "cool story bro"

  183. Guus


  184. Zash

    Odd, it's in Dino but not poezio

  185. Guus

    I saw it in Converse, not Conversations.

  186. Guus

    More unicode magic?

  187. pep.

    indeed I don't see it.

  188. Ge0rG

    Something something message dedup?

  189. Guus

    It's only in Converse that I noticed the "I am groot" message.

  190. Guus

    I already wondered why Zash was reacting with that on the message that I saw before it.

  191. Ge0rG

    Guus: me too

  192. Ge0rG

    Now I want to see the xml

  193. Guus

    Unsure if it's in MAM

  194. Zash

    It's not in the MUC MAM

  195. Zash

    Ok, what trickery is this

  196. Ge0rG

    Can anybody post the XML?

  197. jonas’

    and I was wondering why Zash thought my finding of the p2 repository was a cool stoyr

  198. Zash

    Can't post the XML. Can't even find the corresponding line in my logs.

  199. Daniel

    it's not in my dino

  200. moparisthebest

    it showed up in my dino

  201. Ge0rG

    It's a carbon.

  202. Daniel

    a carbon in a muc?

  203. moparisthebest


  204. Ge0rG

    <message to="georg@yax.im/poezio" id="718d40df-3948-4798-a99b-35cc9f03cc4f-641" type="groupchat" from="xsf@muc.xmpp.org/balu_der_baer"> <received xmlns="urn:xmpp:carbons:2"> <forwarded xmlns="urn:xmpp:forward:0"> <message xmlns="jabber:client" to="xsf@muc.xmpp.org" type="groupchat" from="xsf@muc.xmpp.org/i_am_groot"> <body>I am groot.</body> </message> </forwarded> </received> </message>

  205. Daniel

    so any client that shows it potentially has f'uped carbon parsing?

  206. Zash


  207. moparisthebest

    yep missing from my Conversations though, neat

  208. moparisthebest

    I love that mysterious bug finder

  209. Daniel

    Ge0rG, do you just dump all the xml?

  210. Ge0rG

    Daniel: that's from poezio debug log file

  211. Ge0rG

    Everything old is new again. https://www.cvedetails.com/cve/CVE-2017-5589/

  212. Daniel

    sadly i think dino even existed back then

  213. Guus

    It's interesting to ponder on how this can be utilized to have covert discussions en plein public

  214. Ge0rG

    moparisthebest: Guus: can you open bug reports?

  215. moparisthebest

    Daniel, but you said it *didn't* display in your dino? but it did in mine... what version do you have?

  216. Zash

    Guus, MUC PMs seems simpler

  217. Daniel


  218. Daniel

    but maybe it wasn’t stored in muc history

  219. Guus

    Zash: where's the fun in that though

  220. Daniel

    so don’t count on that

  221. moparisthebest

    AH that makes more sense

  222. Guus

    Ge0rG: wilco

  223. moparisthebest

    mine is built from git HEAD too, but trying to figure out exactly when...

  224. Ge0rG

    Also I need to talk to our content manager because the advisory url is 404

  225. Zash

    Mine is whatever Debian package from OBS, and I saw it.

  226. Guus

    jcbrand: ^^

  227. Daniel

    converse showed it as well?

  228. Ge0rG

    Funny how the month changed... https://rt-solutions.de/en/2017/01/cve-2017-5589_xmpp_carbons/

  229. Daniel


  230. Ge0rG

    Converse was affected back then.

  231. Ge0rG

    balu_der_baer: are you a pentester or is your client broken?

  232. Daniel

    that does not look like a broken client

  233. Daniel

    (on the sending end)

  234. Ge0rG

    Daniel: something like delayed delivery gone very much wrong?

  235. Daniel

    how? why?

  236. Ge0rG

    Next up: unrequested MAM impersonation

  237. moparisthebest

    the `i_am_groot` seems like a dead giveaway for deliberate test

  238. moparisthebest

    otherwise that'd be an insanely odd client bug

  239. Daniel

    there is so much long hanging fruit to pick in the xmpp world

  240. Ge0rG

    It's good that somebody does the testing. And this place is actually well suited

  241. Zash

    So what's next, shall we try the MEGALOL-attack?

  242. Guus

    It would have been nice to share findings though.

  243. Guus

    I found out by accident.

  244. moparisthebest

    isn't that what that was? :D

  245. Daniel

    i mean i was wondering why Zash found the p2 story so interesting…

  246. pep.

    Daniel, same :D

  247. Ge0rG


  248. Ge0rG

    "complain loudly if you can read this"

  249. pep.


  250. moparisthebest

    so you can probably impersonate actual people that are in the MUC right?

  251. Ge0rG

    moparisthebest: yes

  252. Daniel

    depending on how fucked it is not just muc

  253. Ge0rG

    moparisthebest: most probably you can impersonate anyone, even outside of the MUC

  254. Ge0rG

    moparisthebest: read the CVE

  255. moparisthebest

    right, sweet

  256. moparisthebest

    yea I just meant the XML groot just sent was MUC only, and implied you could impersonate anyone

  257. moparisthebest

    I'd seen the old general carbons CVE before though

  258. Ge0rG

    It's not really new

  259. Ge0rG

    We should have a test suite for clients.

  260. Daniel

    i wouldn’t be shocked if dino was vulnerable to CVE-2015-8688

  261. Ge0rG


  262. lovetox

    so is this covered by this line in the XEP

  263. Daniel

    someone should try; probably...

  264. lovetox

    Any forwarded copies received by a Carbons-enabled client MUST be from that user's bare JID

  265. lovetox


  266. Daniel

    lovetox, yes

  267. lovetox

    someone cant fake a message from a bare muc jid

  268. Guus

    Uff, this was hard on mobile. https://github.com/conversejs/converse.js/issues/1704

  269. Guus

    Please augment if needed

  270. Daniel

    lovetox, it not bare jid. just the users bare jid is allowed

  271. Daniel

    there shouldn’t be carbons in mucs

  272. lovetox

    yeah but the server is responsible that there are none

  273. lovetox

    at least that says the xep

  274. Daniel


  275. Daniel

    your carbons parsing code needs to be wrapped in a if from == null || from == my_account_jid

  276. lovetox

    ah i get it

  277. lovetox

    yes must be from my account bare jid

  278. lovetox

    not a "user"

  279. Daniel

    which excludes the shit balu send

  280. lovetox


  281. lovetox

    # Carbon must be from our bare jid if not stanza.getFrom() == own_jid.getBare(): raise InvalidFrom('Invalid from: %s' % stanza.getAttr('from'))

  282. lovetox

    was scared i fucked up :) but seems i did this right

  283. pep.

    That's not a new bug, gajim would have probably been tested at that time :)

  284. Ge0rG

    I've added a section to the test cases

  285. pep.


  286. Ge0rG

    Still looking for somebody who can implement them

  287. Ge0rG

    Would probably have to be a component for the MUC parts

  288. Ge0rG

    OTOH, a bot could fake being a MUC, right?

  289. lovetox

    yes pep. but as of course i think i can do everything better i reimplement much code, also carbon parsing

  290. Zash

    This carbons thing could be done by a bot

  291. pep.


  292. pep.

    lovetox, tests!

  293. Ge0rG

    It was a huge strain to my eyes, my fingers and my patience to add those three lines to the wiki from my android phone.

  294. lovetox

    though its much harder wth MAM

  295. lovetox

    i only accept mam messages with query-id s that im actually waiting for

  296. Daniel

    well you do…

  297. Daniel

    and yes can confirm that dino is vuln to https://gultsch.de/gajim_roster_push_and_message_interception.html

  298. Daniel

    why does this shit keep happening

  299. Daniel


  300. Zash


  301. pep.


  302. Daniel

    so question is do i fix it now?

  303. Ge0rG

    Daniel: can you do a roster push through a MUC?

  304. Daniel

    Ge0rG: looking at the code I'm relatively certain you could

  305. Ge0rG


  306. pep.

    let's try?

  307. Daniel

    Haven't tested that one tho

  308. Daniel

    You have to get lucky to get your iq routed I guess. Lol

  309. Ge0rG

    Daniel: only with MSN

  310. moparisthebest

    is there a generic bot/component someplace that can just try all of these things against a JID

  311. pep.

    Which is probably the default in this MUC

  312. pep.

    So not a correct target

  313. moparisthebest

    so it can be used across projects

  314. Ge0rG

    moparisthebest: write one please! https://wiki.xmpp.org/web/Client_Test_Cases#Staying_inside

  315. moparisthebest

    it would probably be hard to write it with most existing libraries, they tend to try to insist on you sending proper things

  316. Daniel

    Glad the Spammer haven't found out how to but themselves right into your roster

  317. Daniel

    The cool thing about that CVE is due to roster version it also won't go away

  318. moparisthebest

    I'd gladly accept spam from such a smart spammer though

  319. Daniel

    So my Dino will be stuck with that test jid I injected

  320. moparisthebest

    might even buy what he's selling

  321. Ge0rG

    moparisthebest: it would get propagated into the spam sending tools and used by dozens spammers within some weeks

  322. Daniel

    So who is going to collect the CVE for mam injection in multiple clients?

  323. Ge0rG

    Daniel: let's wait half a year until there is a significant deployed base

  324. Daniel


  325. Ge0rG

    Other than that, I'll gladly volunteer. I need some more CVEs on my CV

  326. Zash

    CVEs go on your CV?

  327. Ge0rG

    Zash: yes

  328. lovetox

    thats why they start with CV..

  329. Zash


  330. Ge0rG

    Curriculum Vitae Extension.

  331. Ge0rG

    Do we have an up to date entity caps database?

  332. balu_der_baer

    Can you see me?

  333. pep.

    Only the hash? Or all features? If it's just hashes, movim probably has a few up to some point in the past(?) https://nl.movim.eu/?about#caps_widget_tab, otherwise I'm sure you can gather some by running code on prosody

  334. pep.

    balu_der_baer, yes

  335. Zash

    A wild haxxor appears

  336. Ge0rG

    balu_der_baer: no

  337. Ge0rG

    pep.: all the features. Looking for clients with MAM

  338. Daniel

    Mam doesn't show up in Caps

  339. Daniel

    Shouldn't show up. Lpl

  340. Ge0rG

    Then I'll hack something into mod_mam

  341. Daniel

    Shouldn't show up. 😂

  342. Zash

    Nothing says you can't do client-to-client MAM ;)

  343. Ge0rG

    Zash: MAM Push!

  344. Zash

    Idea from long ago: Make a bot that connects to your account and enables carbons, then lets you query it.

  345. pep.

    Zash: that's actually been mentioned a few times..

  346. Ge0rG

    Like posting some Carbons when upgrading from 1:1 to a private MUC!

  347. pep.

    (c2c MAM)

  348. Daniel

    There used to be an ad hoc command that did something like that

  349. Zash

    pep.: nothing new under the sun.

  350. Daniel

    Only for unread I believe

  351. Zash

    Yeah, that too

  352. Daniel

    from reading the code it looks like dino has disabled code that would have checked for the origin of a mam message

  353. Daniel

    and yes it is in fact vulnerable

  354. Daniel

    (just wanted to beat Ge0rG to it)

  355. Guus

    Daniel: a worthy goal.

  356. pep.

    I don't want to swear that slix isn't.

  357. pep.

    (or poezio)

  358. mathieui

    vulnerable to what?

  359. Daniel

    to the MAM thing? no i bet it will be more than just dino

  360. mathieui

    we don’t check the origin, but you have to guess the (fully-random) mam ID

  361. mathieui

    (slix matchers make checking for multiple things a bit tricky, so to fix that we would have to write an "xml mask")

  362. Ge0rG

    Daniel: keep us updated on your advisory

  363. moparisthebest

    so this time balu_der_baer 's "Can you see me?" showed up in Conversations but not dino, fun stuff

  364. Daniel

    was that anything critical?

  365. moparisthebest

    Ge0rG, got raw XML for that one?

  366. pep.

    04:48:04 IN <message xml:lang="en" from="xsf@muc.xmpp.org/Daniel" type="groupchat" to="pep@bouah.net/poezio-C7iY" id="e682bdd7-d98c-4cfd-9c59-fb9e5f9a6d8a"><origin-id xmlns="urn:xmpp:sid:0" id="e682bdd7-d98c-4cfd-9c59-fb9e5f9a6d8a" /><replace xmlns="urn:xmpp:message-correct:0" id="00dc00d3-ae5f-4572-b6c3-4b9e95445e5b" /><body>Shouldn&apos;t show up. 😂 </body><stanza-id xmlns="urn:xmpp:sid:0" by="xsf@muc.xmpp.org" id="2019-09-10-f3fa92f3f7cb7366" /></message>

  367. pep.


  368. U+061C

    it's not my fault this time!

  369. Ge0rG

    Daniel: no, just interested. I'd be glad to co-author as well

  370. pep.

    noo, poezio has only 2k lines in the xml_tab.. gonna grep logs now

  371. moparisthebest

    didn't see that one in either place pep.

  372. pep.

    moparisthebest, neither did I, just looking at xml logs

  373. Daniel

    pep., what's that?

  374. Ge0rG

    moparisthebest: sigh

  375. Ge0rG

    <message to="georg@yax.im/poezio-IS8H" id="718d40df-3948-4798-a99b-35cc9f03cc4f-13F5" type="groupchat" from="xsf@muc.xmpp.org/balu_der_baer"> <body>Can you see me?</body> <received xmlns="urn:xmpp:carbons:2"> <forwarded xmlns="urn:xmpp:forward:0"> <message xmlns="jabber:client" to="xsf@muc.xmpp.org" type="groupchat" from="xsf@muc.xmpp.org/balu_der_baer" /> </forwarded> </received>

  376. Ge0rG

    It was a message that also contained a carbon

  377. Daniel

    but that's ok to show up?

  378. Daniel


  379. moparisthebest

    strange that dino doesn't show that one but Conversations does

  380. Daniel

    i mean both is fine i guess

  381. Ge0rG

    Yes, that's okay

  382. moparisthebest

    so dino does have filtering? it's just wrong

  383. pep.

    What was that XEP that says "don't send everything in the same payload"

  384. Daniel

    no i wouldn’t blame dino for not showing that

  385. Ge0rG

    balu_der_baer: next time add another body to the carbon

  386. Daniel

    moparisthebest, no it just goes down the carbons pipe

  387. Daniel

    and then the carbon doesn’t have anything

  388. Daniel

    Ge0rG, well that will show up in dino

  389. Daniel

    but with the message from within the carbon

  390. U+061C

    out of curiosity, can you put carbon into carbon?

  391. Daniel


  392. Ge0rG

    pep.: https://xmpp.org/extensions/xep-0226.html

  393. pep.

    right that

  394. U+061C

    i mean, what will clients do if they receive carbon within carbon?

  395. Daniel

    just ignore it

  396. moparisthebest

    I'm just awaiting the circular fastening

  397. Daniel

    or parse the outer body if there is one

  398. pep.

    Daniel, that's what you'd hope they do

  399. Daniel

    well at least for dino (even with the bug) and Conversations

  400. Daniel

    and almost def Gajim

  401. Daniel

    until we bring full stanza in the mix

  402. Daniel

    then other funny things might happen

  403. Ge0rG

    U+061C: only if the client has a recursive carbon parser

  404. moparisthebest

    it'd be odd to have code to parse carbons recursively

  405. Daniel


  406. moparisthebest

    any clients written in lisp around? :D

  407. U+061C

    that emacs client?

  408. Ge0rG

    moparisthebest: a message parsing function that extracts the forwarded payload and passes it to the message parsing function? Sounds rather plausible

  409. Daniel

    but hey with Xabber doing their own thing we will soon have new CVE instead of having to recycle the old ones

  410. moparisthebest

    could be

  411. pep.

    Zash, unrelated, what conversejs version is running on xmpp.org btw?

  412. Zash

    Probably just the CDN version.

  413. pep.

    ah it says on the page

  414. pep.


  415. balu_der_baer

    Anyone knows if this is the latest version of Prosody running here?

  416. Zash

    It's not

  417. Zash

    /version xmpp.org

  418. Daniel

    is today the picking low hanging fruit day?

  419. Zash


  420. Daniel

    i also kinda want to rewatch BSG now

  421. Zash

    All this has happened before, and it will happen again, and again, and again

  422. balu_der_baer

  423. Daniel

    so yeah since people have started to exploit the dino roster push i should probably take this offline

  424. Zash

    Anyone got examples of strings that'd be different between IDNA 2003 and 2008?

  425. Zash