XSF Discussion - 2019-08-19

  1. COM8

    Is there a simple C++ XMPP library that lets me interact with raw XML?

  2. COM8

    I wan't to creat an application that runs on a microcontroller with only 500kByte of ROM

  3. jonas’

    COM8, I used libstrophe or libcouplet in the past

  4. jonas’

    (both are C)

  5. jonas’

    (but should be perfectly usable with C++)

  6. jonas’

    example usage in my project: https://github.com/horazont/hint/blob/devel/host/src/xmppintf.c

  7. COM8

    Thanks. will have a look at it

  8. Holger

    COM8: http://deusexmachinae.se/dxmpp/ was written with IoT stuff in mind, but not sure it's minimalistic enough for your use case.

  9. COM8

    Holger: dxmpp looks also interresting. Thanks.

  10. Ge0rG

    Sigh. Prosody will send a cancel/not-acceptable if you are not in a MUC, Biboumi will send a modify/not-acceptable, and ejabberd will just send a sender-less message into the MUC if you happen to be an admin.

  11. Ge0rG

    Consistency, I want you back.

  12. moparisthebest


  13. Ge0rG


  14. Ge0rG

    If I'm reading https://xmpp.org/rfcs/rfc6120.html#stanzas-error-syntax right, `modify` is only about the data, not about your own state.

  15. MattJ

    I'd listen to reasoned argument about whether 'cancel' would better be 'modify', but I am currently unconvinced that 'modify' is correct

  16. Ge0rG

    MattJ: you can re-try sending the message after joining the MUC

  17. MattJ


  18. Ge0rG

    I remember a proposal about an application-defined condition of <not-an-occupant> of sorts.

  19. MattJ

    For me the semantics of the error types are generally most easily distinguished by the appropriate UI - e.g. 'modify' would re-show whatever dialog a user submitted that caused an action

  20. MattJ

    In this case I guess just the input box

  21. Ge0rG

    This feels slightly related to cancel/recipient-unavailable that mod_smacks sends when the session dies.

  22. Ge0rG

    MattJ: I recently added logic to yaxim to mark the message as "not yet sent" and to rejoin the MUC in those cases.

  23. Ge0rG

    but only on cancel/not-acceptable, not on modify

  24. Ge0rG

    maybe Holger knows the right error bounce if you send a message while not being in an ejabberd MUC?

  25. Ge0rG

    Also, the RFC has to say: 'The intended recipient is temporarily unavailable, undergoing maintenance, etc.; the associated error type SHOULD be "wait".'

  26. Ge0rG

    MattJ: the RFC also proposes "modify" for not-acceptable.

  27. Holger

    Ge0rG: Yes ejabberd returns modify/not-acceptable (as per the spec).

  28. Ge0rG

    MattJ: ^

  29. Ge0rG

    Holger: it's only a SHOULD in the spec.

  30. MattJ

    If we deviate from the spec we can certainly fix that

  31. Ge0rG

    And modifying the message _data_ won't fix the issue

  32. MattJ

    I disagree with most cases of "only a SHOULD"

  33. Holger

    Ge0rG: I'm slowly getting used to having to justify why on earth ejabberd adheres to SHOULDs :-)

  34. Kev

    Question: Servers are expected to validate stanza syntax for stanzas they route, but does anyone actually extend that to doing the xml:lang rule checking for duplicate bodies etc.?

  35. Ge0rG

    Holger: not long ago I violently complained about ejabberd implementing a MAY.

  36. Holger

    I do remember :-)

  37. Holger

    Kev: ejabberd doesn't, FWIW. (It only checks the validity of the xml:lang value itself.)

  38. Kev


  39. jonas’

    how about auth/not-acceptable, Ge0rG? :D

  40. Ge0rG

    jonas’: is that a serious proposal? 😜

  41. jonas’

    Ge0rG, partly

  42. Ge0rG

    jonas’: you could submit a PR to 0045 with the new custom error condition.

  43. jonas’

    I could indeed

  44. Ge0rG

    jonas’: will you?

  45. jonas’

    not today

  46. jonas’

    I have an aioxmpp release to make

  47. Ge0rG

    Technically, a message could also be rejected by a MUC for an actual policy violation, right?

  48. Ge0rG

    It would be modify/not-acceptable in that case.

  49. Ge0rG

    So I think cancel/not-acceptable is a cleaner way of signalling "you are not in the MUC".

  50. Ge0rG

    But less clean than cancel/custom-condition/not-an-occupant

  51. MattJ


  52. Zash

    Was it MattJ who said type=auth made sense?

  53. MattJ

    I don't think so

  54. Ge0rG

    it was jonas’ and it wasn't very serious.

  55. Zash

    Well if you consider a join to be almost like auth if you squint the right way

  56. Ge0rG

    Maybe we really just need MUC-Push

  57. jonas’


  58. Ge0rG

    Yeah, let's reinvent all of our protocols without learning from past errors.

  59. jonas’

    I got the impression that MIX at least attempts learn from them

  60. Ge0rG

    From a subset of them, I'd say.

  61. MattJ

    From where I'm looking, it picks a handful of problems with MUC, and fixes them by exchanging them with other design trade-offs

  62. Ge0rG

    Mostly with a significantly increased complexity.

  63. MattJ

    We are solving complex problems

  64. fippo

    the problem space is so complex that there is no one-size-fits-all solution

  65. MattJ


  66. fippo

    (what mattj said...)

  67. Ge0rG

    fippo: right. And forcing all the problems into one solution has proven to end up badly in the past.

  68. Daniel

    i find MIX to be easier than MUC with the shit loads of hacks you need to implement to make it bearable

  69. Ge0rG

    Daniel: only because you don't know yet the shitload of hacks you need to make MIX bearable

  70. Zash

    Wait a decade and say that again

  71. Daniel

    Ge0rG, well mix is not stable yet so we could fix them before they become hacks

  72. Zash

    Requirements change. Hacks accumulate.

  73. Ge0rG

    Daniel: adding MIX rooms to your roster is already a huge hack.

  74. Ge0rG

    proxy JIDs... another hack

  75. Ge0rG

    handling of intermittent s2s failures: a hack waiting to happen

  76. Daniel

    well we decided to not do that

  77. Daniel

    putting it in the roster

  78. Daniel

    the xep just doesn’t know that yet

  79. Ge0rG

    oh, where did I put my "told you so" stamp?

  80. Daniel

    what part?

  81. Ge0rG

    MIX has all the signs of "design by committee"

  82. Zash

    MUC doesn't?

  83. Ge0rG

    Daniel: the MIX-in-roster part

  84. Daniel

    that we are going to decide not to do that?

  85. Ge0rG

    Zash: hm..

  86. Ge0rG

    Daniel: that it's a very dumb idea.

  87. Daniel

    yes; that's why we decided to get rid of it

  88. Ge0rG

    When did you? And who's "we" anyway?

  89. Ge0rG

    ah, Summit

  90. Ge0rG

    Heh, my first opposition to MIX in Roster was three years and two days ago.

  91. Zash

    Delayed happy opposition day!

  92. Ge0rG

    I'm not sure whether to be glad or sad.

  93. jonas’


  94. jonas’

    It was brought to my attention (as author of XEP-0414) that the section "Analysis of [Hash function use in] Existing XMPP Extensions" was lost in the split of XEP-0300 and XEP-0414

  95. jonas’

    I am inclined to remove the (dangling) reference to that section from XEP-414 entirely

  96. jonas’

    but I could link it to an older version of XEP-0300 instead

  97. jonas’

    does anyone here happen to have a strong opinion on that one?

  98. jonas’


  99. Zash

    No strong opinions here. Maybe a "hmm, not sure" from me.

  100. jonas’

    those who have implemented XEP-0027 (Current Jabber OpenPGP Usage): my reading of the XEP indicates that messages are either signed or encrypted, but never both

  101. jonas’

    this doesn’t make sense to me

  102. jonas’

    but the XEP lacks a writeup on how an signed+encrypted message would look like

  103. ralphm

    You can just have both elements I think.

  104. ralphm

    In any case you only encrypt/sign the body/status.

  105. jonas’

    but it’s not specified whether you sign or encrypt first

  106. jonas’

    it’s not specified whether the raw or the armored encrypted output is signed (if encrypt-then-sign is used)

  107. ralphm

    Yeah, maybe I'm wrong: “It does not enable both signing and encryption of a stanza, only signing of the presence status and encryption of the message body.”

  108. jonas’

    that’s kind of meh

  109. jonas’

    is it really how it’s deployed in the wild?

  110. ralphm

    I think the general opinion of it isn't high.

  111. jonas’

    it seems to be the way how openpgp is implemented nowadays though

  112. ralphm

    Also replay attacks

  113. jonas’


  114. jonas’

    that’d be my concern

  115. jonas’

    but apparently that’s the case indeed

  116. jonas’

    Conversations uses ACTION_ENCRYPT for the message

  117. jonas’

    if I’m reading the code right

  118. jonas’

    https://github.com/open-keychain/openpgp-api/blob/master/openpgp-api/src/main/java/org/openintents/openpgp/util/OpenPgpApi.java#L119 https://github.com/siacs/Conversations/blob/49224335fc5cc9c950f347e29ab9f3bbe33792fc/src/main/java/eu/siacs/conversations/crypto/PgpEngine.java#L50

  119. jonas’

    https://github.com/open-keychain/openpgp-api/blob/master/openpgp-api/src/main/java/org/openintents/openpgp/util/OpenPgpApi.java#L119 https://github.com/siacs/Conversations/blob/master/src/main/java/eu/siacs/conversations/crypto/PgpEngine.java#L50

  120. moparisthebest

    there is a reason to encrypt but not sign, repudiation, ie "what? I didn't send that and you can't prove that I did!!!!"

  121. moparisthebest

    but there is also value in encrypt + sign if you don't need that property

  122. flow

    I am always suprised that xep27 is still gets implemented given the amount of serious issues it has

  123. jonas’

    (context why I’m asking: feature request for xep-0027 support against aioxmpp)

  124. Ge0rG

    jonas’: sometimes it's best to reject feature requests.

  125. jonas’

    sometimes, but then again, we’d just provide the schema declarations anyways

  126. jonas’

    e2ee implementation is for now out of scope for aioxmpp

  127. moparisthebest

    flow, like what?

  128. moparisthebest

    I mean it's basically the same as encrypted but not signed email, it can be useful, you just have to know what you are getting

  129. flow

    moparisthebest, like the ones mentioned at https://xmpp.org/extensions/xep-0027.html#security (and there are probably more)

  130. moparisthebest

    those aren't really "security issues" as such though

  131. flow

    and "it can be useful" is probably true, but I'd argue most xep27 users, would expect signed and encrypted messages

  132. flow

    the encrypt only use case is rarely useful

  133. Zash

    jonas’, this be why '27 is discouraged and OX is a thing I believe

  134. moparisthebest

    for example I used to have my various servers send me alert/cronjob emails etc pgp encrypted, and then I switched to xep27 xmpp messages, same (actually slightly better) security properties

  135. moparisthebest

    but yea if users think they are getting something else, that's their problem

  136. Ge0rG

    moparisthebest: that doesn't sound like you had a requirement to not sign.

  137. moparisthebest

    other than I didn't generate PGP keys for my servers no

  138. flow

    well it was signed before, so it is true that is not a step back. But if your use case is human-to-human interaction, then "encrypt only" is not what you ever want to do with OpenPGP

  139. flow

    *wasn't signed before

  140. jonas’

    FWIW, I’m going to tack: .. warning:: Please see the security considerations of :xep:`27` before making use of this protocol. Consider implementation of :xep:`373` instead. on all the things touching XEP-0027 in aioxmpp

  141. jonas’

    flow, I have in the past intentionally sent unsigned but encrypted emails

  142. jonas’

    but those are very *very* rare cases

  143. jonas’

    probably less than five since I started to use gpg

  144. jonas’

    and I don’t think it’s the default in any way, and I *do* think that an E2EE protocol which does not support signing of messages *at all* is definitely a prolbem

  145. flow

    I can't imagine that the average joe user would want to send unsigned but encrypted mails

  146. jonas’


  147. jonas’

    me neither

  148. flow

    jonas’, what was your intention sending unsigned but encrypted?

  149. moparisthebest

    anti-govt activists would though

  150. jonas’

    flow, yes

  151. ralphm

    Average joe actually doesn't think about encryption at all.

  152. moparisthebest

    though I'd accept an argument they should just use OTR instead

  153. jonas’

    flow, I made statements which I wasn’t sure I wanted to have signed with my public identity.

  154. Ge0rG

    moparisthebest: I'm sure they could just create a throw away key

  155. flow

    moparisthebest, anti govt activists shouldn't use e-mail (and probably xmpp) at all for their communication

  156. flow

    jonas’, hmm, I don't know the exact case, but that is usually a sign to sleep over the mail another day until you send it ;)

  157. jonas’

    flow, I had done that step already

  158. pep.

    Is memberbot offline?

  159. pep.

    Ah it's fine now

  160. pep.

    https://wiki.xmpp.org/web/Jonathan_Siegle_Application_2019 Is he around here somewhere? I've never actually heard of him, didn't even know he was running xsf machines

  161. pep.

    (or maybe it's just that I don't know the realname)

  162. ralphm

    No, he's very much in the background these days