-
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
-
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
-
jonas’
Link Mauve, slack, and discord and various other platforms, to be fair
-
Link Mauve
jonas’, sure, I just won’t list them all every time. :p
-
jonas’
fair
-
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.
-
jonas’
this was discussed in prosody@, apparently we’ve got quite a few implementations which diverge from this behaviour.
-
Ge0rG
it'll be big fun to get out of this mess again
-
flow
jonas’, is there an issue if the client saslprep's when using plain?
-
jonas’
flow, if the backend on the server is for example a PHP user database with hashes which doesn’t SASLprep
-
flow
woudn't such a setup prevent sasl mechs that require client-side sasl prep?
-
jonas’
yes, but also for other reasons
-
jonas’
flow, you wouldn’t offer SCRAM then, because you don’t have the required server side data in that case
-
jonas’
only PLAIN
-
Ge0rG
I suppose that a server now needs to perform password checks on both the prepped and the unprepped value?
-
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
-
jonas’
e.g. when authenticating with PLAIN against a SCRAM store
-
jonas’
but that needs to be evaluated
-
jonas’
aaaand I was proven wrong
-
jonas’
yikes
-
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.
-
Martin
>openfire_4_5_1_x64.exe 15170 oO
-
Guus
Yeah, the userbase is Windows-heavy. I have no idea how much of these are individual downloads, scripted, etc, etc.
-
Zash
99.99999999% of downloads these days seem to be CI systems that download the world for each run
-
Zash
Top 1 downloader of Prosody is our CI
-
Zash
Reeeeeeally need to make it push based instead of having it poll constantly
-
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
-
Zash
fun