Sam WhitedWhile testing my server implementation I just realized that bind is broken because I always match the feature being selected by the namespace but bind does its magic IQ stuff. Does everyone else just special case this? I really have no good idea how to handle this in a sane/general way.
ZashProsody used to special-case pre-binding IQs, explicitly excempting by namespace and stuff. Now it treats them as stream elements until after resource binding.
Sam WhitedWhat does it mean to treat them as stream elements? Does that mean in theory the bind IQ could be sent at any time during the negotiation process?
ZashAnd then there's a bit of special dispatch for {default namespace}iq, but they're not iq stanzas as far as routing is considered
Sam Whitedoh, gotcha
Sam WhitedYah, I don't start IQ handling at all until after the session is negotiated so they're not actually treated as IQs, but I guess I'll have to special case "if you get <iq/> pass that to the bind handler" instead of just relying on namespace
Sam WhitedI hate having a magical special case in there though
ZashYeah, I wasn't a fan of having resource binding or IBR special-cased so early in routing.
ZashAlso why I'd like to move away from such iq-looking things.
Sam WhitedOh is IBR special too? I didn't remember that, I'll have to go re-read that one
ZashI don't remember
ZashHm, could be that it was only binding that was special, since it happens after authentication
Sam Whitedhmmm, well, I don't want to deal with that one right now (or possibly ever) so I may just say "if you get an IQ, pass it to the bind handler" to start and ignore IBR until someone complains
Beherithas left
Beherithas joined
kikuchiyohas left
ZashSo the change in Prosody was in when <{jabber:client}iq> becomes a stanza, as opposed to a stream element (.... nonza). Before it was at authentication, now it's at resource binding.
kikuchiyohas joined
adityaborikarhas left
ZashThis makes sense to me since you need a resource for routing.
adityaborikarhas joined
Sam WhitedI don't understand the distinction
Sam WhitedOr how it could be at authentication since it's always used for resource binding?
ZashThere's a period in the life of a session between authentication suceeding and resource binding
ZashWhat happens if you try to send a message before resource binding?
Sam WhitedOh, I don't actually have handlers for messages or anything at that point so it would just think there was no such feature and say that "jabber:client message isn't an advertised stream feature" or something
Sam WhitedBut that makes sense if you're already handling messages and IQs and what not, which I guess technically I should be since I think in theory you could send them to the server before negotiation is complete
goffihas left
goffihas joined
COM8has joined
florettahas left
COM8has left
lovetoxhas joined
florettahas joined
Beherithas left
lovetoxhas left
Beherithas joined
ZashDoes anyone have a client supporting XEP-0440 and `tls-server-end-point` ?
lovetoxhas joined
flowZash, if you provide a server implementation then I would be very tempted to provide the client side implementation
lovetoxhas left
frankhas left
Beherithas left
Beherithas joined
Zashflow: I've got an initial WIP where you need to supply the cert hash yourself, wondering if I should publish as-is or wait for library support for getting the hash to use to get it.
frankhas joined
marchas left
marchas joined
ZashOh dear, dual RSA/EC cert setups are going to cause pain.
flowZash, with your current approach, where teh cert hash is externally supplied, I assume?
ZashWith the next step of the WIP where it tries to hash the configured certificate. Which is already a blocker because it doesn't know what hash function the cert is signed with, and you're supposed to use the same if it's better than sha-256
Zashflow: Not specifically, more in general. Prosody doesn't support it anyways.
Beherithas left
ZashAnd in the TLS offloading proxy setup where it makes sense to do with a configured cert hash, certificate rollovers will be fun.
marchas left
moparisthebestcert hash or key hash? basically things should only use key hash ever imho
flowZash, yep, in TLS offloading setups this may be more pain than gain
Zashmoparisthebest, I'd actually like to have (maybe even write) a channel binding thing that says "use the SPKI as-is"
moparisthebestoh, channel binding, that's probably fine, I should read first
moparisthebestyea that'd be neat, match up with DANE well (and maybe we can do HPKP for XMPP one day...)
ZashOr drop certificates and use raw public keys!
ZashOf course that's never going to happen. Can't actually have nice things.
moparisthebestI swear there used to be a TLS mode that did that
ZashRaw public keys? Yeah.
moparisthebestI assume it was dropped with TLS 1.3
Zashhttps://tools.ietf.org/html/rfc7250
ZashOnly the web can have nice things.
jonnjhas left
Beherithas joined
marchas joined
jonnjhas joined
Sam WhitedMaybe if you get an IQ instead of the expected thing to start a stream feature it should check the payload and use its namespace to determine which stream feature to select. That seems more general purpose. If the stream feature isn't bind and you somehow get a client sending <iq><sasl> or something, the thing that parses it will just not support the IQ and will fail, so whomever wrote the stream feature implementation could decide whether to support IQs or not (probably just bind, but I dunno, maybe someone wants some other legacy feature that uses IQs at some point)
Sam WhitedThat seems vaguely more general purpose than just special casing bind, even though I doubt it's very useful.
adityaborikarhas left
kikuchiyohas left
kikuchiyohas joined
adityaborikarhas joined
Alexhas left
Alexhas joined
o2has left
o2has joined
lovetoxhas joined
jonnjhas left
oibaloshas left
oibaloshas joined
ZashEvent based architecture, dispatch on top level {xmlns}name, hook {jabber:client}iq and further dispatch on the iq payload {xmlns}name. Not exactly how it works in Prosody but sorta.
ZashAnd something something session state in (unauthed → unbound → ready) or somesuch