XSF Discussion - 2020-02-18

  1. Ellenor Malik

    XMPP over XMPP

  2. jonas’

    Ge0rG, in-band

  3. jonas’

    Ge0rG, out-of-band

  4. Ge0rG

    jonas’: you still have three weeks to reapply!

  5. Daniel

    jonas’: if you come to the meetup on Thursday I can remind you oob

  6. jonas’

    Ge0rG, no? reapplications close on Feb 23rd

  7. jonas’

    Daniel, that’d mean leaving the house

  8. jonas’

    I suppose

  9. Ge0rG

    jonas’: I'm sorry, you are right

  10. jonas’

    nice try to get me kicked out of council! ;)

  11. MattJ


  12. Ge0rG

    jonas’: not just you! :P

  13. pep.

    https://github.com/xsf/xmpp.org/pull/679 Anybody with superpowers to review plz? :)

  14. Ge0rG

    > The next Summit will happen next year. 😁

  15. emus

    Have you hear that the BND is financing open source projects with 5000€ similar to GSoC?

  16. Ge0rG


  17. dwd

    That's the German Foreign Intel agency?

  18. vanitasvitae

    emus: yeah

  19. Ge0rG

    dwd: yes

  20. pep.

    Ge0rG, I'm very hopeful!

  21. dwd

    I suppose it's possible that XMPP projects would be favoured there.

  22. Ge0rG

    dwd: the ones that were "recently" uncovered to have backdoored Crypto AG

  23. Ge0rG

    (the involvement was known since 1997, but apparently it's big news in 2020)

  24. dwd

    Ge0rG, Hah. That's such an old story, and moreover a repeated pattern that's been occurring since after WW2.

  25. Ge0rG

    dwd: indeed

  26. edhelas

    > BND financing open source projects > OMEMO:2 incoming > 🤔

  27. dwd

    Ge0rG, First case I'm aware of is the UK selling Enigma systems post-war. However, I have a suspicion that there's a similar case after the Napoleonic wars.

  28. pep.

    edhelas, conspiracy!

  29. dwd

    edhelas, I'm not sure that wold be relevant. It's unclear to me if that would fit the threat model.

  30. pep.

    Daniel is an undercover agent

  31. dwd

    edhelas, I'm not sure that would be relevant. It's unclear to me if that would fit the threat model.

  32. pep.


  33. dwd

    edhelas, In particular, BND presumably do trust their server, and probably more than the mobile devices used in the field.

  34. vanitasvitae

    edhelas: shhhh

  35. pep.

    Curious to know if there's anything you can do to prevent messages leaking once a terminal is compromised :x (as long as it's not known to be)

  36. dwd

    pep., It's more that if you think a device might be compromised, with OMEMO/Signal/etc the device has a cleartext archive, whereas without it won't and you can cut access to the server-side archive.

  37. pep.

    without what e2ee it won't have a cleartext archive?

  38. pep.

    I'm not sure I understand

  39. pep.

    You mean the client won't explicitely store locally?

  40. dwd

    pep., For example, with WhatsApp, the device stores a database of all the message history.

  41. dwd

    pep., Whereas with Pando (for example) we explicitly don't, and instead pull that from the server.

  42. pep.

    That doesn't mean it doesn't see the cleartext messages

  43. dwd

    pep., Sure. But there's a matter of the effect of a compromise post-discovery.

  44. pep.

    (you kinda have to, I don't have bionic e2ee-capable eyes)

  45. dwd

    pep., The question isn't who and what device can see the messages. The question is where the archive is kept at rest.

  46. pep.

    Well this assumes you have any doubts

  47. dwd

    pep., Well, only in as much as if someone compromises a device without your knowing all bets are off no matter what you do.

  48. pep.

    what I said above :)

  49. dwd

    pep., So not much point in considering that case. Instead, consider the cases where endpoint compromise is known.

  50. dwd

    pep., And decide which you think is the greater risk - for some, that'll be the server being compromised, for others, the client. Which you feel is the bigger risk means you might want OMEMO-style encryption or not.

  51. pep.

    Sure there's a point in considering it as well. It's certainly a lot easier to get a hold of a user terminal when that user is targetted. When the user is not targetted directly and people are just interested in data, it's probably faster to try and compromise the server and I bet there's lots of servers not that good security-wise

  52. dwd

    pep., Right, but for a foreign intel agency, I would suspect the risk of a compromised client is probably higher.

  53. dwd

    pep., Same for us, actually. I believe the risk of a community nurse leaving their phone in a patient's house is higher than someone breaking into our servers.

  54. dwd

    pep., But that won't be the same for everyone, of course.

  55. pep.

    Who knows.. One would hope they employ capable people and they give us the freedom to act

  56. pep.

    Who knows.. One would hope they employ capable people and they give them the freedom to act

  57. Zash

    Myeah, forgetting my phone somewhere does seem more likely than someone breaking into my server room and/or server.

  58. dwd

    Zash, But if you ran your server for thousands on people, the risk profile might change.

  59. dwd

    Zash, But if you ran your server for thousands of people, the risk profile might change.

  60. dwd

    Zash, For you, if not for your users.

  61. Zash

    I don't, so my users == { me }

  62. dwd

    My best understanding of why WhatsApp have encryption is to protect themselves from subpoena activity, not for security for their users as such.

  63. Zash

    Makes sense.

  64. emus

    vanitasvitae, Ge0rG: I mean lets take away their money - modern problems need modern solutions :)

  65. Ge0rG

    dwd: it has helped very much, hasn't it? https://www.reuters.com/article/us-facebook-brazil/facebook-executive-jailed-in-brazil-as-court-seeks-whatsapp-data-idUSKCN0W34WF

  66. pep.

    Open reuters > Get visually agressed by cookies' consent bs > Manage consent > JS error..

  67. Ge0rG has the "I don't care about cookies" extension and didn't notice anything

  68. pep.

    I have a similar extension but I still get their annoying popup

  69. Neustradamus

    I have a little request, can you open: https://nl.movim.eu/?feed/pubsub.movim.eu/Movim When you click on the publication titles, have you the publication or other?

  70. MattJ

    I get prompted to download the atom feed

  71. pep.


  72. MattJ


  73. pep.

    I'm not sure browsers parse this correctly anymore.. curl tells me "content-type: application/atom+xml; charset=UTF-8" so that's correct right?

  74. Neustradamus

    Thanks guys, you have confirmed the problem to edhelas, I am not alone ;)

  75. pep.

    Neustradamus, I'd say your client is the issue. Use a proper feed reader

  76. edhelas

    the problem is that the feed reader is not taking the alternate + text/html

  77. edhelas

    but only the first alternate, that is kinda an issue; so i'll fix that one

  78. Neustradamus

    The problem is linked to (for example): </content> <link rel="enclosure" type="image/png" href="https://upload.movim.eu/files/9d94237298995552fa13436420195fbca436dce7/jDBsJ9BW7g66gCZ3G3ARICSq5T3dsAg9j75CnNOr/image.png"/> <link rel="alternate" href="https://upload.movim.eu/files/9d94237298995552fa13436420195fbca436dce7/jDBsJ9BW7g66gCZ3G3ARICSq5T3dsAg9j75CnNOr/image.png"/> <link rel="alternate" type="text/html" href="https://nl.movim.eu/?node/pubsub.movim.eu/Movim/87633da7-3963-4923-aabc-54ac5f6ad1d8"/> </entry>

  79. pep.

    edhelas, if that's a problem to you then then I think it's before that.

  80. pep.

    HTTP Headers

  81. edhelas

    Neustradamus I actually told you 2min ago that I will fix the issue, why bothering the people here about that ?

  82. Neustradamus

    edhelas: I sent here before you understand the problem

  83. edhelas

    also, Atom implementation in Movim is definitly not a topic related to this chatroom

  84. Neustradamus

    edhelas: I can not join the main mucroom ;)

  85. pep.

    yes you've been banned, for reasons one can understand

  86. Neustradamus

    I know that some people do not like when we inform about problems, we can see a new time today. If no people inform, no solution ;)

  87. MattJ

    Sometimes it's not about the information, but about the delivery

  88. Alex

    Reminder that the current application period ends by the end of this week. In case you want to appy, recruit someone to apply, or need to reapply: https://wiki.xmpp.org/web/Membership_Applications_Q1_2020 Thanks

  89. Daniel

    jonas’: ^

  90. Guus

    Daniel is yours a haiku? 🙂

  91. jonas’

    application done, thanks

  92. dwd

    jonas’, Any chance we can last call XEP-0345 again? I have no idea what happened to it last time. Board, BTW, not Council.

  93. pep.

    It's be voted in by board

  94. pep.

    Last board

  95. dwd

    pep., Has it? Showing as Proposed, currently.

  96. pep.

    I was the only one to answer the LC and board didn't take that into account anyway

  97. jonas’

    I must’ve missed that one, can you dig up records?

  98. dwd

    pep., And LC ending over two years ago.

  99. pep.

    hmm when was that again..

  100. moparisthebest

    again, many people aren't getting all mailing list posting because xsf's mailmain still breaks DKIM and SPF and therefore DMARC

  101. moparisthebest

    I get maybe half of the emails sent to the list, it depends on the email settings of the sender

  102. moparisthebest

    (please fix mailmain)

  103. jonas’

    I love how those "anti spam" technologies break valid usecases while not preventing spam.

  104. jonas’

    but yeah, we should probably get that fixed

  105. moparisthebest

    why do I keep typing mailmain instead of mailman...

  106. Zash

    Those aren't anti-spam

  107. jonas’

    AFAIK it involves: - Turn off the footer - Turn off the subject prefix - Enable the masquerading of From for DMARC-protected domains

  108. moparisthebest

    so dmarc allows a pass if *either* SPF or DKIM passes, you can't not break SPF, so if you simply stop breaking DKIM that should fix everything

  109. moparisthebest

    which yes, turn off footer and subject prefix

  110. jonas’

    it will fix everything related to DMARC, but break the UX

  111. moparisthebest

    make sure the List-Unsubscribe header is set, and you'll be golden

  112. jonas’

    can we get a mailman admin, please?

  113. pep.

    What are the cons again of validating dkim at the mailing list level and having the mailing list then do dkim itself? Not being able to validate end-to-end?

  114. jonas’

    cc @ MattJ

  115. jonas’

    pep., the cons are that it doesn’t help

  116. pep.

    how so

  117. jonas’

    (also, operational cost)

  118. jonas’

    pep., you still break the DKIM signature of the original sender

  119. Zash

    Just masquerade the Sender and be done with it

  120. pep.

    You remove it even. The list signs itself

  121. moparisthebest

    you can do that too ^

  122. moparisthebest

    I mean, instead

  123. jonas’

    pep., and then the receiver looks up the DMARC record and sees that there should be a signature for that sender

  124. pep.

    jonas’, the sender being the list?

  125. jonas’


  126. jonas’

    I always get confused with Sender vs. MAIL-FROM vs. From:

  127. jonas’

    and also Return-Path

  128. Zash

    From is purely metadata, you can put whatever you want there

  129. pep.

    Well Return-Path is the list here, and I'd put both enveloppe and the other as the list anyway and sign with the list.

  130. Zash

    != routing data

  131. jonas’

    pep., requires setting up and maintaining a DKIM thing though

  132. pep.

    If I want to validate who sent what I'd use normal gpg signing

  133. jonas’

    pep., yeah, tell that please to the DKIM idiots

  134. pep.

    not what I'm saying

  135. Zash

    pep.: Footers can break gpg tho

  136. jonas’

    Zash, they’re attached as separate text/plain part

  137. Zash

    Right. Not on every list tho.

  138. pep.

    I always assume DKIM allows us to validate point-to-point. I'd expect the list to do the validation always, not a host at the other end of the chain

  139. Zash

    *mumble* Google Groups

  140. pep.


  141. moparisthebest

    I get people have opinions re: DKIM/SPF/DMARC but that's not really relevant, they are a thing most email providers implement, and if we want most people to be able to recieve mail to the list, it has to be fixed

  142. jonas’

    moparisthebest, yeah, help me get hands on a mailman admin

  143. pep.

    moparisthebest, yeah I'm proposing a practical solution :p

  144. jonas’

    pep., setting up and maintaining OpenDKIM is *not* practical

  145. jonas’

    (on the XSF resource budget either way)

  146. pep.


  147. pep.

    Meaning I'm not just talking about protocols because I like to talk about protocols

  148. moparisthebest

    (I run rspamd which does DKIM+SPF+DMARC+spam stuff automatically, and is easier to set up than opendkim+spf+spamassassin+amavisd+everything else)

  149. jonas’

    I love especially how rspamd depends on redis, but doesn’t support redis clusters.

  150. moparisthebest

    but beside the point, there are basically 2 ways it can be fixed: 1. stop breaking DKIM signatures (don't add footer or mangle subject) 2. send from xmpp domain instead

  151. moparisthebest

    the XSF mail server *should* already be validating dmarc/dkim/spf or it can be used to forward unauthorized mail/spam

  152. moparisthebest

    does anything actually stop me from sending mail as a board member to a board-only mailing list?

  153. jonas’

    moparisthebest, this is a question I’ve been asking myself for quite some time and which I wanted to pen-test after having asked board, but I never got around to actually do that.

  154. moparisthebest

    what's the official way to get that on the board's agenda as a question?

  155. jonas’

    send a message to board@

  156. jonas’

    someone will hopefully fish it out of the moderation queue

  157. pep.

    moparisthebest, "as a board member"?

  158. jonas’

    aside from that I may still have +w on the board trello, or you can ask pep. who’s on board, too.

  159. pep.

    I don't think you can send stuff to board@ if you're not subscribed can you?

  160. moparisthebest

    pep., like, impersonating your email for instance

  161. jonas’

    pep., but the subscription only checks From

  162. jonas’

    (or maybe Sender)

  163. pep.

    ah I see

  164. pep.

    We're not using board@ anyway, and I don't like it

  165. moparisthebest

    and if it doesn't do dkim/dmarc/spf or something, then I can happily send "official board emails" from ralphm or pep. or whoever

  166. pep.

    So you can send what you want. Plus I always sign my emails :P

  167. jonas’

    email from is not to be trusted. news at 11.

  168. pep.


  169. moparisthebest

    right, and all those are terrible hacks to add authentication to it :/

  170. pep.


  171. moparisthebest

    it's getting better, but hacking that on after the fact is rough

  172. moparisthebest

    also ARC incoming...

  173. moparisthebest

    http://arc-spec.org/ ^

  174. pep.

    dwd, MR 20190307T15:16:48Z 000 <ralphm>  motion carries. Let the Editors go through to the mechanics to move XEP-0345 to Active.

  175. MattJ


  176. pep.

    I was looking for that

  177. jonas’

    ah, that’s clearly my fault

  178. jonas’

    fixing that now

  179. pep.

    It's indeed not been processed by editors, but I wouldn't go as far as saying it's your fault. There are many other editors :x

  180. jonas’

    were there back then though?

  181. pep.

    No, but there are others

  182. jonas’

    reminds me to ask board to clean up editor membership

  183. pep.


  184. jonas’

    I abused my privileges to create https://trello.com/c/8Q5XQWks/388-clean-up-editor-team-memberships

  185. pep.

    how dare you

  186. pep.

    Thanks, looks good

  187. dwd

    I always sign my emails too - I put "Dave." at the bottom.

  188. pep.

    Indeed. Just like signatures we use on legally binding documents, it's been proven it works very well

  189. pep.

    (I had a hard time making it less sarcastic)

  190. jonas’

    Subject: [Standards] ACTIVE: XEP-0345 (Form of Membership Applications)

  191. jonas’

    there we go

  192. pep.

    Thanks :)

  193. jonas’

    ah, I need to re-last-call '402

  194. lovetox

    dwd, the example in 402 for publish options is not the best

  195. lovetox

    you use max_items = 10000

  196. lovetox

    if you are a new client and there are existing bookmarks, this results 99% in a failed publish

  197. dwd

    lovetox, PRs welcome. I didn't actually write that one, I think Link Mauve did (he actually wrote most of that spec at this point, we should make him an author).

  198. Daniel

    Yeah I think that probably predates the max thing in pubsub

  199. lovetox

    ah k, yeah we should change that, there is a new max-items=max in pbusub

  200. lovetox

    though this probably also will fail, because no server supports that yet

  201. Daniel

    And having a 'magic' number was the best we good do before

  202. Zash


  203. Daniel

    Yes 'atomic bookmarks in pep' probably just depends on max being supported

  204. Daniel

    Which should be mentioned somewhere

  205. Ge0rG

    has the "max" bike shedding settled yet?

  206. dwd

    Daniel, "PEP Native Bookmarks". I bikeshedded the name a bit further.

  207. Ge0rG

    IIRC there was a revamp by server developers who objected because "max" is not a valid integer

  208. jonas’

    dwd, though I consider that name slightly confusing

  209. jonas’

    I plan to bikeshed on that one

  210. Daniel

    Yes you can name it whatever you want as long as it's called atomic bookmarks in pep

  211. dwd


  212. Zash


  213. Daniel

    That's a compromise I can live with

  214. Ge0rG


  215. Ge0rG

    Did we have "Schrödinger's Bookmarks" yet?

  216. dwd

    Ge0rG, Heisenberg's Bookmarks? You know how to store them or what they are, but not both?

  217. Ge0rG

    dwd: I appreciate that. +1

  218. Ge0rG

    Also what's the dance I need to perform to determine whether PEP on my server is persistent?

  219. Ge0rG

    (as in: stored to disk, not to RAM)

  220. Daniel

    I think there is a feature

  221. Ellenor Malik

    > dwd has written: > edhelas, In particular, BND presumably do trust their server, and probably more than the mobile devices used in the field. Trusting the server does not seem like a viable threat model ever

  222. Zash

    Ge0rG, `#persistent-items` maybe?

  223. pep.

    I'd like the max_items=max thing to be settled so that we can actually use the feature :x

  224. Zash

    But muh validation code :(

  225. Ge0rG

    I wouldn't be opposed to make `-1` the new max.

  226. pep.

    I'll let you bikeshed the thing, I just need the feature

  227. Ge0rG

    because max_items=0 can obviously mean "you shall not pass", but -1 is actually something like "unlimited" in computerese

  228. Ge0rG

    But I suppose the author is already fed up with the unicode discussion

  229. dwd

    Ellenor Malik, At all? Ever? I trust my server because it's in the same room as me right now, and only I have access.

  230. Ellenor Malik

    Never ever.

  231. dwd

    Ellenor Malik, For anything?

  232. Ge0rG

    dwd: but you are not always in that room, are you?

  233. dwd

    Ge0rG, Pretty much. :-)

  234. Ge0rG

    dwd: I've heard rumors of you being in Brussels and not having your server room around you

  235. dwd

    Ge0rG, Lies.

  236. dwd

    Ge0rG, And/or a clone.

  237. Ge0rG

    maybe your server is an evil twin now.

  238. Ellenor Malik

    "Only I have access." Only true if you built the processor, hard disk, and everything yourself.

  239. Ge0rG

    or maybe the evil twin was in Brussels indeed, and told people embarassing stories about the origins of your na,e

  240. Ge0rG

    or maybe the evil twin was in Brussels indeed, and told people embarassing stories about the origins of your name

  241. jonas’

    Ellenor Malik, so you can’t trust the client either. Your argument is invalid.

  242. dwd

    Ellenor Malik, OK, but the same goes for your client device, so you're saying nobody can trust anything, and we may as well all go home.

  243. jonas’

    ^5, dwd

  244. Ellenor Malik

    > jonas’ has written: > Ellenor Malik, so you can’t trust the client either. Your argument is invalid. to be clear, the first part does not imply the second part

  245. Ellenor Malik

    it's best to trust as few links as possible

  246. dwd

    Ellenor Malik, Yes, I agree, keep the attack surface low etc. I just suggested that there were cases where the risk to the client device was higher than the risk to the server.

  247. dwd

    Ellenor Malik, Certainly not true in all cases.

  248. Ellenor Malik

    encrypt everything to the best of your ability

  249. dwd

    Ellenor Malik, Encryption doesn't solve any problems, though, it just moves problems around.

  250. Daniel

    If the BND can't trust their servers they probably have bigger issues

  251. dwd

    Daniel, Right, that.

  252. dwd

    Daniel, Well. Actually it's not that simple. But they probably trust the server more than the clients at least.

  253. Ellenor Malik

    assuming you can partially trust the endpoints, encryption makes problems smaller

  254. pep.

    Ellenor Malik, "it depends"

  255. pep.

    on the making problems smaller part

  256. Daniel

    Also something something accountability

  257. dwd

    Ellenor Malik, No, I disagree. The BND might not even trust its *users* as much as its server.

  258. lovetox

    what is the idea behind

  259. lovetox

    <conference xmlns='urn:xmpp:bookmarks:1'/> is a valid bookmark?

  260. lovetox

    why would someone publish this, and what should i do with that if i receive it

  261. dwd

    lovetox, The pubsub item id gives you the jid, remember.

  262. lovetox


  263. lovetox

    kk thanks

  264. dwd

    lovetox, So probably quite obvious if you actually see it in the wild.

  265. moparisthebest

    vanitasvitae: (re: a/v) not even an Android phone or any laptop with internet and jitsi meet?

  266. vanitasvitae

    moparisthebest: we could try that, but I doubt it will be as good as Cisco's teleconferencing.

  267. moparisthebest

    WebEx is considered good???? Yikes

  268. vanitasvitae

    We'll see if we come up with something on site :)