XSF Discussion - 2022-07-28


  1. emus

    One question on the MoM from yesterday: What is the topic "Security bounties"?

  2. MattJ

    emus, the possibility that the XSF could have an official bug bounty program ( https://en.wikipedia.org/wiki/Bug_bounty_program ) for security issues in the XMPP protocol and maybe certain software projects

  3. emus

    MattJ: ah then I got it right already. wasnt sure if it really was about bug bounty. I support this!

  4. emus

    Ge0rG: can you repeat the idea to automatically list the CVEs from all xeps? Was it as I stated?

  5. wurstsalat

    I'd help with the website if that's necessary :)

  6. Ge0rG

    I'm not even sure any more what the perceived benefit was

  7. emus

    Ge0rG: well, a clear overview and centralized place to review what happened

  8. emus

    I assume?

  9. Kev

    The only benefit to anyone I see from a page listing CVEs for unrelated XMPP projects is so someone can link to it when they want to say "Look, XMPP software has lots of vulnerabilities", to be perfectly honest.

  10. emus

    I think that would go hand in hand with the bug bounty

  11. Kev

    I'm not arguing against CVEs.

  12. emus

    if we want to track them.as well (which I still think.would be good practice, right?)

  13. Kev

    Do we have any CVEs against the protocol? I admit I didn't realise that was a thing.

  14. emus

    Ge0rG: ?

  15. Ge0rG

    Kev: I'm pretty sure we don't, and I think that's not how CVEs work in general. We've had vulnerable protocols in the past (e.g. compression), but our solution was to deprecate them. We also have protocols that are CVE magnets, notably 0280/0313 and XHTML-IM

  16. Ge0rG

    IMHO the scary <cve> blocks in the XEPs, while technically not part of the protocol specification, are a good trade-off between notifying prospective developers of the challenges and making public how "horrible" our specs are ;)

  17. emus

    Ge0rG: so you also dont want to track them centralized?

  18. Ge0rG

    emus: I don't remember what it would be good for

  19. emus

    Hmm, but as you said, isnt the idea to make such things public and easy to follow? like devs and others can subscribe to such a page for example. each time something pops up they will be notified?

  20. emus

    other opinions?

  21. singpolyma

    There's no practical difference for privacy between owned hardware, leased hardware, and a VM anyway. People in the data centre can get at the server either way

  22. jcbrand

    I think there is a practical difference if you have to physically access the hardware versus accessing data through cloud management software.

  23. Zash

    Virtualization has more attack surface. Bugs in hypervisors or even CPUs do happen.

  24. Ge0rG

    And then the whole speculative fault execution mess

  25. singpolyma

    "cloud management software" = ssh. Full disk encryption does nothing while the server is powered on. I agree about VM attack surface that does sometimes happen

  26. Ge0rG

    singpolyma: how would you extract data from a server that's powered on?

  27. Zash

    I'm not convinced this would weigh much for our purposes tho.

  28. singpolyma

    Ge0rG: oh I see, your argument is that to get in if it's well secured I have to do something that would interrupt operation. Probably true. Though that's true for full disk encryption in other cases too unless a backdoor was preinstalled when they setup for you

  29. Zash

    This very chat runs on a VM. 🤷️

  30. singpolyma

    Anyway, I'm not against people running their own hardware of course, but it's too much work to bother for most full-timers, nevermind volunteers so I think any small trade-offs point heavily to simplifying

  31. Ge0rG

    But the original question was about our mailing lists? Given that "we" are a US based 501c, we can't enforce the GDPR anyway in any reasonable manner, so we could as well rent some cloud service. Maybe there are list operators that are doing this for other (FOSS) communities?

  32. singpolyma

    The mailing lists seem like a simple case? Can run basically anywhere, just need good IP rep or an SMTP relay for deliverability. Or are you meaning to stop running them and use "hosted mailing lists"?

  33. singpolyma

    Yeah. And IIRC they're all mailman2 already so no real benefit to changing that

  34. Ge0rG

    singpolyma: while mailman2 runs on its own, IP reputation doesn't

  35. flow

    isn't mailman2 deprecated, or soon to be?

  36. singpolyma

    Ge0rG: sure, so use an SMTP relay if that's a concern

  37. singpolyma

    flow: dunno. Mailman2 wasn't ready for prime time when I last looked

  38. Zash

    I'm certain I recently saw a post saying mailman3 would break all permalinks... so that seems fun

  39. singpolyma

    mailman2 is the stable one everyone uses. mailman3 is the rewrite

  40. flow

    fedora using mailman3 IIRC

  41. flow

    fedora is using mailman3 IIRC

  42. flow

    but I would be happy if we would use discourse, as I believe we need a central place that brings together developer, protocol architects *and* users

  43. emus

    flow: we have lemmy for a few months

  44. flow

    managing igniterealtime's discourse isntance is pretty low-maintenance

  45. singpolyma

    flow: yes, but it would be a big migration thing to move over to it from the current setup

  46. flow

    there is an alternative to migration

  47. Zash

    "don't" ? :)

  48. flow

    besides, I wouldn't be suprised if somebody hasn't already written a migration tool from mailman to discourse

  49. flow

    Zash, no, freeze and conserve mailman, and then start over

  50. flow

    I would, but last time I suggested discourse, some voices where raised against it

  51. flow

    so the problem is to find a tool that everyone can aggree on

  52. singpolyma

    emus: yes, we're just discussing what software to use for the maillists

  53. flow

    and that's it's terrible to find things there, if you aren't zash

  54. flow

    I think alone the fact that with discourse we could tag every discussion with the related XEPs would be a big win

  55. singpolyma

    Well, "the youth" mostly don't use message boards or email at all anymore, just chat, so MUC is perfect there

  56. emus

    I was suggesting an evaluation of services before deployment but that was not of interest 🤷🏻‍♂️

  57. singpolyma

    Lemmy is a platform for making multiple link aggregation communities

  58. flow

    clearly there are techies out there who don't like the appeal of mailman2 and would be happy to use a web based interface instead

  59. flow

    clearly there are techies out there who don't like the appeal of mailman2 (and mailing lists in general) and would be happy to use a web based interface instead

  60. flow

    clearly there are techies out there who don't like the appeal of mailman2 (and mailing lists in general) and would be happy to use a web-based interface instead

  61. flow

    and by sticking with mailing lists only, we don't reach those

  62. flow

    so it seems only sensible to pick a solution that provides both interfaces, that is, mailing list and web-based, to the discussion

  63. singpolyma

    Sure. I said discourse would be better. But when the discussion started with "how do we make this easier" I think expanding the use case / doing the migration is asking for more work not less. Of course, nothing is up to me and I'll happily abide the decision of those doing the work

  64. flow

    I find it especially appealing that a web-based interface would also help XMPP users to report their issues, which would greatly help us with future protocol design

  65. singpolyma

    flow: you'll just get people whining about their apps that way :P

  66. flow

    and developers struggling with increasing the user experience can be directly directed to protocol architects

  67. flow

    singpolyma, that is right, and another reasons why user reports should happen at the same venue where developers and architects meet

  68. MSavoritias (fae,ve)

    What does matrix have? The chats?

  69. MSavoritias (fae,ve)

    I havent seen discourse being used much by any community that has adopted it personally

  70. MSavoritias (fae,ve)

    People stick to chats or some ticket system like github

  71. Zash

    singpolyma, that what the kids call it these days?

  72. flow

    Zash, hence I wrote "part of"

  73. emus

    flow: having both is not a thing?

  74. singpolyma

    Oh yeah, discord is chat again

  75. flow

    emus, clarify "both" please :)

  76. emus

    Discourse and new mail setup

  77. Zash

    Two mailing lists?

  78. emus

    Zash: or can they run on the same database with different interfaces?

  79. flow

    emus, ideally, discourse is able to replace the mailing lists, so having both would be not an ideal solution, but if it's the only way we can have discourse, then it's better than nothing

  80. singpolyma

    Yeah, two mailing lists seems redundant

  81. singpolyma

    Twice as many emails! ;)

  82. emus

    Ok, I though it can be run as just two interfaces and you just choose mail or discourse

  83. moparisthebest

    yes, but that's just running discourse

  84. mathieui

    MSavoritias (fae,ve): I have seen community adopting discourse to some good level of success, I just stopped interacting with them because discourse is quite bad at replacing a mailing list, but I guess people like it

  85. MSavoritias (fae,ve)

    Wait discourse is supposed to replace a mailing list? Its horrible for that personally. Ui wise and functionality

  86. edhelas

    To me discourse is a no go :p

  87. MSavoritias (fae,ve)

    I thought we were talking about a forum thing

  88. singpolyma

    MSavoritias (fae,ve): if you use it via email UI should be the same

  89. MSavoritias (fae,ve)

    Depends how its done then. In terms of compatibility between the too then

  90. emus

    MSavoritias (fae,ve): we have Lemmy already

  91. MSavoritias (fae,ve)

    Thats my thought too. Discource seems too much effort for little gain

  92. MSavoritias (fae,ve)

    I think lemmy has more chances to attract users to xmpp than a forum

  93. MSavoritias (fae,ve)

    Federation and stuff

  94. flow

    https://lwn.net/Articles/901744/

  95. moparisthebest

    lemmy doesn't do email though

  96. jjrh

    https://discourse.slicer.org/t/using-discourse-as-a-mailing-list/67 looks like you can use discourse as a traditional mailing list

  97. flow

    Oh, I guess I didn't make myself clear, as that is what I was trying to say all the time :)

  98. jjrh

    Only backing up your statement :)

  99. flow

    Discourse provides a web-based interface to the discussion, while addionally providing a mailing list based one

  100. flow

    Arguably the mailing list one is not exactly like mailman's interface

  101. flow

    but I guess it is enough to follow and engage in the conversation via mail

  102. jjrh

    I think the problem with mailing lists is they are increasingly used less by new projects and thus are new to younger people and sometimes intimidating. It also requires one to setup mail filters to avoid having your inbox get flooded.

  103. Zash

    This feels like a thing that could be done with one click if someone at $EmailVendor cared enough to implement it.

  104. jjrh

    Sure, but no one has.

  105. Zash

    This = create folder and a filter rule for email with the current List-Id

  106. benk

    > This = create folder and a filter rule for email with the current List-Id I do this

  107. Zash

    Did you make a button in your email client to do that in a single click?

  108. moparisthebest

    I don't mind mailing lists but ours are totally broken, I know mailman3 has all the knobs to fix them, I don't know if mailman2 does, but discourse does things correctly out of the box

  109. moparisthebest

    and by broken, I mean don't deliver to anyone implementing decade old mail standards

  110. singpolyma

    moparisthebest: that's a mailserver concern

  111. moparisthebest

    singpolyma, no it's not, the mailing list software can't modify bodies

  112. moparisthebest

    well, it can't modify bodies and also send from an email it doesn't own, it has to pick one or the other

  113. singpolyma

    moparisthebest: you mean headers? DKIM doesn't usually secure the body? But yeah, you just add a sender header and can keep everything else the same. Standard practise at any SMTP relay

  114. moparisthebest

    DKIM signs the body, you either have to not modify the body and just add the List-Id header *or* do whatever you want with the body, modify the From, and sign it with your own DKIM key

  115. moparisthebest

    our current mailing lists modify the body and leave the signature causing messages not to be delivered to the majority of recipients

  116. singpolyma

    moparisthebest: you don't have to modify from. You add a sender header and re-sign. Again, standard practise at any competent SMTP relay so don't need special support in the mailing list software

  117. moparisthebest

    quick search has everyone configuring mailman for it so https://nanoy.fr/post/dkim-and-mailman3/ https://wiki.list.org/DEV/DKIM

  118. moparisthebest

    but that's fine, just pointing out our current solution doesn't work well

  119. singpolyma

    Sure, they're probably not using a relay and just using vanilla postfix or something

  120. singpolyma

    But yeah, managing an outgoing mailserver is a thing. It's not impossible, but if we want to reduce work then outsourcing *that* is probably a good move

  121. singpolyma

    Mailgun or someone normal that does this all day long

  122. singpolyma

    Keep inbound with a vanilla mailserver because rep and such aren't an issue for inbound, probably

  123. root

    I am kind of walking into this conversation halfway through (read up the last roughly 120 messages) so I may be a little lost on what's happening, but is the current idea(s) to move infrastructure (website, mail, chats,?) to something different? How are things set up currently? What is the aim, exactly? I gather obviously something that requires less maintenance by the XSF, but also encourages engagement? What am I missing?

  124. Kev

    The mail server's on old hardware that needs replacing. That's the fundamental desire.

  125. moparisthebest

    if I understand correctly, the current infrastructure is super ancient and can't be upgraded, and also lives in a bunker where we may or may not be able to contact hands there to fix things if they go wrong, so the conversation is really 2 independent decisions: 1. new hardware there or elsewhere, or "the cloud", or whatever 2. what to do with mailing lists

  126. Kev

    From my PoV, the bunker's treated us very well, hasn't given us any significant issues, and there's no reason to move away from it for its own sake.

  127. Kev

    There may be reasons to do something that isn't the bunker, but not because it's not the bunker.

  128. Zash

    Nothing says we have to have everything in the same place.

  129. Zash

    We already don't.

  130. Kev

    Indeed.

  131. root

    Ok. On discourse, can't really say I have used it much, but to me as a user where I have seen it implemented, and tried to use it, it was a PIA, didn't help that ad/script blockers hate it too. But to me it felt scetchy trying to make contact with the site's team/community, most often I just left and didn't return. Perhaps some of those issues are mine, as well the sites I saw using them were not Foss communities.

  132. moparisthebest

    root, so you were trying to use it in the browser as a forum and not as a mailing list ?

  133. root

    moparisthebest: that is correct. I did not know until today it had that functionality, but I have never researched either, so take my opinion with a grain of salt.