jdev - 2020-05-19

  1. Wojtek

    tbh I don't know (personally) anyone that uses Slack so it is (was?) definitelly not geared towards them. personal opinion - for me using `@` just *feels* natural

  2. MattJ

    The good thing about 372 is that people can choose clients (or configure) what feels natural for them, rather than having "competing" highlight styles

  3. jonas’

    Link Mauve, slack, and discord and various other platforms, to be fair

  4. Link Mauve

    jonas’, sure, I just won’t list them all every time. :p

  5. jonas’


  6. jonas’

    PSA to all implementors: - In SASL PLAIN, the client must not call SASLprep on the auth data (username, password). This is the server’s job. (RFC 4616 §2: https://tools.ietf.org/html/rfc4616 ) - In SCRAM, the client MUST call SASLprep on the password (RFC 5802 §2) and SHOULD call it on the username while allowing for unassigned codepoints (RFC 5802 §5.1). The server MUST call SASLprep on the username (RFC 5802 §5.1). It is the server’s responsibility to ensure that PLAIN data is properly SASLprep’d if PLAIN is offered together with SCRAM.

  7. jonas’

    this was discussed in prosody@, apparently we’ve got quite a few implementations which diverge from this behaviour.

  8. Ge0rG

    it'll be big fun to get out of this mess again

  9. flow

    jonas’, is there an issue if the client saslprep's when using plain?

  10. jonas’

    flow, if the backend on the server is for example a PHP user database with hashes which doesn’t SASLprep

  11. flow

    woudn't such a setup prevent sasl mechs that require client-side sasl prep?

  12. jonas’

    yes, but also for other reasons

  13. jonas’

    flow, you wouldn’t offer SCRAM then, because you don’t have the required server side data in that case

  14. jonas’

    only PLAIN

  15. Ge0rG

    I suppose that a server now needs to perform password checks on both the prepped and the unprepped value?

  16. jonas’

    I don’t think this is truly an issue for *most* deployments. I expect the deployments which implement SCRAM to do it right (but I may of course be wrong with that) and I expect issues only when PLAIN is involved

  17. jonas’

    e.g. when authenticating with PLAIN against a SCRAM store

  18. jonas’

    but that needs to be evaluated

  19. jonas’

    aaaand I was proven wrong

  20. jonas’


  21. Guus

    Some download stats of the previous release of Openfire in the release notes of the latest release, at https://discourse.igniterealtime.org/t/openfire-4-5-2-is-released for those interested in weird stats. Also, we did a new release.

  22. Martin

    >openfire_4_5_1_x64.exe 15170 oO

  23. Guus

    Yeah, the userbase is Windows-heavy. I have no idea how much of these are individual downloads, scripted, etc, etc.

  24. Zash

    99.99999999% of downloads these days seem to be CI systems that download the world for each run

  25. Zash

    Top 1 downloader of Prosody is our CI

  26. Zash

    Reeeeeeally need to make it push based instead of having it poll constantly

  27. jonas’

    odd causalities (and casualties). Our discussion about what’s valid in nodeprep / the domainpart of JIDs spilled over to #powerdns, and people started playing around and then https://docs.powerdns.com/recursor/security-advisories/powerdns-advisory-2020-02.html happened

  28. Zash