jdev - 2020-03-31


  1. Sam Whited

    Was anyone here around during the JSF days? I'm trying to get a sense of how its mission was different from the XSFs since my understanding is that it was more software focused

  2. Kev

    Sam Whited: Very few people who're still active. Alex, Edwin, Ralph. Me just about. Not sure about Dave, but I suspect not.

  3. Kev

    Peter, obviously.

  4. Kev

    I've probably forgotten someone, but it's that sort of number of people, I think.

  5. Sam Whited

    Kev: thanks, I'll reach out to them directly

  6. Ge0rG

    Sam Whited: are you going to make a history write-up? That'd be very interesting

  7. Sam Whited

    Ge0rG: I wasn't planning on it, but that would be fun if I learn anything interesting

  8. Ge0rG

    As somebody who is very interested in having a JSF 2.0 of sorts today, I'm probably too biased to do such a thing.

  9. Sam Whited

    Ge0rG: I've been vaguely thinking about that which is why I asked. I'd like to have something like Apache but for XMPP projects. Something that can act as a fiscal sponsor to help projects raise money, provide a common set of guidelines and dev practices and infrastructure for stuff under its umbrella, etc. but before I ask people what they'd want out of it I figured I'd see what existed before. I'm also not convinced that there is enough interest in XMPP in general to even make it possible, but you never know. Anyways, just doing very preliminary research.

  10. jonas’

    Sam Whited, you should attend board meetings more often

  11. jonas’

    also maybe become a member again so that you see what’s going on on members@

  12. Sam Whited

    jonas’: I still don't see the point of being a member of the XSF.

  13. jonas’

    so that you get a say on that matter

  14. Ge0rG

    Sam Whited: nobody is _against_ creating such an organization, but the XSF isn't it, and looks like so far nobody had the resources to actually start it.

  15. Sam Whited

    Ge0rG: right, that's why I was thinking about doing it separate from the XSF.

  16. jonas’

    you’re most definitely not the first one with that thought

  17. Ge0rG

    I think that the XSF (and XMPP overall) would vastly benefit from having it, though.

  18. Sam Whited

    yah, probably not

  19. Sam Whited

    jonas’: a say in what matter?

  20. jonas’

    Sam Whited, the direction of the XSF and how funds are used.

  21. Sam Whited

    jonas’: I don't think this should be the XSF, they should be two separate organizations.

  22. jonas’

    MattJ, cc @ you, I think you brought something like that up in one of the more recent board meetings, too ^

  23. jonas’

    Sam Whited, yes, and I think such an organisation should have its roots in the XMPP and XSF communities

  24. Sam Whited

    jonas’: I agree, but like I said, this is just me doing some preliminary research.

  25. pep.

    !

  26. jonas’

    I’m saying there’s already efforts in that direction and I suggest you join them. the more the better.

  27. MattJ

    I bring it up all the time

  28. pep.

    I'm also interested fwiw

  29. MattJ

    to anyone who will listen, or who thinks the XSF is capable of doing all the things people want it to do :)

  30. pep.

    "jonas’> Sam Whited, yes, and I think such an organisation should have its roots in the XMPP and XSF communities", I agree

  31. MattJ

    Well it's unlikely to have its roots in the Matrix community, I agree :)

  32. pep.

    No but it could be perceived as a "FU the XSF, it doesn't work, we're doing our own thing"

  33. MattJ

    I almost thing, so what if it is? (which is unlikely if you're up-front about the goals)

  34. MattJ

    I almost think, so what if it is? (which is unlikely if you're up-front about the goals)

  35. MattJ

    Modern XMPP also has/had that risk

  36. MattJ

    Even the name and domain :)

  37. Ge0rG

    I'm pretty sure it won't, because the XSF is very clear about its razor-sharp focus on Protocol.

  38. MattJ

    (XSF should register legacyxmpp.org on 1st April)

  39. Ge0rG

    MattJ: you could do it right now.

  40. MattJ

    Oh look, that's tomorrow

  41. MattJ

    Must finish my MAM update in time

  42. Sam Whited

    I kind of forgot about modern XMPP, I'm glad to see this exists. I like the goal of providing docs and UI/UX guidelines and what not.

  43. Ge0rG

    MattJ: because you want it to appear on the Humorous track?

  44. MattJ

    With DNS-over-XMPP on the Standards Track and MAM on the Humorous track we'll be good

  45. MattJ

    Hmm, I wonder how many libraries/clients would get tripped up by an iq type='get' in one namespace, and the result having a payload with a different namespace

  46. jonas’

    ... why would they

  47. MattJ

    Because people make assumptions

  48. jonas’

    why do tehy?

  49. jonas’

    why do they?

  50. MattJ

    :)

  51. Sam Whited

    seems like the easiest thing to do would be to match based on ID then just decode whatever is in the result, and I would assume most people would do the easiest thing and it wouldn't cause problems

  52. Ge0rG

    MattJ: you'd be surprised how many implementations ignore the xmlns altogether

  53. flow

    well it does

  54. flow

    if you only match on the id, then you are potentially open to spoofed replies

  55. MattJ

    You match on (jid, id) though

  56. Zash

    and type

  57. Zash

    (jid, id, type=(result|error))

  58. Ge0rG

    Monal won't work on my account because I have a Cisco user on my roster who has a Cisco-namespaced <presence> element inside the jabber:client <presence> element

  59. jonas’

    or have a sufficiently unpredictable ID :)

  60. pep.

    I'm just patching our minidom implementation in Rust to force namespaces everywhere. It's just not possible to retrieve an element without specifying a namespace, unless you loop over everything all the time

  61. flow

    and even (jid, id) is not that trivial as it seems, since there could be multiple values for jid

  62. flow

    including, in some cases, nil

  63. jonas’

    don’t get me started on the ambiguity of an absent @to/@from on stanzas

  64. flow

    so you may simply want to generate "good" IDs and be done…

  65. Sam Whited

    Why would there be multiple values for JID? Do you just mean the server being the domain or the empty attribute?

  66. jonas’

    Sam Whited, that’s not what empty attribute means

  67. Zash

    jonas’, when is it ambigous?

  68. jonas’

    absent attribute refers to your *account*, not to the server domain.

  69. Sam Whited

    oh right, that one. Is that what you menat?

  70. jonas’

    yes

  71. jonas’

    Zash, you can’t simply match on the verbatim string, you have to take into account your currently bound-to JID after resource binding, since some servers will always do one thing (present or absent attribute) even if you always send present/absent

  72. Sam Whited

    yah, that's irritating. I just have my library normalize that on all incoming stanzas

  73. jonas’

    so you have to, in your processing loop, alias empty jid to locally bound bare JID, which is annoying to do

  74. jonas’

    I recall having issues with normalising that actually

  75. Ge0rG

    jonas’: nothing wrong with empty @from/@to... Until you send a message to yourself and the Carbon copy you receive doesn't have one of those set, but it means a different thing ;)

  76. Zash

    Just don't find the text that suggests that empty to/from is different from the bare account jid.

  77. flow

    jonas’, do you remember which issues you had exactly?

  78. jonas’

    (also, of course it requires the stanza broker to know your local JID, because we all hate self-contained things)

  79. jonas’

    I’ll have to check the git log

  80. Sam Whited

    What is a "stanza broker"?

  81. jonas’

    Sam Whited, the thing which takes the stanzas from the XML stream and hands it to handlers

  82. jonas’

    I think it’s called mux in mellium

  83. Sam Whited

    Oh, that's not what does the noramlization in my case (I don't think, if it does it shouldn't be, I can't remember)

  84. Sam Whited

    The session (or connection) knows your JID, and whenever any tokens are read from it it can normalize them

  85. jonas’

    my point is that there’s *no* layer which should need to know about your locally bound JID in the stanza processing pipeline

  86. Ge0rG

    Sam Whited: are you also normalizing <forwarded> stanzas? :D

  87. Sam Whited

    Ge0rG: I don't remember how that works, but those are wrapped in an actual stanza, no? I should probably look, if not I'm probably breaking something there

  88. jonas’

    flow, possibly the normalisation issues were purely in aioxmpp

  89. Ge0rG

    Sam Whited: yes they are, but they are also <message/> stanzas and there are no guarantees whatsoever on them having @from/@to set correctly

  90. Sam Whited

    Ge0rG: I don't do any automatic handling at all of those right now, my library is a bit low-level for that. If a package was ever written to handle them, it would have to do its own normalization to remain self contained.

  91. Zash

    I like to think of it as stanzas inheriting the logical to/from of the parent stream.

  92. Zash

    After resource binding one could think of those as from=full jid to=bare jid

  93. Ge0rG

    Zash: that's the logical thing indeed, except that for some people it's not obvious that you have a stream to your account.

  94. jonas’

    Zash, however, as a client, you set @to to the domain, not to the bare account JID

  95. jonas’

    Zash, however, as a client, you set stream:stream/@to to the domain, not to the bare account JID

  96. Zash

    jonas’: Imagine that it changes during resource binding

  97. jonas’

    that does make no sense to me

  98. Zash

    I kinda wish resource binding was a stream restart thing

  99. jonas’

    changing on SASL, that’d make sense, because that actually binds you to a JID

  100. jonas’

    changing on SASL, that’d make sense, because that actually binds you to a bare JID of some kind

  101. Zash

    Drop the resource binding iq hack, server tells you to/from in the post-sasl restart

  102. jonas’

    that’d be kind of sexy, except that the client speaks first on stream resets

  103. Zash

    Myeah

  104. Zash

    + SASL2 gets rid of the stream restart

  105. Zash

    Tho you could just drop the to/from that the client sends. The server knows who you are after auth and it knows who you authed to.

  106. Zash

    And by drop I mean the server ignores it.

  107. Sam Whited

    I'm always torn about the restarts. On the one hand, they're logical and they're probably good from a security perspective. On the other hand, the entire connection process takes forever on a crappy network and anything we can do to speed that up makes me happy.

  108. Zash

    I did something like that in an experimental CBOR protocol once. No stream restarts, just a message that updates top-level properties like to/from

  109. jonas’

    I don’t even know what stream restarts are supposed to do. the @to is only interesting for client->server really pre-STARTTLS as an SNI-surrogate

  110. jonas’

    aren’t they?

  111. flow

    jonas’, rumar is that they are supposed to reset the xml parser state

  112. flow

    jonas’, rumor is that they are supposed to reset the xml parser state

  113. Zash

    and thus throw away auth related state that might linger

  114. Zash

    which is why it's weird to me that SASL2 drops the restart

  115. jonas’

    flow, ah, that makes sense

  116. jonas’

    I’ll probably forget that again, but it *does* make sense

  117. MattJ

    Pretty sure there have been protocol security problems in the past that didn't apply to XMPP because we do restarts

  118. Zash

    Also older SASL mechanisms can negotiate encryption and stuff, which requires a clear point where it's activated.

  119. flow

    I think it's not that bad to have them

  120. flow

    not sure about the motivation to drop them in sasl2 though

  121. Kev

    You need a stream restart after integrity is negotiated.

  122. Kev

    Both starttls and SASL can negotiate integrity, I think.

  123. jonas’

    Kev, see, that argument I don’t get

  124. Zash

    Never seen it used in SASL tho, only seen the traces of it in DIGEST-MD5

  125. jonas’

    I can see the argument that you want to throw away an XMPP parser/serialiser after having done auth with it, or that you don’t want to keep an XML pipeline hooked up to a stream potentially in the middle of a TLS handshake. But I don’t get that integrity argument

  126. Sam Whited realizes that as we speak I am extremely far behind on my phone because the connection got dropped and on this crappy mobile network it takes ages to be re-established.

  127. Sam Whited

    I'm always confused when I walk up to my laptop and there's a ton of new messages I hadn't seen.

  128. Kev

    jonas’: Because if you assume pre-integrity that things might have been injected into the stream, people could have mangled your to/from and stream id, as well as injecting things into your XML parser.

  129. jonas’

    right, so to/from/stream id are 100% irrelevant, aren’t they?

  130. Kev

    So you're potentially doing authorisation based on injected data.

  131. Kev

    I don't believe they are, no.

  132. jonas’

    you authenticate the server with TLS/SASL, likewise for the client.

  133. jonas’

    I never saw the stream ID used for anything

  134. Zash

    It's used in dialback

  135. jonas’

    that’s more interesting

  136. jonas’

    (maybe my view is too client-centric?)

  137. Kev

    I think it might be :)

  138. jonas’

    but clients are most hurt by stream restarts either way

  139. Zash

    Didn't the non-SASL auth also use the stream id?

  140. Zash

    > SHA1-encrypted Hmmm

  141. Zash

    > SHA1(concat(sid, password))

  142. Zash

    Obsoleted nearly 12 years ago? Why do we still ship code for this?

  143. Zash

    Altho I fondly remember typing https://xmpp.org/extensions/xep-0078.html#example-3 into a telnet console once upon a time

  144. moparisthebest

    I think it should be brought back, just the PLAIN though, and only over TLS of course

  145. moparisthebest

    if it's good enough for HTTP why not XMPP

  146. Zash

    eugh

  147. moparisthebest

    SASL made sense before TLS was mandatory, I don't really think it brings any advantages nowadays though

  148. Zash

    This notion makes me sad

  149. moparisthebest

    unless you see "complexity" or "not being able to upgrade ever" as an advantage

  150. moparisthebest

    are there actual advantages to SASL ?

  151. lovetox

    you mean SASL SCRAM?

  152. Kev

    There's an advantage to having a choice of mechanisms, if that's the question. And once you've got a choice of mechanisms, why not use SASL.

  153. lovetox

    yeah there is more than sasl scram

  154. lovetox

    you need a protocol to tell the server how you are going to auth

  155. lovetox

    may it be via 2FA or external via client cert or even PLAIN

  156. Zash

    "good enough for http", but the web uses a lot of OAuth and stuff that only works if you're a browser

  157. moparisthebest

    client cert can be handled at the TLS layer, 2FA can just be a token appended to your password which makes it the same as PLAIN

  158. moparisthebest

    fair re: oauth ugh

  159. Zash

    Also, I sure hope you're not making the argument that popular == good

  160. moparisthebest

    no, I'm arguing that PLAIN user+pass is "good enough" and KISS and sasl-scram and friends is needless complexity for no gain

  161. lovetox

    i agree about sasl scram over tls is probably not very useful

  162. lovetox

    but not about getting rid of extendable protocol that can define any kind of auth mechanism

  163. Ge0rG

    it's useful because you don't need to store the password on the client

  164. Zash

    or on the server

  165. Zash

    or send it over the wire

  166. Zash

    even if TLS helps there

  167. Sam Whited

    More useful than not having an upgrade path if SHA-1 gets broken?

  168. Zash

    and it's cheap to verify for the server, even if you did a billion rounds of PBKDF2

  169. Zash

    Does this exact discussion with these exact words get repeated every couple of months?

  170. Sam Whited

    Unrelated: but is Apache Vysper still being developed? Randomly wound up on its Git page and there are a bunch of recent commits by names I don't recognize. That is suprising

  171. Zash

    https://github.com/xsf/xmpp.org/pull/592#issuecomment-514935602

  172. Sam Whited

    yah, they're not wrong, it's not easy to find. Good to know.

  173. Zash

    Looks like they did a bunch of stuff last year

  174. SouL

    Hmm, is it a XMPP server?

  175. Zash

    Yes

  176. SouL

    I thought it had something different to it (a reason to make it active again that other XMPP servers do not have or something)

  177. lovetox

    moparisthebest, fyi you cant do the full client cert spec without sasl

  178. lovetox

    a cert could be valid for more than one account

  179. lovetox

    so you need a way to tell the server the account you want to auth with

  180. lovetox

    don't know though if anyone does that

  181. moparisthebest

    Ge0rG, and how is not storing the password on the client useful?

  182. moparisthebest

    your xmpp account password should already only be used for xmpp, so if someone has access to your account, it doesn't really matter if they have the password or not

  183. jonas’

    moparisthebest, that’s a pretty strong "should" there

  184. jonas’

    first: user reality begs to differ. second: single-sign-on systems *do* exist.

  185. moparisthebest

    should be a MUST , we need to stop catering to idiots

  186. moparisthebest

    if someone uses "password" or "mustang1" across all their accounts, it doesn't really matter that the xmpp client doesn't store it locally

  187. jonas’

    if someone uses "7GvdunCpiwkUKty9dj3/u8l5" for their company single-sign-on which also has an XMPP client, it does matter though

  188. jonas’

    if someone uses "7GvdunCpiwkUKty9dj3/u8l5" for their company single-sign-on which also has an XMPP service, it does matter though

  189. Zash

    Uh in those cases you can't use SCRAM anyways since you need to send that password in plain text to some validation service.

  190. jonas’

    shush

  191. Zash

    ... unless it's some OAuth-derivative thing

  192. moparisthebest

    jonas’, does it? cause their browser stores it in plaintext in that case, also probably outlook

  193. jonas’

    moparisthebest, "others are bad, let’s also be bad"

  194. Zash

    burning coal works just fine, let's do more of that!

  195. moparisthebest

    jonas’, yep, if it provides no benefit in any case and brings complexity, let's not bother

  196. moparisthebest

    so far we've established it's useless if it's unique to the xmpp account, or in the case of single sign on, where is it useful then?

  197. jonas’

    I don’t agree with your assessment of the SSO situation

  198. Zash

    I don't agree that there's no benefit.