XSF Discussion - 2021-04-07

  1. alexbay218

    Is there a place I can get information on xmpp spec? I'm looking at https://xmpp.org/extensions/ and I can't find clear info on how to work with xmpp messages (stanzas?)

  2. alexbay218

    anyone here?

  3. menel

    alexbay218: I think most will wake up in a few hours.. But isn't it in the core what you seek? https://xmpp.org/rfcs/rfc6120.html

  4. alexbay218

    I see, I got there eventually, but I'm wondering if I'm missing some sort of tutorial that more easily explains it. Reading full specifications is pretty dry

  5. menel

    There are some devs in this room.. Maybe they know some tutorial website.. But its early in the morning in Europe and late in the US east cost

  6. alexbay218

    figured, I'll ask later

  7. Ge0rG

    Now I wonder... are my Last Call responses so long that nobody is going to read them? Maybe I should just strategically bring up the most important point only, and then -1 the XEP so that I can bring up the second most important point in the year after? :D

  8. Ge0rG

    jonas’: AOB for today, or maybe just for you with your Editor hat: would it make sense to collect CVEs related to XEPs in a XEPs meta-data / Security Considerations / somewhere?

  9. jonas’


  10. jonas’

    or maybe

  11. jonas’

    CVEs are for implementations, so it’ll be interesting to find a good clear cut of when a CVE should be mentioned in the XEP or not…

  12. jonas’

    but in case of '280, heck yeah, add it

  13. Ge0rG

    did you just say DOAP?

  14. Ge0rG

    I'm also looking at 0313

  15. jonas’

    did I miss something there?

  16. Ge0rG

    0297 Security Considerations are rather clear OTOH

  17. Ge0rG

    jonas’: https://monal.im/blog/cve-2020-26547/

  18. jonas’

    Ge0rG, that’s 280 tho

  19. Ge0rG

    jonas’: it's MAM and Carbons, as well as https://gultsch.de/dino_multiple.html

  20. jonas’

    ok, the description on the page only says carbons

  21. Ge0rG

    "Monal before 4.9 does not implement proper sender verification on *MAM* and Message Carbon (XEP-0280) results."

  22. jonas’

    yeah, those CVEs should probably be linked as an example for '280, '313 and also '297, because people don’t seem to get it.

  23. Ge0rG

    Yeah, but the Security Considerations typically already contain wording saying that "you must not". And still, people don't get it. Or don't read them. I'm not sure how to improve the developer-experience here

  24. Ge0rG

    short of a Huge Red Blinking Marquee

  25. jonas’

    CVE numbers are scary

  26. Ge0rG

    only if you see them

  27. jonas’

    yes, hence add them to the security considerations of all those documents

  28. Ge0rG

    I suppose it would make sense to have some plumbing for adding CVEs, making it possible to auto-extract them in some way?

  29. jonas’

    maybe, PRs welcome ;)

  30. jonas’

    I imagine this to be tricky though

  31. Ge0rG

    like a `<cve number="2020-26547" uri="https://monal.im/blog/cve-2020-26547/">Improper verification of MAM and Carbons in Monal before 4.9</cve>`

  32. jonas’

    I wouldn’t want to associate them to document metadata directly, because in most cases it’s not a problem with the document, but a problem with implementations.

  33. jonas’

    so having a list of CVEs on a XEP gives the wrong impression

  34. Ge0rG

    Yeah, I'm speaking of a template for stuffing it into the body and rendering

  35. jonas’

    and havnig a list of <cve/> elements in the header and then making xep.xsl inject those in the security considerations section is breaking lots of abstractions

  36. jonas’

    ok, yeah

  37. jonas’

    somewhat like link/footnote etc

  38. Ge0rG


  39. jonas’

    go for it I’d say, we can discuss it in council if need be. we might learn that it’s a board matter though, not quite sure

  40. Ge0rG

    Probably better than https://xmpp.org/extensions/xep-0223.html#revision-history-v1.1

  41. jonas’

    (though I’d argue it’s an editor matter)

  42. Ge0rG

    Then there is also the last sentence of https://xmpp.org/extensions/xep-0373.html#security

  43. dwd

    I'm in favour of including CVEs encountered in implementing XEPs in those XEPs, whichever hat I'm wearing.

  44. Ge0rG

    dwd: but what if you are not wearing any hat?

  45. dwd

    Even then.

  46. dwd

    I'd actually be fine with information notes pointing to implementation dicussion on the Wiki, too, thinking about it.

  47. Ge0rG

    Does anybody volunteer to create an XML template?

  48. Ge0rG

    dwd: I think that's why we created https://wiki.xmpp.org/web/Category:Spec_Remarks but it might be non-trivial to do an automatic redirect from XEP title to mediawiki slug

  49. Ge0rG

    especially if the slug isn't consistent

  50. dwd

    Ge0rG, I'm thinking manual works for now.

  51. jonas’

    Ge0rG, you just did, didn’t you? :)

  52. Ge0rG

    jonas’: I'd love to, but who's going to plow my snow?

  53. jonas’

    your laptop which you’re holding in the snow while running the test build with the new xsl file!

  54. jonas’


  55. dwd

    Ge0rG, Is that a euphemism?

  56. Ge0rG

    jonas’: unfortunately, my new laptop is very energy efficient.

  57. Ge0rG

    dwd: whatever floats your boat!

  58. dwd

    Ge0rG, Is *that* a euphemism?

  59. dwd

    Maybe it's euphemisms all the way down.

  60. Ge0rG

    dwd: it always is.

  61. dwd

    Maybe the turtles are a euphemism.

  62. Ge0rG

    What are the turtles a euphemism for? For turtles?

  63. dwd

    You may have just blown my mind.

  64. jonas’

    is that an euphemism?

  65. dwd

    jonas’, No, just a metaphor.

  66. Kev

    It’s like an explosion in his brain-cage.

  67. Ge0rG

    Aren't euphemisms a subset of metaphors?

  68. dwd

    A subset *and* a superset.

  69. dwd

    (It's possible that only Kev will get that reference...)

  70. Kev

    But he did, so that’s alright

  71. Ge0rG

    dwd: I suppose that your statement isn't based on set theory.

  72. Kev

    Ge0rG: Someone once claimed that their implementation of a XEP was both a superset and a subset of the functionality.

  73. Ge0rG

    Kev: that's not a bad statement actually

  74. Kev

    Not as long as they meant that it was an exact implementation of the XEP. They didn’t.

  75. dwd

    "Sure, we don't do that mandatory thing, but we do this other thing instead so we're still conformant, right?"

  76. Ge0rG

    Well, handling it right requires a certain understanding of set theory, yes.

  77. Guus

    I got questions asked in context of a standard that defines some kind of uniform data transfer over XMPP, that I am unfamiliar with: IEC 61850-8-2. When I google for the standards, I find various applications of Openfire (eg: electricity grid management over XMPP). Anyone familiar with that standard?

  78. Zash

    Only aware that there's some grid management RFC involving XMPP.

  79. flow

    i think that's a different grid

  80. flow

    the IEC standards deal mostly with power girds I'd assume

  81. flow

    but no familarity here, cause I don't have the bucks to pay for that standard (and I am also unable to retrieve it via my university)

  82. dwd

    Zash, I think *that* grid is for the Cyberzz, whereas the IEC one is for the Leccy Grid, as we say here.

  83. Zash


  84. dwd

    Zash, The RFCs as I recall do Cyber Threat Information Exchange, whereas the IEC one does - I think - electricity grid management.

  85. dwd

    Zash, Possibly interconnect management. Your country's power controlled by Openfire.

  86. dwd

    Zash, And probably version three point something ancient.

  87. vanitasvitae

    EPOX - Electric Power over XMPP

  88. Kev

    dwd: I couldn’t be more scared.

  89. Kev

    I mean, I tried, but my power failed.

  90. Guus


  91. Ge0rG

    jonas’: I wanted to push a PR on gitlab, but gitlab/main is two months out of date

  92. Ge0rG

    Well, now it looks like I created it on my own repository. Well done.

  93. Ge0rG

    jonas’: rendering build is running on https://gitlab.com/ge0rg/xeps/-/merge_requests/1 - code is also on https://github.com/ge0rg/xeps/tree/cve

  94. Ge0rG

    rendered version also at https://op-co.de/tmp/xep-0280.html#security - feel free to bash

  95. Ge0rG

    I'm not sure if this is enough or if the format should have a caption that contains a title and a text area that contains a description.

  96. deuill


  97. deuill

    Should... should somebody tell him?

  98. Zash

    Sam already did: https://lists.sr.ht/~sircmpwn/public-inbox/%3C08dd6c3d-b9f6-4b50-83b1-3fedbb763de8%40www.fastmail.com%3E

  99. deuill

    Hah, I, of course, didn't expect much of it.

  100. moparisthebest

    I don't get it, when I come up with a great idea and find someone else already implemented it for me I'm delighted I don't have to do any work :)

  101. ben

    i thought he was describing xmpp too...

  102. ben

    i bugged him about it on irc and wouldn't even consider it at all becuase xml and it "already failed"

  103. deuill

    It's a shame since people look up to Drew, or at least seem to admire the tenacity, but there's two sides to that apparently.

  104. deuill

    If you disregard the actual technical/implementation aspects of XMPP, the fact remains that the collection of RFCs and XEPs describe in great detail the *semantics* of a federated, extensible communication protocol.

  105. deuill

    I find it hard to believe that any other federated system won't end up walking down the same paths in many ways.

  106. ben


  107. Ge0rG

    Unless that other federated system is just a marketing plot of a startup company?

  108. Zash

    Email? Hm, I don't think so.

  109. Ge0rG

    > I'm converting more and more people from other messengers to come join me on @matrixdotorg. Clearly the best choice if you want something that's OSS + open-standards-based and federated *and* not requiring a phone number as a primary identifier (I always found that sooo dumb). https://twitter.com/juliusvolz/status/1379891845229117452

  110. wgreenhouse

    > Sam already did: https://lists.sr.ht/~sircmpwn/public-inbox/%3C08dd6c3d-b9f6-4b50-83b1-3fedbb763de8%40www.fastmail.com%3E :facepalm: