XSF Discussion - 2018-08-16

  1. Link Mauve

    Ugh, https://infosec-handbook.eu/blog/xmpp-aitm/

  2. Link Mauve

    They’re mostly right, but I dislike their conclusions.

  3. Ge0rG

    Link Mauve: they also had a rant about how bad XMPP is, recently

  4. Ge0rG


  5. Link Mauve

    Ge0rG, this is another.

  6. dwd

    Link Mauve, "Furthermore, he is convinced that most XMPP server and client software is more a leisure project than secure software." - there's at least three companies working with XMPP in high security environments.

  7. Zash

    Uh, worth reading?

  8. daniel

    To be fair the companies you are talking about aren't the companies and products most end users are using

  9. daniel

    But still at least ejabberd and Conversations are products created by for profit entities

  10. daniel

    > Uh, worth reading? Not really

  11. Zash

    > Links > * How to use Signal more privacy-friendly

  12. Zash


  13. edhelas

    > solution, don't use Signal

  14. jonasw

    > solution, stop doing those computer things and become potato farmer

  15. Ge0rG

    jonasw: potato seeds are generticaly manipulated by Monsanto to not reproduce after the first generation, forcing you to buy new seeds from them

  16. Zash

    Plant potato, get more potato

  17. dwd

    Still don't quite understand why "Don't trust an XMPP server operator, they can monitor your traffic really easily!" can be combined with "Use this centralized service, because the admins and hosting providers are totally trustworthy."

  18. Zash

    dwd: You dare question our lord and saviour, Moxie?! /s

  19. Zash

    Something something praise be crypto-jesus

  20. edhelas

    never question Father Moxie

  21. dwd

    Well, right. That's why pretty much every *other* cryptographer is working on MLS.

  22. edhelas

    and the Signal centralized backend deployed on AWS instances :p

  23. edhelas

    but it's "Snowden Approved ©"

  24. Zash

    and Schneier approved(?)

  25. dwd

    Yeah, because a guy who dumped a load of stuff he hadn't even read onto a bunch of journalists is a good source of judgement.

  26. Zash

    The holy trinity giveth unto us Signal

  27. edhelas

    by the way, the centralized-xmpp-based-omemo Cryptocat client is not maintained anymore ? https://github.com/cryptocat/cryptocat

  28. jonasw

    dwd, (being devil’s advocate): "because we can deploy useful e2ee"

  29. dwd

    jonasw, Sure, but the remaining problems still exist - anyone reading the cleartext Signal traffic can read out the routing info.

  30. daniel

    edhelas: does that surprise you given the three preceding iterations of that project?

  31. Zash

    dwd: wait, what?

  32. Ge0rG

    Zash: Facebook paid TWO MILLION DOLLARS to get moxie's Stamp Of Approval. It must be good!

  33. Ge0rG

    Zash: if your "wait, what" relates to Signal: the Signal admins can access exactly the same kind of metadata as your XMPP server admin, except with phone numbers instead of JIDs. But they Totally Promised Not To Do It.

  34. edhelas

    so this is fine

  35. Zash

    I read what dwd wrote as an implied lack of transport encryption

  36. Ge0rG

    Zash: I think "cleartext Signal traffic" was supposed to mean the post-decryption stream

  37. Zash


  38. Ge0rG

    wouldn't that be pre-decryption?

  39. Zash

    Were they the funny people who named their transport protocol "Noise"?

  40. Ge0rG

    Zash: drink some more coffee. Or drink less, if you've had some today.

  41. Zash

    Post-lunch nap perhaps

  42. dwd

    Zash, No, I did mean inside the service. I assume it runs TLS etc.

  43. Zash

    dwd: I have this feeling that they invented their own TLS and named it Noise

  44. dwd

    With that bunch, that's entirely possible.

  45. Zash

    http://noiseprotocol.org/index.html hmmmmm, doesn't say Signal anywhere?

  46. Zash

    But WhatsApp

  47. Ge0rG

    https://blog.powerdns.com/2018/03/22/the-dns-camel-or-the-rise-in-dns-complexit/ - this is so similar to XMPP

  48. Zash

    DNS, complex? But, but, it's being HTTP&JSON-ified! That's the simplest thing evar!!!

  49. Ge0rG

    Zash: take your nap already

  50. ralphm waves

  51. ralphm set the topic to

    XSF Board Meeting | Logs: http://logs.xmpp.org/xsf/ | Agenda https://trello.com/b/Dn6IQOu0/board-meetings

  52. ralphm

    0. Welcome

  53. ralphm

    Who do we have?

  54. ralphm

    I'm back from vacation.

  55. Guus


  56. Guus

    welcome back

  57. Guus

    (MattJ is always here if you mention him 😛 )

  58. Guus


  59. Guus

    *tap* *tap* is this thing on?

  60. MattJ


  61. Guus


  62. MattJ

    Sorry, was temporarily distracted by the doorbell :)

  63. ralphm

    Quorum, yay

  64. ralphm

    Agenda items?

  65. Guus

    I don't have any

  66. MattJ

    I haven't looked at Trello in a while

  67. Guus

    at what point are we going to send someone over to Martin's house to check if he's OK?

  68. Guus

    (not you, Martin. The other Martin)

  69. MattJ

    He did reply to my email fairly promptly, so he's "around"

  70. Ge0rG

    so no need to send a SWAT team?

  71. ralphm

    Didn't we discuss this back in June?

  72. ralphm

    21, specifically

  73. MattJ


  74. ralphm

    Any updates on your side MattJ?

  75. MattJ

    No, the only thing on my side is GDPR, and I'm afraid I've not had time to work on it

  76. ralphm

    Now vacation is over and summer is coming to an end, we should be able to get back in motion.

  77. MattJ

    Yes, hopefully

  78. MattJ

    Just before the end of the term :)

  79. Guus

    which reminds me: should we start looking for the next Board?

  80. ralphm

    That was going to be my only thing for today. Ask Alex when he wants to start that process.

  81. ralphm

    We can already start poking people for interest.

  82. Guus

    sounds like a plan

  83. Guus

    maybe we should also curate our to-do list, see what things we can reasonably expect to get done this term, and what not

  84. ralphm nods

  85. ralphm

    I'll have a look at it for next week.

  86. ralphm

    Anything else?

  87. Guus

    And, while on the subject:

  88. MattJ

    Nothing else from me

  89. Guus

    Should we consider putting in place a system where we do not replace the entire board each year?

  90. Guus

    have two-year terms, staggered - something like that?

  91. Guus

    I'm hoping that that'll prevent ramp-up and shut-down overhead, by making it more of an ongoing process.

  92. ralphm

    Not sure. I don't think it has been a problem before.

  93. ralphm

    All boards I was part of had overlap

  94. dwd

    ralphm, Yes, but not by design, and there's always a feeling that Board can't do anything that goes beyond its term.

  95. ralphm

    That's a good point. This would require changes to our Bylaws, though. Not sure if we can do that before these elections.

  96. Guus

    oh, I'm not in a hurry

  97. dwd

    ralphm, I have occasionally wondered about staggered terms, or an "executive team" that actually does the work, that can be recalled by subsequent boards.

  98. Guus

    shall I post on the members list, see if there's support or not?

  99. MattJ

    We really don't have any kind of executive team

  100. ralphm

    dwd: well, yeah, but since we currently don't even have an Executive Director, we'd to figure out what that all means.

  101. ralphm

    Guus: please do.

  102. Guus


  103. ralphm

    Ok. My last thing was more of a note: FOSDEM has posted a CfP for 2019. Dates are February 2 and 3.

  104. Guus

    ah, someone should kick SCAM in action

  105. ralphm

    So was penciling in Jan 31 and Feb 1 for our own stuff.

  106. Guus

    Sounds good. I've marked it on my personal calendar

  107. ralphm


  108. ralphm

    Cya next week!

  109. ralphm bangs gavel

  110. ralphm set the topic to

    XSF Discussion | Logs: http://logs.xmpp.org/xsf/ | Agenda https://trello.com/b/Dn6IQOu0/board-meetings

  111. Dave Cridland

    So, I've been debugging XEP-0198 support. And I tried - because it seemed easiest - including XEP-0198 data on the stanza itself, as namespaced attributes. Gajim seemed to ignore it - anyone any idea if any clients would choke?

  112. Dave Cridland

    (I was doing this as debugging info I was *hoping* would be ignored, mind...)

  113. Link Mauve

    I still can’t understand how clients could choke on this proper usage of XML, while we are already doing it e.g. for @xml:lang.

  114. Ge0rG

    Dave Cridland: that smells of protocol abuse. But if you give me credentials / IBR, I can test yaxim

  115. Dave Cridland

    Link Mauve, We've avoided namespaced attributes in general because people do screw it up, or at least have historically.

  116. Link Mauve

    I’d really like to see data on that.

  117. Link Mauve

    Please deploy that in the wild. :)

  118. Ge0rG

    I also need to debug an SM anomaly that I've encountered, where messages get duplicated on resume. Sometimes.

  119. Dave Cridland

    Link Mauve, They're a bit of a weird one, in terms of XML, since <x xmlns='foo' attr='blah'/> is entirely different from <a:x xmlns:a='foo' a:attr='blah'/>.

  120. flow

    Ge0rG, duplicates send *after* resume?

  121. Dave Cridland

    Ge0rG, This ought to help track that one down. I'll throw you my IBR-enabled test server's details.

  122. flow

    Dave Cridland, care to share why those elements are different?

  123. Link Mauve

    Dave Cridland, first one would be equivalent to <a:x xmlns:a='foo' attr='blah'/>, because non-prefixed attributes are in the null namespace.

  124. Link Mauve

    flow, ↑

  125. Link Mauve

    But you can perfectly have them in other namespaces.

  126. Dave Cridland

    flow, As Link Mauve says. But thanks for being an exemplar case of not understanding the things.

  127. Link Mauve

    <x xmlns='foo' xmlns:b='bar' b:attr='baz'/> works, but it’s a totally different element.

  128. Link Mauve

    And thus you can also have <x xmlns='foo' xmlns:b='bar' attr='blah' b:attr='baz'/>, with no conflict.

  129. Dave Cridland

    Link Mauve, I'm not sure that a non-prefixed attribute is in any namespace at all, as such.

  130. Link Mauve

    Which is equal to <a:x xmlns:a='foo' xmlns:b='bar' attr='blah' b:attr='baz'/>.

  131. Dave Cridland

    Link Mauve, So you can't, for example, say <x xmlns='foo' xmlns:null='' null:attr=blah'/>

  132. Link Mauve


  133. Link Mauve

    Instead of “the null namespace” I should have said “no namespace”, but null is how this is represented at least in JS and Java.

  134. Dave Cridland

    Link Mauve, Right, but "attr" is "The attr attribute of x", whereas your "b:attr" is the "attr attribute of the bar namespace".

  135. Link Mauve


  136. Dave Cridland

    But in any case, corner-cases like <a xmlns:a='a' xmlns:b='a' a:a='bar' b:a='foo'/> can easily slip through.

  137. Dave Cridland

    Since that XML happens to be legal if you're not processing namespaces, but illegal if you are.

  138. Link Mauve

    Why? :/

  139. Link Mauve

    Ah, missed that both are the same namespace.

  140. Dave Cridland

    Link Mauve, Right.

  141. Link Mauve

    But are there really XML libraries which fail on that?

  142. Link Mauve

    I’d expect they to be fixed by then.

  143. Dave Cridland

    Link Mauve, I'd fully expect that XML to traverse most servers.

  144. flow

    possibly depending on the layer where the XML is embedded. Not all intermediate hops parse each and every part of the stanza

  145. Dave Cridland

    flow, Right. Or at least, not to the namespace level.

  146. Link Mauve

    % nc 5222 <?xml version='1.0'?><stream:stream xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en' xmlns='jabber:client' to='linkmauve.fr'> <?xml version='1.0'?><stream:stream xmlns:stream='http://etherx.jabber.org/streams' xml:lang='en' from='linkmauve.fr' id='a8ccb26b-51b5-4a48-b1cb-ea4734f61a7f' xmlns='jabber:client'><stream:features><starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'><required/></starttls></stream:features> <a xmlns:a='foo' xmlns:b='foo' a:coucou='abc' b:coucou='def'/> <stream:error><not-well-formed xmlns='urn:ietf:params:xml:ns:xmpp-streams'/></stream:error></stream:stream>

  147. Link Mauve

    At least Prosody correctly rejects it.

  148. Ge0rG

    flow: yes, because smack3+0198 was miscounting.

  149. flow

    Link Mauve, even if it is embedded deep down in an extension element within a stanza?

  150. Dave Cridland

    Link Mauve, I'd expect Prosody to, because it's using Expat underneath, right?

  151. MattJ


  152. Dave Cridland

    Link Mauve, But ejabberd uses RapidXML, as does Metre. I'm not sure about Openfire actually - but it wouldn't surprise me if it passed them through unscathed.

  153. Holger

    ejabberd uses Expat.

  154. MattJ

    I thought so. I thought dwd was implying they switched

  155. dwd

    Holger, Oh, I thought the new stuff was using an Erland-wrapped RapidXML?

  156. dwd

    Erlang, even.

  157. Holger

    dwd: Nope still Erlang-wrapped Expat, I'm not aware of attempts to switch.

  158. Holger

    There was a major rewrite of the wrapping itself, which is now mostly in C.

  159. dwd

    Ah! MongooseIM, not ejabberd. exml is now RapidXML.

  160. dwd

    But confusingly, I don't think they use my fork.