Was anyone here around during the JSF days? I'm trying to get a sense of how its mission was different from the XSFs since my understanding is that it was more software focused
pulkomandyhas left
pulkomandyhas joined
amnesiahas joined
Kev
Sam Whited: Very few people who're still active. Alex, Edwin, Ralph. Me just about. Not sure about Dave, but I suspect not.
Kev
Peter, obviously.
Kev
I've probably forgotten someone, but it's that sort of number of people, I think.
Sam Whited
Kev: thanks, I'll reach out to them directly
Ge0rG
Sam Whited: are you going to make a history write-up? That'd be very interesting
pulkomandyhas left
Sam Whited
Ge0rG: I wasn't planning on it, but that would be fun if I learn anything interesting
Ge0rG
As somebody who is very interested in having a JSF 2.0 of sorts today, I'm probably too biased to do such a thing.
amnesiahas left
Sam Whited
Ge0rG: I've been vaguely thinking about that which is why I asked. I'd like to have something like Apache but for XMPP projects. Something that can act as a fiscal sponsor to help projects raise money, provide a common set of guidelines and dev practices and infrastructure for stuff under its umbrella, etc. but before I ask people what they'd want out of it I figured I'd see what existed before. I'm also not convinced that there is enough interest in XMPP in general to even make it possible, but you never know. Anyways, just doing very preliminary research.
Wojtekhas joined
jonas’
Sam Whited, you should attend board meetings more often
jonas’
also maybe become a member again so that you see what’s going on on members@
Sam Whited
jonas’: I still don't see the point of being a member of the XSF.
jonas’
so that you get a say on that matter
Ge0rG
Sam Whited: nobody is _against_ creating such an organization, but the XSF isn't it, and looks like so far nobody had the resources to actually start it.
Sam Whited
Ge0rG: right, that's why I was thinking about doing it separate from the XSF.
jonas’
you’re most definitely not the first one with that thought
Ge0rG
I think that the XSF (and XMPP overall) would vastly benefit from having it, though.
Sam Whited
yah, probably not
Sam Whited
jonas’: a say in what matter?
jonas’
Sam Whited, the direction of the XSF and how funds are used.
Sam Whited
jonas’: I don't think this should be the XSF, they should be two separate organizations.
jonas’
MattJ, cc @ you, I think you brought something like that up in one of the more recent board meetings, too ^
jonas’
Sam Whited, yes, and I think such an organisation should have its roots in the XMPP and XSF communities
Sam Whited
jonas’: I agree, but like I said, this is just me doing some preliminary research.
pep.
!
jonas’
I’m saying there’s already efforts in that direction and I suggest you join them. the more the better.
MattJ
I bring it up all the time
pep.
I'm also interested fwiw
MattJ
to anyone who will listen, or who thinks the XSF is capable of doing all the things people want it to do :)
pep.
"jonas’> Sam Whited, yes, and I think such an organisation should have its roots in the XMPP and XSF communities", I agree
pulkomandyhas joined
MattJ
Well it's unlikely to have its roots in the Matrix community, I agree :)
pep.
No but it could be perceived as a "FU the XSF, it doesn't work, we're doing our own thing"
MattJ
I almost thing, so what if it is? (which is unlikely if you're up-front about the goals)✎
MattJ
I almost think, so what if it is? (which is unlikely if you're up-front about the goals) ✏
MattJ
Modern XMPP also has/had that risk
MattJ
Even the name and domain :)
Ge0rG
I'm pretty sure it won't, because the XSF is very clear about its razor-sharp focus on Protocol.
MattJ
(XSF should register legacyxmpp.org on 1st April)
Ge0rG
MattJ: you could do it right now.
MattJ
Oh look, that's tomorrow
asterixhas left
MattJ
Must finish my MAM update in time
asterixhas joined
Sam Whited
I kind of forgot about modern XMPP, I'm glad to see this exists. I like the goal of providing docs and UI/UX guidelines and what not.
Ge0rG
MattJ: because you want it to appear on the Humorous track?
asterixhas left
asterixhas joined
pulkomandyhas left
MattJ
With DNS-over-XMPP on the Standards Track and MAM on the Humorous track we'll be good
amnesiahas joined
asterixhas left
asterixhas joined
MattJ
Hmm, I wonder how many libraries/clients would get tripped up by an iq type='get' in one namespace, and the result having a payload with a different namespace
seems like the easiest thing to do would be to match based on ID then just decode whatever is in the result, and I would assume most people would do the easiest thing and it wouldn't cause problems
Ge0rG
MattJ: you'd be surprised how many implementations ignore the xmlns altogether
flow
well it does
flow
if you only match on the id, then you are potentially open to spoofed replies
asterixhas left
MattJ
You match on (jid, id) though
asterixhas joined
Zash
and type
Zash
(jid, id, type=(result|error))
Ge0rG
Monal won't work on my account because I have a Cisco user on my roster who has a Cisco-namespaced <presence> element inside the jabber:client <presence> element
jonas’
or have a sufficiently unpredictable ID :)
pep.
I'm just patching our minidom implementation in Rust to force namespaces everywhere. It's just not possible to retrieve an element without specifying a namespace, unless you loop over everything all the time
flow
and even (jid, id) is not that trivial as it seems, since there could be multiple values for jid
flow
including, in some cases, nil
jonas’
don’t get me started on the ambiguity of an absent @to/@from on stanzas
flow
so you may simply want to generate "good" IDs and be done…
Sam Whited
Why would there be multiple values for JID? Do you just mean the server being the domain or the empty attribute?
jonas’
Sam Whited, that’s not what empty attribute means
Zash
jonas’, when is it ambigous?
jonas’
absent attribute refers to your *account*, not to the server domain.
Sam Whited
oh right, that one. Is that what you menat?
jonas’
yes
jonas’
Zash, you can’t simply match on the verbatim string, you have to take into account your currently bound-to JID after resource binding, since some servers will always do one thing (present or absent attribute) even if you always send present/absent
Sam Whited
yah, that's irritating. I just have my library normalize that on all incoming stanzas
jonas’
so you have to, in your processing loop, alias empty jid to locally bound bare JID, which is annoying to do
jonas’
I recall having issues with normalising that actually
Ge0rG
jonas’: nothing wrong with empty @from/@to... Until you send a message to yourself and the Carbon copy you receive doesn't have one of those set, but it means a different thing ;)
Zash
Just don't find the text that suggests that empty to/from is different from the bare account jid.
flow
jonas’, do you remember which issues you had exactly?
jonas’
(also, of course it requires the stanza broker to know your local JID, because we all hate self-contained things)
jonas’
I’ll have to check the git log
Sam Whited
What is a "stanza broker"?
jonas’
Sam Whited, the thing which takes the stanzas from the XML stream and hands it to handlers
jonas’
I think it’s called mux in mellium
Sam Whited
Oh, that's not what does the noramlization in my case (I don't think, if it does it shouldn't be, I can't remember)
Sam Whited
The session (or connection) knows your JID, and whenever any tokens are read from it it can normalize them
jonas’
my point is that there’s *no* layer which should need to know about your locally bound JID in the stanza processing pipeline
Ge0rG
Sam Whited: are you also normalizing <forwarded> stanzas? :D
Sam Whited
Ge0rG: I don't remember how that works, but those are wrapped in an actual stanza, no? I should probably look, if not I'm probably breaking something there
jonas’
flow, possibly the normalisation issues were purely in aioxmpp
Ge0rG
Sam Whited: yes they are, but they are also <message/> stanzas and there are no guarantees whatsoever on them having @from/@to set correctly
Sam Whited
Ge0rG: I don't do any automatic handling at all of those right now, my library is a bit low-level for that. If a package was ever written to handle them, it would have to do its own normalization to remain self contained.
Zash
I like to think of it as stanzas inheriting the logical to/from of the parent stream.
Zash
After resource binding one could think of those as from=full jid to=bare jid
Ge0rG
Zash: that's the logical thing indeed, except that for some people it's not obvious that you have a stream to your account.
jonas’
Zash, however, as a client, you set @to to the domain, not to the bare account JID✎
jonas’
Zash, however, as a client, you set stream:stream/@to to the domain, not to the bare account JID ✏
Zash
jonas’: Imagine that it changes during resource binding
rionhas left
rionhas joined
jonas’
that does make no sense to me
Zash
I kinda wish resource binding was a stream restart thing
jonas’
changing on SASL, that’d make sense, because that actually binds you to a JID✎
jonas’
changing on SASL, that’d make sense, because that actually binds you to a bare JID of some kind ✏
debaclehas joined
Zash
Drop the resource binding iq hack, server tells you to/from in the post-sasl restart
jonas’
that’d be kind of sexy, except that the client speaks first on stream resets
Zash
Myeah
Zash
+ SASL2 gets rid of the stream restart
Zash
Tho you could just drop the to/from that the client sends. The server knows who you are after auth and it knows who you authed to.
Zash
And by drop I mean the server ignores it.
asterixhas left
Sam Whited
I'm always torn about the restarts. On the one hand, they're logical and they're probably good from a security perspective. On the other hand, the entire connection process takes forever on a crappy network and anything we can do to speed that up makes me happy.
asterixhas joined
Zash
I did something like that in an experimental CBOR protocol once. No stream restarts, just a message that updates top-level properties like to/from
jonas’
I don’t even know what stream restarts are supposed to do. the @to is only interesting for client->server really pre-STARTTLS as an SNI-surrogate
jonas’
aren’t they?
flow
jonas’, rumar is that they are supposed to reset the xml parser state✎
flow
jonas’, rumor is that they are supposed to reset the xml parser state ✏
Zash
and thus throw away auth related state that might linger
asterixhas left
Zash
which is why it's weird to me that SASL2 drops the restart
jonas’
flow, ah, that makes sense
asterixhas joined
jonas’
I’ll probably forget that again, but it *does* make sense
pulkomandyhas left
MattJ
Pretty sure there have been protocol security problems in the past that didn't apply to XMPP because we do restarts
pulkomandyhas joined
Zash
Also older SASL mechanisms can negotiate encryption and stuff, which requires a clear point where it's activated.
flow
I think it's not that bad to have them
flow
not sure about the motivation to drop them in sasl2 though
Kev
You need a stream restart after integrity is negotiated.
Kev
Both starttls and SASL can negotiate integrity, I think.
jonas’
Kev, see, that argument I don’t get
amnesiahas left
Zash
Never seen it used in SASL tho, only seen the traces of it in DIGEST-MD5
jonas’
I can see the argument that you want to throw away an XMPP parser/serialiser after having done auth with it, or that you don’t want to keep an XML pipeline hooked up to a stream potentially in the middle of a TLS handshake. But I don’t get that integrity argument
Sam Whitedrealizes that as we speak I am extremely far behind on my phone because the connection got dropped and on this crappy mobile network it takes ages to be re-established.
Sam Whited
I'm always confused when I walk up to my laptop and there's a ton of new messages I hadn't seen.
paulhas left
tskhas left
Kev
jonas’: Because if you assume pre-integrity that things might have been injected into the stream, people could have mangled your to/from and stream id, as well as injecting things into your XML parser.
jonas’
right, so to/from/stream id are 100% irrelevant, aren’t they?
Kev
So you're potentially doing authorisation based on injected data.
Kev
I don't believe they are, no.
jonas’
you authenticate the server with TLS/SASL, likewise for the client.
jonas’
I never saw the stream ID used for anything
paulhas joined
Zash
It's used in dialback
asterixhas left
asterixhas joined
jonas’
that’s more interesting
asterixhas left
asterixhas joined
jonas’
(maybe my view is too client-centric?)
Kev
I think it might be :)
jonas’
but clients are most hurt by stream restarts either way
Zash
Didn't the non-SASL auth also use the stream id?
Zash
> SHA1-encrypted
Hmmm
Zash
> SHA1(concat(sid, password))
Zash
Obsoleted nearly 12 years ago? Why do we still ship code for this?
Zash
Altho I fondly remember typing https://xmpp.org/extensions/xep-0078.html#example-3 into a telnet console once upon a time
moparisthebest
I think it should be brought back, just the PLAIN though, and only over TLS of course
moparisthebest
if it's good enough for HTTP why not XMPP
Zash
eugh
moparisthebest
SASL made sense before TLS was mandatory, I don't really think it brings any advantages nowadays though
Zash
This notion makes me sad
moparisthebest
unless you see "complexity" or "not being able to upgrade ever" as an advantage
moparisthebest
are there actual advantages to SASL ?
lovetox
you mean SASL SCRAM?
Kev
There's an advantage to having a choice of mechanisms, if that's the question. And once you've got a choice of mechanisms, why not use SASL.
lovetox
yeah there is more than sasl scram
lovetox
you need a protocol to tell the server how you are going to auth
lovetox
may it be via 2FA or external via client cert or even PLAIN
Zash
"good enough for http", but the web uses a lot of OAuth and stuff that only works if you're a browser
moparisthebest
client cert can be handled at the TLS layer, 2FA can just be a token appended to your password which makes it the same as PLAIN
moparisthebest
fair re: oauth ugh
Zash
Also, I sure hope you're not making the argument that popular == good
asterixhas left
asterixhas joined
pulkomandyhas left
pulkomandyhas joined
paulhas left
paulhas joined
dendanghas left
dendanghas joined
moparisthebest
no, I'm arguing that PLAIN user+pass is "good enough" and KISS and sasl-scram and friends is needless complexity for no gain
dendanghas left
dendanghas joined
dendanghas left
dendanghas joined
asterixhas left
asterixhas joined
asterixhas left
asterixhas joined
lovetox
i agree about sasl scram over tls is probably not very useful
lovetox
but not about getting rid of extendable protocol that can define any kind of auth mechanism
Ge0rG
it's useful because you don't need to store the password on the client
Zash
or on the server
Zash
or send it over the wire
Zash
even if TLS helps there
Sam Whited
More useful than not having an upgrade path if SHA-1 gets broken?
Zash
and it's cheap to verify for the server, even if you did a billion rounds of PBKDF2
Zash
Does this exact discussion with these exact words get repeated every couple of months?
Sam Whited
Unrelated: but is Apache Vysper still being developed? Randomly wound up on its Git page and there are a bunch of recent commits by names I don't recognize. That is suprising
yah, they're not wrong, it's not easy to find. Good to know.
Zash
Looks like they did a bunch of stuff last year
SouL
Hmm, is it a XMPP server?
Zash
Yes
SouL
I thought it had something different to it (a reason to make it active again that other XMPP servers do not have or something)
asterixhas left
asterixhas joined
lovetox
moparisthebest, fyi you cant do the full client cert spec without sasl
lovetox
a cert could be valid for more than one account
lovetox
so you need a way to tell the server the account you want to auth with
lovetox
don't know though if anyone does that
asterixhas left
asterixhas joined
moparisthebest
Ge0rG, and how is not storing the password on the client useful?
moparisthebest
your xmpp account password should already only be used for xmpp, so if someone has access to your account, it doesn't really matter if they have the password or not
jonas’
moparisthebest, that’s a pretty strong "should" there
jonas’
first: user reality begs to differ. second: single-sign-on systems *do* exist.
moparisthebest
should be a MUST , we need to stop catering to idiots
moparisthebest
if someone uses "password" or "mustang1" across all their accounts, it doesn't really matter that the xmpp client doesn't store it locally
jonas’
if someone uses "7GvdunCpiwkUKty9dj3/u8l5" for their company single-sign-on which also has an XMPP client, it does matter though✎
jonas’
if someone uses "7GvdunCpiwkUKty9dj3/u8l5" for their company single-sign-on which also has an XMPP service, it does matter though ✏
Zash
Uh in those cases you can't use SCRAM anyways since you need to send that password in plain text to some validation service.
asterixhas left
asterixhas joined
asterixhas left
asterixhas joined
jonas’
shush
Zash
... unless it's some OAuth-derivative thing
asterixhas left
asterixhas joined
alexishas left
sonnyhas joined
asterixhas left
asterixhas joined
moparisthebest
jonas’, does it? cause their browser stores it in plaintext in that case, also probably outlook
asterixhas left
asterixhas joined
pulkomandyhas left
pulkomandyhas joined
Martinhas left
asterixhas left
asterixhas joined
Martinhas joined
Martinhas left
Martinhas joined
pulkomandyhas left
pulkomandyhas joined
Martinhas left
Martinhas joined
jonas’
moparisthebest, "others are bad, let’s also be bad"
Martinhas left
Zash
burning coal works just fine, let's do more of that!
Martinhas joined
moparisthebest
jonas’, yep, if it provides no benefit in any case and brings complexity, let's not bother
moparisthebest
so far we've established it's useless if it's unique to the xmpp account, or in the case of single sign on, where is it useful then?
jonas’
I don’t agree with your assessment of the SSO situation