jdev - 2020-05-19

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

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

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

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

fair

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.

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

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

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

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

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

yes, but also for other reasons

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

only PLAIN

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

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

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

but that needs to be evaluated

aaaand I was proven wrong

yikes

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.

>openfire_4_5_1_x64.exe 15170 oO

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

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

Top 1 downloader of Prosody is our CI

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

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

fun