moparisthebest, to me, at least one canonical way to discover QUIC connectivity (e.g. SRV records) would seem sensible
konstantinoshas left
Kevhas left
Fishbowlerhas left
Fishbowlerhas joined
msavoritiashas left
Samhas left
msavoritiashas joined
msavoritiashas left
msavoritiashas joined
adiaholichas joined
wurstsalathas joined
djorzhas left
atomicwatchhas joined
Kevhas joined
adiaholichas left
djorzhas joined
rionhas joined
adiaholichas joined
Samhas joined
nikhilmwarrierhas joined
Kevhas left
neshtaxmpphas left
neshtaxmpphas joined
adiaholichas left
florettahas left
adiaholichas joined
Fishbowlerhas left
Fishbowlerhas joined
lskdjfhas joined
marchas joined
djorzhas left
Maranda_has joined
florettahas joined
Fishbowlerhas left
Fishbowlerhas joined
stphas joined
qwestionhas joined
djorzhas joined
chipmnkhas joined
Andrzejhas joined
chipmnkhas left
nikhilmwarrierhas left
nikhilmwarrierhas joined
qwestionhas left
florettahas left
florettahas joined
Alexhas joined
SteveFhas joined
adiaholichas left
Maranda_has left
Kevhas joined
stphas left
djorzhas left
adiaholichas joined
stphas joined
qwestionhas joined
Andrzejhas left
djorzhas joined
beanhas joined
adiaholichas left
marchas left
Maskugatigerhas joined
marchas joined
marchas left
emushas left
konstantinoshas joined
djorzhas left
adiaholichas joined
Tobiashas left
Tobiashas joined
qwestionhas left
marchas joined
adiaholichas left
debaclehas left
adiaholichas joined
florettahas left
stphas left
stphas joined
adiaholichas left
Maskugatigerhas left
Tim Rhas joined
karoshihas left
msavoritiashas left
thndrbvrhas left
thndrbvrhas joined
adiaholichas joined
karoshihas joined
վարյաhas left
վարյաhas joined
florettahas joined
adiaholichas left
msavoritiashas joined
xnamedhas joined
florettahas left
qwestionhas joined
Samhas left
sbachhas left
sbachhas joined
qwestionhas left
sbachhas left
sbachhas joined
sbachhas left
sbachhas joined
neshtaxmpphas left
neshtaxmpphas joined
qwestionhas joined
msavoritiashas left
Wojtekhas joined
qwestionhas left
emushas joined
harry837374884has left
adiaholichas joined
harry837374884has joined
msavoritiashas joined
qwestionhas joined
gooyahas joined
florettahas joined
adiaholichas left
Samhas joined
adiaholichas joined
qwestionhas left
վարյաhas left
վարյաhas joined
qwestionhas joined
qwestionhas left
debaclehas joined
konstantinoshas left
Samhas left
karoshihas left
qwestionhas joined
nikhilmwarrierhas left
nikhilmwarrierhas joined
Steve Killehas left
Steve Killehas joined
Steve Killehas left
Steve Killehas joined
vanitasvitaehas left
qwestionhas left
Steve Killehas left
Steve Killehas joined
qwestionhas joined
qwestionhas left
qwestionhas joined
Steve Killehas left
Steve Killehas joined
qwestionhas left
menelhas left
վարյաhas left
վարյաhas joined
restive_monkhas joined
qwestionhas joined
sbachhas left
sbachhas joined
qwestionhas left
qwestionhas joined
qwestionhas left
qwestionhas joined
qwestionhas left
lovetoxhas left
karoshihas joined
qwestionhas joined
konstantinoshas joined
qwestionhas left
harry837374884has left
Dele Olajidehas joined
lovetoxhas joined
qwestionhas joined
qwestionhas left
harry837374884has joined
menelhas joined
neshtaxmpphas left
neshtaxmpphas joined
antranigvhas joined
lovetoxhas left
adiaholichas left
vanitasvitaehas joined
lovetoxhas joined
adiaholichas joined
msavoritiashas left
adiaholichas left
menelhas left
menelhas joined
florettahas left
Samhas joined
adiaholichas joined
Fishbowlerhas left
adiaholichas left
qwestionhas joined
Fishbowlerhas joined
SteveFhas left
SteveFhas joined
antranigvhas left
SteveFhas left
SteveFhas joined
antranigvhas joined
Steve Killehas left
Steve Killehas joined
Steve Killehas left
Steve Killehas joined
վարյաhas left
վարյաhas joined
qwestionhas left
florettahas joined
Samhas left
Samhas joined
msavoritiashas joined
vanitasvitaehas left
Wojtekhas left
msavoritiashas left
qwestionhas joined
Wojtekhas joined
neshtaxmpphas left
neshtaxmpphas joined
chipmnkhas joined
nikhilmwarrierhas left
qwestionhas left
qwestionhas joined
qwestionhas left
qwestionhas joined
sbachhas left
sbachhas joined
sbachhas left
sbachhas joined
adiaholichas joined
qwestionhas left
qwestionhas joined
adiaholichas left
wgreenhousehas left
Vidakhas left
qwestionhas left
qwestionhas joined
wgreenhousehas joined
adiaholichas joined
vanitasvitaehas joined
qwestionhas left
theonepinghas joined
pablohas joined
theonepinghas left
adiaholichas left
qwestionhas joined
qwestionhas left
վարյաhas left
վարյաhas joined
qwestionhas joined
moparisthebest
because the canonical way will be in (hopefully) xep-0156
konstantinoshas left
pablohas left
Zash
> is there precedent
Like, the core RFC defining both the TCP binding and the SRV discovery method?
qwestionhas left
menelhas left
moparisthebest
no, the opposite, *not* defining port binding or discovery, just saying "that's defined in $other-xep"
menelhas joined
restive_monkhas left
antranigvhas left
antranigvhas joined
sbachhas left
sbachhas joined
qwestionhas joined
raghavgururajanhas joined
վարյաhas left
վարյաhas joined
nikhilmwarrierhas joined
restive_monkhas joined
Mx2has left
antranigvhas left
antranigvhas joined
harry837374884has left
neshtaxmpphas left
neshtaxmpphas joined
eevvoorhas left
antranigvhas left
qwestionhas left
eevvoorhas joined
antranigvhas joined
harry837374884has joined
msavoritiashas joined
Calvinhas joined
konstantinoshas joined
antranigvhas left
Samhas left
Dele Olajidehas left
adiaholichas joined
Samhas joined
Mx2has joined
վարյաhas left
վարյաhas joined
neshtaxmpphas left
chipmnkhas left
chipmnkhas joined
neshtaxmpphas joined
Samhas left
Samhas joined
վարյաhas left
վարյաhas joined
antranigvhas joined
restive_monkhas left
jinxdhas joined
antranigvhas left
Paganinihas joined
rebeld22has joined
վարյաhas left
վարյաhas joined
sbachhas left
sbachhas joined
msavoritiashas left
neshtaxmpphas left
neshtaxmpphas joined
raghavgururajanhas left
restive_monkhas joined
antranigvhas joined
antranigvhas left
վարյաhas left
վարյաhas joined
raghavgururajanhas joined
antranigvhas joined
վարյաhas left
վարյաhas joined
վարյաhas left
վարյաhas joined
msavoritiashas joined
konstantinoshas left
nikhilmwarrierhas left
adiaholichas left
restive_monkhas left
adiaholichas joined
Vidakhas joined
msavoritiashas left
Titihas left
atomicwatchhas left
atomicwatchhas joined
Samhas left
վարյաhas left
վարյաhas joined
Samhas joined
nikhilmwarrierhas joined
Thilo Molitorhas left
Thilo Molitorhas joined
karoshihas left
karoshihas joined
moparisthebest
very interesting XMPP vuln in Zoom's implementation https://bugs.chromium.org/p/project-zero/issues/detail?id=2254
karoshihas left
Samhas left
sbachhas left
sbachhas joined
karoshihas joined
sbachhas left
sbachhas joined
konstantinoshas joined
Samhas joined
restive_monkhas joined
pablohas joined
adiaholichas left
florettahas left
Samhas left
Samhas joined
konstantinoshas left
adiaholichas joined
restive_monkhas left
msavoritiashas joined
emus
moparisthebest: is that something that should have attention from our side?
florettahas joined
sbachhas left
sbachhas joined
Samhas left
pablohas left
vanitasvitae
The XML parser stuff might be interesting
vanitasvitae
As the stanza smuggling attack could also be used on other clients
vanitasvitae
/servers
Samhas joined
flow
It appears that Gloox rolled much of its Unicode and XML parsing code itself, which makes such vulnerabilities more likely. Not using existing libs may be fine if you target constraint low-end embedded devices. But the Zoom client typically runs on none of those
vanitasvitae
Ah, I thought gloox was an XML parser lib, not an XMPP client library :D
vanitasvitae
Well, apparently its both :P
flow
If we want to spin the story away from "XMPP is so complicated because it uses Unicode and XML, hence there are such security issues", then we should point out that there are robust, sound, and battle tested libraries for the heavy-lifting of the low-level stuff, which, if used, make such issues much less likely
flow
In fact the Project Zero report even mentions (and praises) ejabberd for its validation
antranigvhas left
pablohas joined
antranigvhas joined
restive_monkhas joined
djorzhas joined
derdanielhas joined
adiaholichas left
colemanhas left
antranigvhas left
antranigvhas joined
adiaholichas joined
derdaniel
moparisthebest: am I remembering this correctly that you had some quic to xmpp c2s termination proxy thing?
derdanielhas left
Danielhas joined
moparisthebest
flow, idk seems like most of our vulns have been *because* of using existing XML libs that support way-more-than-XMPP-needs
Daniel
A found it. Never mind
moparisthebest
yep https://github.com/moparisthebest/xmpp-proxy
Sam
> Client messages are sent over the same stream connection as control messages from the server.
This specifically interests me and is something I've thought about separating in the past. Maybe multiplexed quic streams could do this as an additional separation if security
antranigvhas left
xeckshas left
xeckshas joined
sbachhas left
sbachhas joined
Daniel
Maybe that's a naive question but would we use raw quic or rather something bosh over HTTP/3?
jonas’
the former
jonas’
use QUIC as a modern replacement for TCP+TLS
jonas’
don't stuff HTTP in there, that's just needless overhead
moparisthebest
I think ^ until websockets-over-http3 is standardized and then we can use that to evade the evil firewalls
jonas’
aaand here I'm sad again
moparisthebest
what's sad about that? a client tries to connect all the ways, it'd probably prefer plain QUIC, but if blocked, go to other methods?
jonas’
I'd rather have clients take a pickaxe and smash that firewall to pieces
jonas’
*ahem*
moparisthebest
I can't disagree with that
jonas’
also, all the good technology going to waste just because some idiot firewalls
moparisthebest
*but* XMPP has to *just work* like Signal does, users are uninterested with long explanations about how they should talk to their network administrator
jonas’
so much damage for nothing
jonas’
see, I'll rather clean the kitchen than continuing to think about this
moparisthebest
I'm curious to see if QUIC/http3 itself will actually ever make it through firewalls
Daniel
So what are the bits (roughly) that a xep would have to specify?
moparisthebest
I reckon a ton of networks currently block UDP on port 443
jonas’
moparisthebest, google will make it happen, one way or another
jonas’
"hey enterprise, you're using gmail corporate, right? well it will stop working if you don't allowlist udp 443"
debaclehas left
debaclehas joined
moparisthebest
Daniel, honestly hardly anything, tl;dr "connect and validate cert like TLS, use bi-directional streams only, each stream is treated as already authenticated as the cert implies, open as many as you want for 'different connections', use connection roaming if you can </eof>"
antranigvhas joined
djorzhas left
moparisthebest
in some future where google has ensured UDP on 443 always works we could recommend not using stream-management but I think we are far off there (for when you are disconnected and can only connect back over TCP+TLS)
Daniel
So there wouldn't be any type of a stanza is a frame or something like that? (asking as someone who doesn't know what a frame is)
Steve Killehas left
moparisthebest
nope, to application code it's identical to a TCP stream
nikhilmwarrierhas left
moparisthebest
there are other types of "transports" you can use under a QUIC session but I think they are uninteresting for XMPP, there are one-way streams for instance
Daniel
ok. i thought that maybe 'frames' could take over some part of stream managment acks or so
Dele Olajidehas joined
restive_monkhas left
Zash
My instinct would be that those are orthogonal things at different layers.
that's the other thing you can do besides bi-directional and uni-directional streams
moparisthebest
but it's basically sending a UDP packet, un-ordered, no guarantees on delivery, must be "small enough"
moparisthebest
Daniel, after tying up some loose ends and writing the XEPs I plan to try to expose xmpp-proxy as a java library and make it take over for Conversation's network code, giving it the ability to do QUIC and Websockets all in one go, no idea how this will work out though :)
moparisthebest
it sounds like one of those things that is easier said than done
Steve Killehas joined
Dele Olajidehas left
Dele Olajidehas joined
Dele Olajidehas left
Dele Olajidehas joined
debaclehas left
florettahas left
neshtaxmpphas left
neshtaxmpphas joined
restive_monkhas joined
flow
Daniel, I'd expect XMPP over QUIC feels just like XMPP over TCP+TLS
flow
so instead of a TlsSocket where you shove raw bytes into and read from, you have a QuickSocket
flow
you'd still want to use stream mangement, even if QUIC provides this functionality already, if you want to be able to resume a stream over a different transport mechanism
moparisthebest
yep ^
flow
of course you could re-use QUIC resumption is your transport stays QUIC during a connectivity change
moparisthebest
so do we know of any XMPP clients that use gloox ? or that parse ascii vs UTF-8 ? seems like this attack is generic in that way
Daniel
> so instead of a TlsSocket where you shove raw bytes into and read from, you have a QuickSocket
That's what I initially hoped but the existing Java quic libraries make this all look a little bit more complex than that
jinxdhas left
flow
isn't there just one QUIC library for java?
moparisthebest
you have to be careful searching for them, old ones say QUIC but mean HTTP3 because that's what it was before it was re-named
flow
moparisthebest, fwiw, these are the reverse dependencies of gloox that ::gentoo nows: https://qa-reports.gentoo.org/output/genrdeps/rindex/net-libs/gloox
adiaholichas left
flow
you could probably do a similar search for e.g. debian packages
restive_monkhas left
djorzhas joined
Daniel
> isn't there just one QUIC library for java?
flow: maybe? Which one are you talking about?
Dele Olajidehas left
adiaholichas joined
moparisthebest
hmm gloox hasn't had an update since 2020, wonder if it's still developed or if they were given a heads up, will see if the JID works :)
debaclehas joined
flow
https://github.com/ptrd/kwik
Dele Olajidehas joined
Tim Rhas left
Tim Rhas joined
Tim Rhas left
moparisthebest
> The TLS library used by Kwik is also "home made"
moparisthebest
hard pass
Wojtekhas left
karoshihas left
krauqhas left
xnamedhas left
Zash
> it's encrypted and secured by TLS (not as a separate layer, but embedded in the protocol)
AIUI you can't use existing TLS libraries as-is unless they have QUIC support
adiaholichas left
marchas left
adiaholichas joined
xnamedhas joined
moparisthebest
right, but all the maintained ones have that by now
colemanhas joined
moparisthebest
Kwik literally says not to use it for security sensitive things, yet it's a TLS replacement, footgun much
jgarthas left
marchas joined
Alex
Memberbot is online for our Q2 2022 elections.
restive_monkhas joined
sbachhas left
sbachhas joined
sbachhas left
sbachhas joined
adiaholichas left
pep.
Gloox is used by renga, on haiku
pep.
^ pulkomandy
pep.
Dunno if he's here or just jdev
moparisthebest
thanks pep. , joined their muc and let them know
Samhas left
adiaholichas joined
moparisthebest
gloox dev's JID is alive, no response yet, I'll say in here if I get one
stpeterhas joined
debaclehas left
Samhas joined
xnamedhas left
xnamedhas joined
msavoritiashas left
florettahas joined
Samhas left
krauqhas joined
jinxdhas joined
adiaholichas left
neshtaxmpphas left
adiaholichas joined
neshtaxmpphas joined
Samhas joined
konstantinoshas joined
msavoritiashas joined
neshtaxmpphas left
neshtaxmpphas joined
Tim Rhas joined
flow
moparisthebest, what exactly did you ask gloox's dev?
moparisthebest
> hi! I got your JID from the gloox website, wondered if you were made aware of a recent vulnerability found in gloox or not? https://bugs.chromium.org/p/project-zero/issues/detail?id=2254
karoshihas joined
flow
I'd somehow assume that he is aware of this. I wonder if gloox being gpl even suggests that zoom bought a license from him
flow
or if they used gloox under the GPL, which means free zoom source for everyone!!!
now of course, the question is if kwik is portable and runs on android
colemanhas left
colemanhas joined
moparisthebest
Daniel: please pay attention to "Kwik implemented it's own TLS lib and should not be used" from it's readme
raghavgururajanhas left
Daniel
Yes I saw that. I have no plans on using that
flow
yep, that was just to show that quic client libraries provide a stream abstraction of the quic transport
moparisthebest
Cool, easy to miss, scares me they don't put that up top :/
moparisthebest
I'll soon see how much of a nightmare interfacing rust and Java/Android is in practice :'(
stpeter
Wow, is Jakob Schröter still maintaining gloox? He's been working on that for ages.
xnamedhas left
flow
he certainly has
stpeter
I mean, we had a commercial license for it at JINC circa 2004 (IIRC).
moparisthebest
You can tell it's been ages because he uses SVN :)
stpeter
heh
moparisthebest
Could be CVS I guess
Kev
> I'd somehow assume that he is aware of this. I wonder if gloox being gpl even suggests that zoom bought a license from him
I know Jakob selling licenses was a thing, I would assume Zoom did (shame they didn't pick Swiften :D)
*IM*has left
Kev
Ah, Peter got here before me.
lovetoxhas joined
stpeterwaves to Kev
marchas left
Kevwaves back
moparisthebest
Kev: what does swiften use for parsing XML?
moparisthebest
Seems like this class of bug could be rather widespread
moparisthebest
I mean hopefully no XMPP clients are downloading and running software but the impersonation aspect
Kev
Expat or libxml2 at user's choice.
Kev
libxml2 being the better choice.
Kev
s/user's choice/dev's choice/
harry837374884has left
marchas joined
Dele Olajidehas left
harry837374884has joined
moparisthebest
Would be interesting to do an inventory of all the various XML parsers and see if any parse differently like this
flow
Kev, why libxml2 >> Expat?
moparisthebest
And by interesting I mean I would enjoy reading someone else's summary because that seems like an absolutely massive amount of work :D
papatutuwawahas joined
adiaholichas left
sbachhas left
sbachhas joined
sbachhas left
sbachhas joined
adiaholichas joined
Ingolfhas left
adiaholichas left
Ingolfhas joined
Tobiashas left
Tobiashas joined
Andrzejhas joined
Tobiashas left
Tobiashas joined
Tobiashas left
Tobiashas joined
Dele Olajidehas joined
antranigvhas left
harry837374884has left
harry837374884has joined
Andrzejhas left
Tim Rhas left
Kev
flow: I honestly don't remember why I think that :D
djorzhas left
florettahas left
Tobiashas left
Tobiashas joined
antranigvhas joined
stpeterhas left
Samhas left
Tim Rhas joined
Samhas joined
adiaholichas joined
chipmnkhas left
chipmnkhas joined
antranigvhas left
antranigvhas joined
antranigvhas left
antranigvhas joined
Tobiashas left
Tobiashas joined
moparisthebest
oh, that's also an expat bug (reported, was it fixed?) and a bug in ejabberd's fast_xml, fun stuff
what are we looking at? anything I should watch out for in rxml? dino doesn't have sufficient scrollback and I am too tired to open my poezio shell and scroll.
moparisthebest
jonas’, about, 3 or 4 XML-specific bugs not counting the zoom RCE from https://bugs.chromium.org/p/project-zero/issues/detail?id=2254
moparisthebest
and yes re: rxml, basically does it parse these the same way expat does, what does it do in the face of utf-8 nonsense etc
moparisthebest
in english the bug is roughly "can you pass a single stanza through a server that a client interprets as more-than-one stanza"
moparisthebest
if so, since the server isn't checking the inner one, you can spoof literally anything to the client
emus
*Those are the accepted contributors for the XSF!!!*
*A warm welcome again Patiga and Pawbud! *
*I will communicated via our channels soon! Are there any annotations here?*
Patiga: More flexibility in dino file transfers
Resource-wise, messenger applications tend to be on the lightweight side of the spectrum. This drastically changes when file transfers are added to the equation. File transfers can introduce arbitrary more resource-usage, both on network and data storage aspects. To alleviate this issue, stateless file sharing empowers the user to make informed decisions on which files to load.
Deliverables
• Unified handling of http and jingle (peer-to-peer) file transfers
• Enable sending metadata alongside files
• Thumbnail previews for images
https://summerofcode.withgoogle.com/programs/2022/projects/z9ixHTWZ
Pawbud: Adding support for Audio/Video Communication via Jingle
The idea is to add support for Audio & Video communication through the Jingle protocol. The goal is to create a Converse plugin that adds the ability to make one-on-one audio/video calls from Converse. The audio/video calls will be compatible with other XMPP clients.
https://summerofcode.withgoogle.com/programs/2022/projects/0nRwZN19
jonas’
moparisthebest, well, rxml uses rust strings, and as I don't have any unsafe { from_utf8_unchecked(..) } in there, I should be golden on the UTF-8 front I think.
adiaholichas left
adiaholichas joined
moparisthebest
I suspect so also
jonas’
oh god
jonas’
the gloox/expat mixture there is explosive, and a nice find
jonas’
meanwhile, people complaining that rxml refuses <?xml-stylesheet ..?>
konstantinoshas left
mhhas left
Zash
muh nice-looking atom feeds!
moparisthebest
I'm pretty much completely convinced at this point that using generic XML libraries for XMPP is a giant mistake
jonas’
said the one dissecting XMPP streams with .find() ;P
jonas’
(which is just barely better)
moparisthebest
I agree, I just think it's better than pulling in expat, rxml didn't exist at that point :P
junaidhas joined
jonas’
may 11 vs. apr 14, you win, but only barely
sbachhas left
sbachhas joined
mhhas joined
sbachhas left
moparisthebest
besides, mine sits in between the server and the client, so I've got parsers on both ends, it doesn't actually matter if I forward crap :D
sbachhas joined
Zash
Wouldn't .find([<>]) be sensitive to broken half of UTF-8 sequences messing with it?
jonas’
Zash, uhhhh
jonas’
iiiinteresting
antranigvhas left
jonas’
though that'd then drop dead on the real parsers on the other end (if it's not gloox, apparently. or expat?)
Zash
which was what I gathered from that Zoom issue
jonas’
and another point in moparisthebest's favour is that initially, rxml had its own utf8 decoder, which wasn't just slow but also a source of errors (most of which *probably* have been found by fuzzing, but you never know)✎
jonas’
and another point in moparisthebest's favour is that initially, rxml had its own utf8 decoder, which wasn't just slow but also a source of errors (most of which *probably* had eventually been found by fuzzing, but you never know) ✏
moparisthebest
that scared me and is why I didn't consider using it originally, but now you said that's gone, and I just haven't went back and looked again yet
konstantinoshas joined
moparisthebest
I'd only be using it for websocket <-> regular xmpp conversions, the only other thing I use find() for is extracting the target domain from <stream to= which even ejabberd doesn't use a proper XML parser on, it's fine :D
florettahas joined
moparisthebest
otherwise it doesn't parse any XML, that's the whole point even
jonas’
doesn't it do that to enforce stanza size limits?
Half-Shothas left
homebeachhas left
Matthewhas left
uhoreghas left
Half-Shothas joined
Matthewhas joined
homebeachhas joined
uhoreghas joined
xnamedhas joined
Tobiashas left
Tobiashas joined
moparisthebest
no, it enforces stanza size limits without parsing XML
jonas’
it counts delimiters, which for me counts as parsing XML
moparisthebest
it spits out whole stanzas at a time, that may or may not be valid XML, but they are complete stanzas under the specified length limit
adiaholichas left
mhhas left
djorzhas joined
moparisthebest
it's only counting, forward-only (never backtracking), not allocating ever, and stops at a pre-defined limit, I know these are famous last words but I don't think it could ever be vulnerable to anything :)
jonas’
fun fact: a bug in the depth counting in aioxmpp led to a viable remote stanza smuggling attack :)
karoshihas joined
moparisthebest
but that's an XML parser no? this is "here is a byte slice, if it's valid XML it's a whole stanza, not a partial one, have fun"
jonas’
that was actually after the xml parser
konstantinoshas left
jonas’
just counting startelement/endelement can be surprisingly tricky
the point is you can then use a dom parser, so it's basically like websocket then, you don't need a SAX parser to tell you when a stanza begins/ends
moparisthebest
websocket also says "here is a byte slice, if it's valid XML it's a whole stanza, not a partial one, have fun"
mhhas joined
Tobiashas left
Tobiashas joined
adiaholichas left
Dele Olajidehas left
adiaholichas joined
flow
moparisthebest, at leat someone will look at the libraries. if everyone uses their own implemention, then bugs will propably go unnoticed forever. Note that I was mentally excluding all C/C++ kind of libaries. I am not sure if any network facing application should ever use those, especially clients, but proably also server applications
sernickhas joined
moparisthebest
How many years have people looked at expat, how many CVEs in the last year
moparisthebest
But yes I agree in general that well tested XMPP-specific libraries in sane languages should be used widely
jonas’
I haven't yet seen anything like rxml in other languages
jonas’
maybe I should see if I can make a C interface for it?
flow
while I don't see the need for XMPP specific XML and Unicode libraries, I am happy that we can at least aggree that code should be well-tested
flow
that said, I wouldn't mind if XML parsers had different module like "XMPP restricted"
djorzhas left
flow
I know the evil unrestricted code would be still there, and depending on the paranoia level, this will bother some
marchas left
marchas joined
Samhas left
atomicwatchhas left
Yagizahas left
harry837374884has left
Samhas joined
sernickhas left
moparisthebest
C devs, the theory: I know how to manage my own memory, I won't write unsafe code
atomicwatchhas joined
moparisthebest
C devs, the practice: 85% of security vulnerabilites are unsafe memory management
moparisthebest
XMPP devs, the theory: I know how to properly configure expat/my XML lib
moparisthebest
XMPP devs, the practice: 85% of security vulnerabilities are mis-configured expat (ok I made up this % but I bet it's close :P)
Half-Shothas left
homebeachhas left
Matthewhas left
uhoreghas left
Half-Shothas joined
Matthewhas joined
homebeachhas joined
uhoreghas joined
flow
Well, no, I actually believe first-time XMPP devs will often just grab the XML parser and be happy that it works
flow
So we do have a similar situation here as we have with XHTML-IM: people just use the first tool that comes to their mind, and are happy that it works
flow
that said, I believe software, especially libraries should be as restrictive as possible per default, and "explode" if the boundaries of the restrictions are crossed
flow
then people can decide if they want to relax the restrictions
lovetox
so lets deprecate xml parsers
lovetox
every developer needs to write his own from now on
flow
I don't see how XML libraries specialized for XMPP would help, in fact, I fear that this would further fragment the software ecosystem
moparisthebest
flow, would you call prosody and ejabberd developers "first-time devs" ? because both have had misconfigured-expat bugs in the last few months
restive_monkhas left
flow
but, again, I wouldn't mind XML parser being restrictive by default and providing specialized modes
moparisthebest
we can keep pretending like it won't ever happen again but we all know it will
flow
moparisthebest, well, I did not claim that expert users do not run into this
moparisthebest
it's not the fault of any of these devs by the way, it's impossible to sanely configure a beast like that
flow
that statement strikes me as an exaggeration
flow
but that may be because I am happy with my Java parsers :)
moparisthebest
ok, let's revisit it if we can go a year without expat problems, let me know :P
flow
(java xml parser exploit in Smack in 5, 4, 3, 2, …✎
flow
(java xml parser exploit in Smack in 5, 4, 3, 2, …) ✏
flow
sure, but I wonder if libxml2 isn't really the go to C(/C++) XML parser
jonas’
isn't expat the only SAX-capable C/C++ XML parser?
debaclehas joined
flow
hmm there is also Xerces
flow
which claims to be SAX
jonas’
which is even more exotic to me than expat fwiw
jonas’
(also mind that expat is backing python's xml module)
flow
dunno, i've heard and stumbled over xerces in a few places
jonas’
first time I recall hearing about it
harry837374884has joined
flow
yeah, but I think it's the java flavor of xerces
flow
xerces-c doesn't seem to have that much traction: https://github.com/apache/xerces-c/graphs/contributors
So, listen, I've just had a completely novel and crazy idea.
How about we use something other than XML?
I've heard great things about YAML...
flow
cap'n'proto ftw
sbachhas left
sbachhas joined
adiaholichas left
moparisthebest
wow, this is worse than I thought, it's simple math really, let's guess which has more bugs:
moparisthebest
$ ./scc libxml2/
───────────────────────────────────────────────────────────────────────────────
Language Files Lines Blanks Comments Code Complexity
───────────────────────────────────────────────────────────────────────────────
C 107 279146 24353 46516 208277 55075
C Header 66 16451 1547 4402 10502 308
moparisthebest
expat:
C Header 23 3464 331 1545 1588 40
C 22 29409 2162 2838 24409 4621
moparisthebest
rxml:
Rust 25 16202 757 1944 13501 444
moparisthebest
it's *absolutely astounding* that libxml2 has 10x the C code that expat does holy hell
jonas’
well, expat doesn't have a DOM, does it. nor does it do xslt or xpath.
moparisthebest
wonder how it factors code complexity cause each one is a few orders of magnitude off haha
moparisthebest
jonas’, challenge: expat-compatible API for rxml, just no-op all the configuration functions :D
djorzhas joined
jonas’
moparisthebest, I have that on my todo, actually, but only for lua-expat :)
Fishbowlerhas left
Fishbowlerhas joined
restive_monkhas joined
neshtaxmpphas left
neshtaxmpphas joined
restive_monkhas left
atomicwatchhas left
moparisthebest
flow, xerces:
Java 832 260492 31434 86353 142705 30512
almost as many lines as libxml2 but 8x the files, god bless java
nuronhas left
emus
Welcome our Google Summer of Code contributors!
- Patiga will work on more flexible file transfers in #Dino https://summerofcode.withgoogle.com/programs/2022/projects/z9ixHTWZ
- PawBud will work towards adding support for A/V #communication via #Jingle in #ConverseJS https://summerofcode.withgoogle.com/programs/2022/projects/0nRwZN19
#XMPP #GSoC #Google #Standards
https://fosstodon.org/web/@xmpp/108358826402429966
https://twitter.com/xmpp/status/1529199174729728000
nuronhas joined
Tim Rhas left
rebeld22
emus: No one wants to work for Google.
davidhas joined
davidhas left
jonas’
rebeld22, excuse me what?
jonas’
that's not exactly "welcoming"
davidhas joined
davidhas left
wgreenhousehas left
archas joined
papatutuwawahas left
rebeld22
jonas’: Sorry, but what you mean?
wgreenhousehas joined
emus
I assume it's time to say good night! 👻️
thndrbvrhas left
thndrbvrhas joined
Samhas left
restive_monkhas joined
Samhas joined
atomicwatchhas joined
msavoritiashas left
adiaholichas joined
adiaholichas left
Dele Olajidehas joined
beanhas left
djorzhas left
Samhas left
djorzhas joined
Samhas joined
Kevhas left
restive_monkhas left
Kevhas joined
Kevhas left
Kevhas joined
emus
I'm in my bed already, but if someone volunteers to guide the user that unspecified asks for help below the Fosstodon tweet - that would be really great! 🙏❤