XSF Discussion - 2019-06-21


  1. Ge0rG

    What do you send to your user's client when blocking a JID?

  2. Ge0rG

    goffi: nice idea on list with the "Social" Compliance Suite category. Could you make a PR with the suggested XEPs against 0412 on my repository fork?

  3. goffi

    Ge0rG: I'll try, but I'm overwhelmed, so I can guanranty when. Please ping me if I haven't done it in a couple of days.

  4. Ge0rG

    goffi: I don't know about the involved XEPs. Do you still need XHTML-IM? I fear I'll just forget about the whole thing in a week or two.

  5. Ge0rG

    Amt you can't just open issues on the XSF repository because the editors don't like that

  6. Ge0rG

    And I fear you can't open issues on my fork, which would've been a good reminder

  7. goffi

    XEP-0412 is draft, so I guess we can't modify it anymore, it should be next year suite

  8. goffi

    I'll open a ticket on my bug tracker as a reminder

  9. Ge0rG

    As I somehow ended up as the shepherd of Compliance Suite, I'm the one responsible for forking it into a new proto XEP, unless Council decides on a new way to do things

  10. Ge0rG

    goffi: but if you provide the delta against 0412, I'll move it over to the new one.

  11. goffi

    Ge0rG: alright, I've made a ticket to our tracker as a reminder (https://bugs.goffi.org/bugs/view/307), so I wont forget. I'll do that when I find some time :)

  12. Ge0rG

    goffi: 👍

  13. pep.

    https://github.com/xsf/xmpp.org/pull/577 Somebody to review/merge this plz? :)

  14. pep.

    who manages the dresden meetup? Meetup it can be added here: https://xmpp.org/community/events.html

  15. pep.

    who manages the dresden meetup? Maybe it can be added here: https://xmpp.org/community/events.html

  16. j.r

    pep.: I could do it

  17. pep.

    Thanks

  18. j.r

    pep., done https://github.com/xsf/xmpp.org/pull/579

  19. pep.

    j.r, can you remove your second change

  20. pep.

    I just fixed it

  21. pep.

    small atomic commits :)

  22. j.r

    pep., I did a second change?

  23. pep.

    https://github.com/xsf/xmpp.org/pull/579/files

  24. pep.

    rebase on master

  25. j.r

    Yeah my fork seems to be a bit outdated

  26. j.r

    Ok will delete the PR and do it again

  27. pep.

    No need to delete

  28. pep.

    push force on your branch, that will update the PR

  29. pep.

    (or just push, if there's no need to force)

  30. j.r

    pep., yeah I remebered this way to do after delete xD

  31. j.r

    But here we go: https://github.com/xsf/xmpp.org/pull/580

  32. pep.

    Thanks

  33. pep.

    Guus, ^, one more! :)

  34. j.r

    > Guus, ^, one more! :) What?

  35. pep.

    I don't have merge powers

  36. j.r

    Ah ok

  37. j.r

    Oh ok

  38. pep.

    I'm organising a sprint in Lyon, we'll fix the dates end of the week: https://wiki.xmpp.org/web/Sprints/2019_July_Lyon, poke me if you interested

  39. edhelas

    I had a really interesting remark by a user, he wanted to make the password policy more strict in Movim, I was wondering if we could no do that on a XMPP level. For example create a small XEP to ask the clients to at least set passwords that have 8 characters minimum + letters/numbers…

  40. edhelas

    it's simply a guideline and server wise the user can still set a "1234" password, but at least most of our users will set something a bit stronger

  41. pep.

    You can have a server policy for sure, that's an implementation detail

  42. moparisthebest

    that's also something that changes constantly

  43. moparisthebest

    and XMPP/SASL has password schemes where the server doesn't know the password right?

  44. moparisthebest

    can't enforce length or complexity requirements if you don't know it

  45. moparisthebest

    lastly that 'letters + numbers' is outdated, current best practice is simply length I'm pretty sure? "pass phrases" instead of "passwords" ?

  46. Guus

    Correct horse battery staple

  47. Ge0rG

    edhelas: simple policy can be easily mapped to a small XEP (number of letters, number of digits, etc). If you want arbitrary rules, you are into Turing Complete language territory...

  48. moparisthebest

    "good password policy" is already defined by plenty of people though, NIST, PCI standards etc etc

  49. Ge0rG

    moparisthebest: then it can be implemented directly in all clients. Problem solved

  50. pep.

    "number of letters, number of digits, ..", I so wish services would stop doing that, and also restricting password length to 30, or 20, or 8, because.. as if they didn't use password hashes, that's scary