XSF Discussion - 2019-12-06

  1. pep.

    Thanks for the meeting/minutes. As I mentioned on the non-public board list, I was at the protests in france :)

  2. edhelas


  3. edhelas

    Movim 0.16.1 released https://nl.movim.eu/?node/pubsub.movim.eu/Movim/cdfc0a4c-3459-4d3b-8c15-08994810d54e

  4. Guus


  5. Guus

    out of personal interest: does that now work with the latest Openfire? iirc, we've fixed the issues that caused interop problems

  6. Zash

    Do we have all the server devs in one of the channelrooMUCs?

  7. edhelas

    Guus didn't tried with Openfire recently

  8. Guus

    Zash this one? 🙂

  9. Guus


  10. Zash

    Guus, Holger, other server devs: We Prosody devs have been thinking about phasing out Dialback, for reasons written down in https://issues.prosody.im/1471 Thoughts?

  11. Zash

    (Metarelated: We need that Hats XEP implemented)

  12. Guus

    I was going to show you how bad of an idea of that was, because over half of my s2s connections use dialback - only to find out that hardly any do.

  13. Guus

    Still, I'd not be a fan, as it'd break backwards compatibility. I'm constantly talking to people that are running server versions that are pretty old.

  14. Guus

    (even those _could_ also do certificate based auth, etc, etc)

  15. Zash

    I was going to ask why the only Dialback connections I have are to jabber.org, dwd and an openfire

  16. Guus

    Why is Openfire's (I'm assuming xmpp.igniterealtime.org) using Dialback? It has valid certs.

  17. Zash

    Why is it not offering me SASL EXTERNAL? I have valid certs?

  18. Guus

    we're running something alpha - buggydibugbug?

  19. Guus

    also, we're currently rewriting all of the s2s code...

  20. Guus

    (not doing dialback would actually save us a lot of time...)

  21. Zash

    In theory having multiplexing would be very nice, but in practice I've never seen that be used, except for that one time dwd tried and found a bug in Prosody.

  22. Zash

    So I've been leaning towards depoying XEP-0288 - Bidi instead and being happy enough with that.

  23. Holger

    > I'd not be a fan, as it'd break backwards compatibility. Same here.

  24. Holger

    I think Tigase still doesn't support SASL EXTERNAL at all, for example. (Not entirely sure though.)

  25. Zash

    Are any of the Tigase folks here or in jdev@?

  26. jonas’

    fun question: those hosts which can only do dialback, what TLS version can they do?

  27. jonas’

    is it likely that they will become unreachable "soon" either way because libssl drops support for that version?

  28. Guus

    I don't think we should remove support for people that for one reason or another don't want or can't set up certificates. Dialback offers better security than no security.

  29. Guus

    I can think of deployments that are deliberately not internet-facing, or have other reasons to not want to depend on Let's Encrypt

  30. Guus

    Also, everyone having valid certificates very much is an effect of one single organisation providing a service, I think. What happens if, for whatever reason, Let's Encrypt stops doing their thing (or stops being trustworthy)?

  31. Guus

    Their certificates are only valid for 3 months - having dialback as a fallback to a service that pretty much hinges on one organisation isn't the worst of ideas, maybe.

  32. Zash

    I'm not a fan of this single point of failure either

  33. Zash

    However it is the current reality

  34. Guus

    would making it easier to disable dialback be a compromise to be considered?

  35. Zash

    I did word it as "phase out", meaning not instant.

  36. Guus

    security-minded setups can then disable it, while others might opt to choose interop over security. It boils down to that question, right?

  37. Zash


  38. Zash

    FWIW it's pretty easy in Prosody already, just comment out that module.

  39. Guus

    Sure, not saying it wasn't 🙂

  40. Zash

    No idea about other servers, but if it's not easy then making it easy seems like a good idea.

  41. Guus

    Having given this 5 minutes of thought, I'd not be a fan of phase out Dialback though.

  42. Maranda

    > Guus, Holger, other server devs: We Prosody devs have been thinking about phasing out Dialback, for reasons written down in https://issues.prosody.im/1471 > Thoughts? > (Metarelated: We need that Hats XEP implemented) Agreed with Guus phasing out DB is a horrible idea, I already more than once expressed my opinion on it

  43. Guus

    I think it's good to discuss these things though. Thanks!

  44. Guus

    Maranda : I never said it was a horrible idea.

  45. !XSF_Martin

    Zash: Didn't you recently talk about disabling dialback in prosody?

  46. Maranda

    Plenty of cisco jabber deployments only do DB for example

  47. Zash

    !XSF_Martin: Yes.

  48. Maranda

    And not sasl external

  49. Maranda

    > Same here. > I think Tigase still doesn't support SASL EXTERNAL at all, for example. (Not entirely sure though.) I'm not sure if it doesnt support it for sure I never seen any deployment I know of using it with my server

  50. Guus

    fwiw: https://issues.igniterealtime.org/browse/OF-1940

  51. Maranda

    Also I never agreed about most of the security concerns on DB nowadays, very few implementations don't do STARTTLS before DB (Metronome does bump servers that do that for example)

  52. Maranda

    And the rogue issuing of certificates by LE just introduces more security concerns, so I'm not sure what you expect to achieve here beside breaking interoperability

  53. MattJ

    Backwards compatibility: meh Let's Encrypt: it's still not the world's only CA by far Closed setups: don't care about s2s, or can run their own CA or enable dialback

  54. Daniel

    Where is memberbot again?

  55. Daniel

    The source code I mean

  56. Daniel

    I finally want to do a lower case and a trim around the response parsing

  57. Daniel

    The fact that it doesn't accept 'Yes ' is super annoying

  58. Maranda

    MattJ: I'm not the one who mentioned LE as solution for a free certificate to feed to SASL external to begin with

  59. Wojtek

    @Maranda - we added it recently in development versions so it will be included in next 8.1.0

  60. pep.

    Daniel, https://github.com/legastero/memberbot

  61. pep.

    See also some fixes here already: https://github.com/linkmauve/memberbot/commits/master

  62. Daniel

    pep.: thank you

  63. Guus

    Daniel I think Alex mentioned forking that into the xsf github account recently. Not sure if he's working on it.

  64. Guus

    and yes, it's annoying. I'd welcome that fix 🙂

  65. Alex

    travelling right now with bad internet access. Feel free to fork it to the XSF repo and I will take it from there ;-)

  66. Daniel

    I think I'll pr link's repo

  67. Alex

    also, don't think I have permissions to fork it to XSF repo, so someone else would need to do the initial fork

  68. pep.

    Maybe I can, now

  69. Alex


  70. pep.

    hmm no I can't

  71. pep.

    Daniel, as you might have seen the "Redis woohoo!" commit is just here to bypass Redis as we didn't want to set it up to test our changes :-°

  72. pep.

    (also I'm curious if it's actually necessary..)

  73. Daniel

    I was just blindly going to add strip().lower() in some places. I wasn't even going to run it

  74. pep.


  75. dwd

    Zash, XEP-0220 is also used by XEP-0288 - are you suggesting that the dialback auth is deprecated, or that the syntax itself is deprecated?

  76. moparisthebest

    Maranda: rogue issuing of certs by LE?

  77. Zash

    dwd: Personally I really don't like the syntax. But I'm pretty sure you can do 288 without talking Dialback.

  78. pep.

    ralphm, Guus, can somebody give me perms on the trello board so I add agendan items please.

  79. pep.

    ralphm, Guus, can somebody give me perms on the trello board so I add agenda items please.

  80. ralphm

    pep., what is your username there?

  81. pep.


  82. ralphm

    pep., oh, interesting, I also found another one, which does have an avatar

  83. pep.

    I just added an avatar

  84. ralphm

    but that one is maximebuquet

  85. pep.

    Yeah, that was the original username they gave me, and apparently it's possible to change it.

  86. pep.

    Not sure how long it sticks around

  87. ralphm

    so it is one account then?

  88. ralphm


  89. pep.

    it is

  90. pep.


  91. pep.

    Thanks I've been added

  92. ralphm

    Well, I think I added both

  93. pep.

    ugh, weird

  94. Guus

    I though I already added you?

  95. Guus

    Are you there three times now? 😁

  96. ralphm

    You added one of his accounts as guest

  97. ralphm

    I promoted that one, and added the other for good measure.

  98. ralphm

    So pep. is double important now

  99. Guus

    Internet is hard

  100. ralphm


  101. Martin

    The *hard* parts are not the problems, the problems come from the *soft* part. No software, no problem. 😁

  102. Guus

    You beat the end boss?

  103. Link Mauve

    RFC5891 says it obsoletes RFC3491, does that mean XMPP applications should stop using the Nameprep stringprep profile for domain names?

  104. ralphm


  105. ralphm

    It turns out that there are some issues surrounding Precis and multiple versions of Unicode.

  106. Zash

    Understatement of the decade 🙂

  107. Link Mauve

    ralphm, this isn’t PRECIS yet.

  108. Zash

    IDNA 2008?

  109. Zash

    That's a separate thing from stringprep

  110. Link Mauve

    I’m looking at whether IDNA2008 can be used for the domainpart of JIDs instead of IDNA2003 + Nameprep.

  111. Zash

    That's not how it works

  112. Link Mauve

    Is it not?

  113. ralphm

    Link Mauve, for reference: https://mailarchive.ietf.org/arch/msg/xmpp/a-WhzOTyOq168GujQHgzQ1-DURI

  114. Link Mauve


  115. Link Mauve

    Ah yes, I have read this email already.

  116. Link Mauve

    This thread.

  117. Zash

    If IDNA 2008 replaces IDNA 2003 AND Nameprep then I've gotten it all backwards.

  118. Link Mauve

    Zash, that’s what I get from the obsoletes header of the RFC, but I may be wrong.

  119. ralphm

    I think you either do it using stringprep as earlier versions of XMPP Addresses, or using Precis using the latests incarnation of it

  120. Zash

    I've just replaced the IDNA part and kept the stringprep part

  121. Zash

    IDNA doesn't come into play until you start doing DNS

  122. Link Mauve

    IDNA2008 did the same mistake (?) as PRECIS of relaxing the Unicode version from Unicode 3.2 to undefined version.

  123. Zash

    Related: The 1023 byte limit on JID parts is super weird given the 256 byte limit on DNS names.

  124. Zash

    I guess you can invent your own non-DNS based federation with looooooong server names.

  125. Link Mauve

    Wouldn’t that break any XMPP software using IDNA*?

  126. Zash

    Define "using IDNA*"

  127. Zash

    Being mostly familiar with Prosody, I can say that it should work fine as long as you don't try to federate.

  128. Zash

    Because IDNA isn't applied until you start doing DNS lookups

  129. Link Mauve

    So I shouldn’t use IDNA2003 nor IDNA2008 in my JID library at all?

  130. Link Mauve

    Since it isn’t involved in DNS in any way?

  131. Zash

    Prosody's JID library doesn't use IDNA at least.

  132. Link Mauve


  133. Zash

    I guess read https://tools.ietf.org/html/rfc7622#section-3.2 and https://tools.ietf.org/html/rfc6122#section-2.2

  134. ralphm

    Or get a hold of Peter

  135. Zash

    One could probably interpret those texts as nameprep being basically the same as IDNA?

  136. ralphm

    Nameprep uses IDNA, but there a bunch more.

  137. flow

    Link Mauve, domainparts can be DNS names of U-labels, not A-labels, hence they are in ACE. IDNA converts U-labels to A-labels and is hence not needed for your JID library.

  138. flow

    Note that RFC7622 is underspecified regarding domainparts, see also https://www.rfc-editor.org/errata/eid5789

  139. Zash

    > ifqdn = 1*1023(domainbyte) > a "domainbyte" is a byte used to represent a UTF-8 encoded Unicode code point that can be contained in a string that conforms to RFC 5890

  140. Zash


  141. flow

    and here lies the problem

  142. Zash

    > ifqdn = 1*(namepoint) > a "namepoint" is a UTF-8 encoded Unicode code point that satisfies the Nameprep profile of stringprep in RFC 6122

  143. flow

    strike that, the ifqnd definition is not the problem, the textual description is

  144. Zash

    Note that those are from two separate RFCs

  145. Zash

    The first I pasted replaces the second.

  146. flow


  147. Zash

    Does the 7622 definition permit 1023 UTF-8 continuation bytes?

  148. flow

    The problem is that RFC7622 only allows code points allowed in NR-LDH labels and U-labels

  149. flow

    which excludes the colon for example, and I am pretty sure most of us have domainparts which include colons

  150. Zash

    Oh glob what's an NR-LDH label?

  151. Zash


  152. flow

    non reserved letters digits hypen label

  153. flow

    Zash, just have a look at https://www.rfc-editor.org/errata/eid5789

  154. Zash

    That's not allowed in domain names

  155. Zash

    And IP literals are in "good luck with that" territory

  156. flow

    NR-LDH are the old style dns label format prior unicode, which just could include letters, digits and the hypen, hence the name

  157. Zash

    Aren't U-labels the new ones?

  158. flow

    yes and no

  159. flow

    on the wire DNS still uses LDH labels

  160. flow

    hence IDNA

  161. Zash remembers how touching on this topic generally ends with a great desire to crawl down under the desk and cry

  162. flow

    It's really not that hard

  163. Zash

    `to_ascii()` yes

  164. flow


  165. Link Mauve

    edhelas, “when you join a chatroom (especially that one)”, which one?

  166. Link Mauve

    Otherwise, congrats for the release!