moparisthebestwhen confronted with a too-big stanza as a server, what would the implications be if the server just silently dropped the stanza and carried on instead of terminating the stream with an error ?
moparisthebestmaybe this answer is different for s2s vs c2s
jonas’moparisthebest, if it can do that, it should instead bounce the stanza properly
jonas’then there are no (new) implications, beyond what you already get when servers make decisions about which stanzas to deliver
moparisthebestwhat if it can drop it, but can't parse it
jonas’unlikely, I think
jonas’to bounce a stanza, you only need the startElement SAX event
jonas’I think you already need that + endElement + magic to determine the stanza boundaries anyway
jonas’I guess dropping would be similar to s2s-closing (without stream management), so there’s not much of a difference there, except that deliverability of other stanzas will be improved (as they don’t get lost in s2s TCP buffers when the stream is killed)
moparisthebestI'm determining stanza boundaries by counting tags and don't have an XML parser
jonas’how are you counting tags?
jonas’(to count tags, you already need something like an XML parser ;))
jonas’enough of an XML parser to add only a shim layer to extract the attributes out of the tags anyway✎
jonas’enough of an XML parser to add only a shim layer to extract the attributes out of the attributes needed for bouncing anyway ✏
moparisthebestroughly, incrementing on < and decrementing on /> or </ so a stanza boundary is when the counter hits 0
jonas’<![CDATA[ < ]]>?
moparisthebesthopefully no one sends that :D seems to have worked so far
jonas’it is valid though
jonas’and: what stops you from catching the slice from the first < to the first > and parsing that as attributes? you can drop all namespace-related stuff as that’s not needed on stanzas anyway, just plain key/value
moparisthebesthrm maybe, so you think that'd be valid? sending an error response on too-big-stanzas and just skipping them otherwise? but not terminating the stream?
jonas’<policy-violation/> would be an appropriate stanza error I think
jonas’look at that, policy-violation has stanza size limit as an example
jonas’oh, that’s the stream error, sorry
moparisthebestantranigv in this MUC has an avatar that makes a stanza bigger than 262,144 bytes for instance
jonas’but I think the stanza error is as valid
jonas’and bouncing individual stanzas with whatever errors you feel like is the right of a server; clients need to cope with that
jonas’dropping on the other hand is tricky because it may be seen as violation of the "MUST reply to IQ requests" clause of RFC 6120
flow> moparisthebest> antranigv in this MUC has an avatar that makes a stanza bigger than 262,144 bytes for instance
One of the reasons that make me believe that servers should be very conservative about the sizes of stanzas they accept. Someting in the range of 10 KiB to 64 KiB seems appropriate
flowI also think that with larger stanza sizes you get easily into scheduling issues, as in, a single stanza can dominate the link while it is transferred
flowThis is turn means, that you should probably bounce to big stanzas at the first hop, and close the stream on all following hops as soon as the limit is reached✎
flowThis is turn means, that you should probably bounce too big stanzas at the first hop, and close the stream on all following hops as soon as the limit is reached ✏
jonas’good point about hogging the link
flowUnfortunately, I believe that the major parts of the ecosystem would break if we do that
flowBut I really hope that we get the ecosystem towards a reasonable sized stanza limit in the future
flowOf course, this requires, things like RSM on disco#(info|item) responses✎
flowOf course, this requires things like RSM on disco#(info|item) responses ✏
jonas’servers already do that :(
dwdI wonder if MAM-like responses on disco might make more sense. Or additional sense.
flowFurthermore, if we talk about techniques that split large content into multiple stanzas, then we have to be aware that it's not easy for the generating entity to assess the resulting stanza size
jonas’just found this https://github.com/horazont/muchopper/commit/7affc581a8539eebc190371d95539bed1fb8bd7c#diff-6d5dca6e6e9b9db00d48d0bb6b748f7302f6b941e4bcee48427a54ff74122c46R48✎
jonas’just found this https://github.com/horazont/muchopper/commit/7affc581a8539eebc190371d95539bed1fb8bd7c#diff-6d5dca6e6e9b9db00d48d0bb6b748f7302f6b941e4bcee48427a54ff74122c46R53-R59 ✏
flowBut probably a pramgatic approach like, "aim for 10KiB stanzas, but limit at 32KiB" is good enough here
flowjonas’, is https://github.com/horazont/muchopper/commit/7affc581a8539eebc190371d95539bed1fb8bd7c#diff-6d5dca6e6e9b9db00d48d0bb6b748f7302f6b941e4bcee48427a54ff74122c46R53 fixed today?
jonas’I did not check again since that commit
moparisthebestit's ok I'm 99% sure I found an ejabberd bug while looking at this too, are `<features xmlns="http://etherx.jabber.org/streams"><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"><required/></starttls></features>` and `<stream:features><starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"><required/></starttls></stream:features>` the same or not?
moparisthebestprosody, dino, gajim, and conversations are ok with either, ejabberd requires the second
jonas’they are the same in XML 1.0 with Namespaces
jonas’but yeah, ejabberd is picky
moparisthebestodd failure mode too, it just hangs for 90 seconds and then sends `<stream:error><connection-timeout xmlns='urn:ietf:params:xml:ns:xmpp-streams'/><text xml:lang='en' xmlns='urn:ietf:params:xml:ns:xmpp-streams'>Idle connection</text></stream:error>` and hangs up
jonas’yep, probably the parser doesn’t read it as belonging to the stream namespace and then drops it
jonas’moparisthebest, but note the interop note in https://tools.ietf.org/html/rfc6120#section-4.8.5
jonas’> Implementations are advised that using a prefix other than 'stream' for the stream namespace might result in interoperability problems.
flowmoparisthebest, sounds like you have a new(?) project, what is it? :)
moparisthebestflow, reverse proxy https://github.com/moparisthebest/xmpp-proxy still super early, just started dogfooding it on my server recently :)
flowmoparisthebest, so you are competing with dwd now? :)
dwdCompetition always welcome.
dwdEspecially as I've not had any time for Metre recently.
jonas’I think metre doesn’t do c2s, does it?
dwdIt does not, no.
dwdGoing to go out on a limb and suggest that xmpp-proxy doesn't do S2S, it's just a connection proxy, too.
moparisthebesthttps://github.com/surevine/Metre ? quite a bit different I guess
moparisthebestxmpp-proxy does c2s and s2s, and multiplexes both along with starttls + direct tls all on the same port(s), but also limits stanza sizes
dwdBut inbound only if I follow this right?
moparisthebestcorrect, inbound only, and provides TLS
dwdAnd that StanzaFilter looks scary. :-)
KevHow does it cope with presenting the client cert to the server?
KevOr is there a ‘I have verified trust, just do external’ flag being passed to the server-proper somehow?
dwdKev, Yeah, doesn't seem to be any support for that.
KevProbably more applicable to C2S where client certs are uncommon than to S2S then, I guess?
moparisthebestno support for client cert auth, server just trusts connections from it is encrypted implicitly (also for the PROXY header)
KevAlthough I guess it probably gets in the way of -PLUS too?
dwdIt'd break channel bindings, yes. Also I think the start-tls handling makes me cry.
moparisthebestyes I agree the StanzaFilter is scary haha
moparisthebestthese are all correct reactions I think
KevI keep getting tempted to write one of these for M-Link, but I keep deciding it needs to be more than a naive proxy because of the interactions between TLS and auth.
Kev(Also because I’d like to use it as a mechanism for seamless upgrades).
moparisthebest(personal opinion for my use-cases only incoming) interactions between TLS and auth are dead, let them lie
dwdFunnily enough, I thought about adapting the Metre code into an Openfire C2S connection manager.
dwdmoparisthebest, I think that's not true given channel bindings especially.
moparisthebestdo they work with TLS 1.3 yet ?
Kevmoparisthebest: You might not like channel binding, but surely you’re not opposed to S2S strong auth?
dwdmoparisthebest, Thanks to Sam, yes.
moparisthebestwill they work with QUIC
dwdmoparisthebest, Your xmpp-proxy doesn't work with QUIC, so somewhat irrelevant, but I think they should given they're simply based on an exported key.
moparisthebestunfortunately if the web doesn't use them, we can't rely on them being supported anywhere
dwdmoparisthebest, Except key exports *are* used and seem well supported, so Sam's approach seems much more likely to be generally available.
moparisthebestand QUIC is the future so I wouldn't call it irrelevant, still a hair early though, we'll see
dwdmoparisthebest, Sure. I expect we'll have XMPP over QUIC at some point. But I don't think key exporting is affected by QUIC versus TLS/TCP, so everything should "just work".
dwdmoparisthebest, Obviously there's very much a place for xmpp-proxy as a bridge to uplift existing servers and services with QUIC etc support though.
jonas’moparisthebest, so that effectively forces use of dialback? or what?
dwdmoparisthebest, I think your StanzaFilter works for idiomatic XMPP XML, but I'm not entirely sure it'll work correctly in some edge cases. I suspect if I'm sufficiently abusive I can at least sneak a closing stream tag past it.
jonas’I’ll just say CDATA
dwdjonas’, Oh, yeah, good point, that too.
moparisthebestalso '< stream:stream' and a few other things, probably ok, it accomplishes it's goal
dwdmoparisthebest, And '<str:stream', and all sorts. Likely it'll work in all non-abusive cases. But yeah, I can get it to terminate the session without the XMPP server thinking its over, and I can get the XMPP server to close it without xmpp-proxy to work. And any server advertising -PLUS basically won't allow auth. Hopefully. But as I say, it'll mostly work and it's a useful tool for a number of cases.
Kevdwd: The server needs to know there’s a TLS terminator in the way anyway, so presumably should not present any auth mechs that don’t proxy in any case.
moparisthebestyep I agree, it was written in a bit of a hurry for one specific use-case which it accomplishes, I'll elaborate more later, and in the meanwhile think about if it can support CDATA sanely without bringing in an XML parser :/
KevI would be inclined to bring in an XML parser, personally.
KevWell, let me rephrase that.
KevIf I wanted this to be generally useful, I would bring in an XML parser.
dwdKev, Oh, I think it *is* generally useful, but possibly limited to testing out deployment strategies you'd then incorporate into server mainline code.
KevIf it just needs to meet a use case and it meets it, *shrug*.
moparisthebestI only hesitate because historically XML parsers have been known to have worse bugs than "closes connection wrongly sometimes"
KevThat is not unfair.
dwdmoparisthebest, This is true, but I can smell the faint odour of a DoS attack there somewhere.
moparisthebestI think yes, but only in terms of killing s2s connections ?
KevKilling S2S is probably less bad than *not* killing S2S
Kev(I have no idea if such an issue can present)
flowmoparisthebest, jxmpp has a XmlSplitter, which probably does something similar to yours. It doess not contain a full blown XML parser, but is a little bit more robust as yoursI think
flowI guess what I am trying to say is, that there exists probably a middle ground between having a full blown XML parser and too trivial parsing for things like that
moparisthebestflow, thanks, I'll have a look https://github.com/igniterealtime/jxmpp/blob/master/jxmpp-core/src/main/java/org/jxmpp/xml/splitter/XmlSplitter.java
mathieuiSo… it has come to my attention that profanity is essentially using 140-chars ids for every stanza
mathieuiwas there any rationale for not limiting the length of the id attributes? we do cap the size of JID, afair
flowmathieui, sadly the length restriction of JID parts is the
flowexeception, not the rule
flowwe do not limit pubsub IDs either
mathieuibut as far as I understand it, the only properties we want for identifiers is "we can fit something non-guessabled and non-bruteforceable in it, and all the better if we can write some arbitrary data for testing"
mathieuibut going over 30 or 50 characters seems overkill in every case
jonas’https://modules.prosody.im/mod_client_proxy.html would like to have a word with you ;)
flowmathieui, yes, I think you are mixing two aspects here: the missing length restriction for many ID things in XMPP *and* the question what a sufficiently long ID is
flowthat said, 140 chars is way to long
mathieuiflow: true, but one could influence the other
flowjust because a random ID can be shorter, there may be very well use cases for long IDs which carry some semantics
flowarguably, this may not be likely for stanza IDs, but very true for e.g. pubsub IDs
flowand I am not sure if it isn't true in some case for stanza IDs
flowin any way, we should point the profanity guys to https://www.grc.com/haystack.htm
Steve Killehas left
dwdEvery now and then, I wonder about translation to a UUID in all cases. Mostly for the database efficiency.
Steve Killehas joined
Zash36 octets for 122(?) bits of entropy feels inefficient, plus they don't help with sort order
dwdYes, you need both a sequential id and a uuid in the database. But cheap to lookup a 128 bit number in an index.
larmaAlso UUIDs can be compressed on wire if octet optimization is what you aim for
jonas’something about https://github.com/ulid/spec
dwdI mean, if we wer etalking XMPP 2.0, I'd be saying stanza ids are alwasys UUIDv4 and any duplications detected cause immediate session termination.
KevOf course, even a 128bit integer in string form is less than 140 characters :D
ZashProfanity with their signed IDs?
mathieuithe worst part of the profanity thing is that the id is a base64 of some form of humongous uuid in string form
mathieuiso it’s like thrice the size for no entropy gain
ZashUuid + hmac(key, uuid) IIRC
dwdSo you can detect forged responses and bounces, I imagine.
Ge0rGExcept nobody does it.
Ge0rGI've looked into that source code before. But then I erased my memories with alcohol.
dwdBut it seems to me that the most interesting attacks based around forging responses would be based around witnessing an existing outbound and just copying the ID, which isn't affected by whether or not the id is signed.
Ge0rGIIRC I did a benchmark of "who does the longest message IDs" on my server, and #1 was bifrost, which stuck whole XMPP messages into the ID, for reasons nobody can anticipate, and #2 was profanity
edhelastime to to XMPP stanza over XMPP messages ids
dwdYears ago, a security audit on some stuff I did decided the id space was a side-channel attack. (As were arbitrary XML attributes etc).
dwdI mean, it's fair enough, but in cases where that matters you need a protocol break anyway.
mdosch> Our brilliant plan to make Profanity famous among the XMPP community was a huge success.
> Profanity became a constant hit for discussions in the community. Everybody was and is talking about its huge IDs.
> Now that we have achieved making people aware of Profanitys existence it's time to make them love Profanity.
> So let's have shorter IDs.
Zash"If you want an answer on the Internet, post the wrong answer first."
edhelasthe community manager of Profanity Inc. is a genius
edhelasi propose that the XSF hire him
DebXWoody#1520 \o/ We will be seen by movim :-)
KevCertainly the best issue I’ve read today.
deuillAnother one for XMPP2
jubalhProfanity actually used UUIDs before. We later added an identifier (instance id + barejid) and hashed that together with an uuid and take a base64 from it. The reason for this was that we didn't have any database and we used this to filter messages in MUCs.
Ge0rGthat sounds like insanity
jubalhAnd yeah I just used a UUID instead of a shorter value to hash together because I was lazy and the XEP didn't forbid it :)
jubalhI mean no rfc or XEP said anything (to my knowledge) about the length of an ID
ZashMaybe every RFC and XEP should have the text "Use your common sense." somewhere.
mathieuijubalh, I am curious though, apart from the hack with the hmac, what is the base64 for?
Ge0rGmathieui: because base-16 is not sufficiently inefficient
Ge0rGso it needs to be wrapped
jubalhZash: it was not about common sense. It was about having few time and solving an issue quickly ;)
jubalhmathieui: I don't remember right now. Maybe it had to do with using barejid or something and the allowed values? Not sure anymore.
jubalhI'll read the code in the next days and change that. We also have a DB now so we could actually check in there if we send the message ourselves.
jubalhAnd the part about making Profanity famous is half-true too :) Because I knew (and more people brought it to my attention) pretty long value and devs will notice ;)
Ge0rGOther people noticed too.
jubalhI love you too Ge0rG :)
mathieuiGe0rG, you did not complain hard enough!
Ge0rGI even spent ~half an hour trying to understand what devil has ridden you for doing it this way
moparisthebest> Zash: it was not about common sense. It was about having few time and solving an issue quickly ;)
Ge0rGmathieui: I did, but probably in the wrong place
mathieuiBut having the messages not display in movim because the DB field for the ID is too short was certainly more fun
ZashDon't trust remote IDs?
jubalhIsn't having a limit length for IDs in the DB even more wrong? :) There is no max length defined AFAIK
moparisthebesta way to send messages that only display in certain clients you say mathieui ? nice attack
mathieuijubalh, edhelas trusted "common sense", and having an index on a TEXT column is meh
jubalhi never trust common sense. I have seen all kinds of IDs so our DB doesnt limit it for example. There are some clients that start from 1 and increase their IDs upon each message. If you restart they start from 1 again. I think Pidgin did something funny too (at one point)
mathieuijubalh, is it still the case though? (for the increasing onces) I though every client switched to some kind of uuid
Ge0rGjubalh: yeah, that was funny.
mathieuilet me dream Ge0rG
mathieuiyou evil man
ZashWhy did I even click a link to MySQL docs‽
jubalhmathieui: I'm not sure. I just remember seeing it. And I think Profanity was using the increasing IDs too. And one of my first contributions was to switch it to UUIDs if I remember correctly.
Ge0rGthere was a "nice" bug in bifröst, where its xmpp backend de-duplicated stanzas based on their ID, and presence stanzas that didn't have an ID got into the same deduplication slot and were dropped
Ge0rGsmack will use $random_prfix-$autoincrement
Kevids do have a max length, BTW.
Ge0rGKev: where is it defined? In XML?
jubalhKev: which is? And where is it written?
KevBecause a stanza is allowed to have a max length of anything down to 10k, it means an id can’t be longer than that, less the rest of the stanza ;)
jubalhyou see guys. So Profanity is all good. Maybe we should stay as is then :)
KevI’d say you had a bit more room to play with, even.
jubalhI'll think of something
Zash(unique stream-id + counter), Ge0rG? Like the thing we keep mentioning as The Best Thing? 🙂
Ge0rGKev: there is no upper limit on the upper limit for stanza sizes, so technically it's unbounded.
Ge0rGZash: not quite.
mathieuijubalh, tbh if you get the binary uuid & hash and encode it in ascii85 (instead of picking the ascii repr and growing it with base64) you would fit easily into most lower limits without losing information :p
deuillPerhaps the there can/should be an XEP that provides some sort of best practice for ID generation? There's been a number of advances over UUID algorithms that avoid clashes while retaining sortability.
Zashdeuill, are you volunteering? 😉
deuillTwitter Snowflake IDs were, I think, the first of their kind, but others have emerged since.
Ge0rGdeuill: yes, and that XEP should be RFC6120'
ZashI looked at those. Also LUID and various variants of concat(timestamp, random)
deuillActually, maybe that's a good way for me to contribute. What I can't tell is why the original RFC says stanzas SHOULD have a unique ID assigned (not MUST?). I need to re-read those passages.
ZashFor fire-and-forget, who cares what the ID is
deuillI think some of these algorithms assume Infinite computational power as well, or at least cycles to spare.
deuillConversations apparently tries to de-dup based on ID (even empty IDs)? People's definition of fire-and-forget may vary lol
ZashHere's a start:
xeps$ pandoc -t ./tools/2xep.lua >inbox/best-id.xml <<.
> % Best practices for stanza IDs
> Use UUIDv4.
Zashruns away and hides `base64url(random.bytes(12))`
deuillCo-Authored-By: Alex P
Ge0rGjonas’: I didn't make a github PR for the CVE formatting back then, but I'd still love to move forward with it.
Ge0rGjonas’: with your Editor hat on, what do you suggest me to do next?
jonas’Ge0rG, remove the background color, make a PR?
Ge0rGjonas’: but I like the background color!
ZashDoes anyone know offhand where it says that 128 bit IDs should be enough until the end of time, for use as reference?
Zash(UUID is less because version numbers and stuff tho)
jonas’Ge0rG, I don’t, it makes for a lack of contrast. And if even *I* find the contrast lacking, any a11y tool will throw it in your face.
jonas’Zash, we use 128 bit strength for cryptography, suggesting that you cannot reasonably brute-force a 128 bit thing
Zashjonas’, cargo cult?
deuill(Tangentially related but this was an interesting comparison of GUID algorithms, albeit all implemented in Go: https://blog.kowalczyk.info/article/JyRZ/generating-good-unique-ids-in-go.html)
jonas’so my opinion is roughly: If you don’t read the security considerations, you are a bad developer. No matter how emphasized they are compared to other sections. But there’s nothing wrong with us pointing out and highlighting exceptional cases where there are documented, wide-spread exploits because of such neglect with extra emphasis.
KevThis is not a hill for me to die on, but I don’t understand why we would say the most important thing about a XEP is a section saying someone once got it wrong.
jonas’do you have other proposals to improve the situation that people clearly ignore security considerations?
KevAccept that it’s not the spec author’s responsibility, nor is it within their ability, to make implementors read the spec?
Ge0rGwrite shorter specs.
Ge0rGalso: write specs that are harder to implement in insecure ways.
KevFocus on writing clear specs that are easy to get right.
jonas’Kev, that’s not an improvement to the situation, only to your (our) perception of it
SamWhat Ge0rG said.
jonas’but we can’t fix e.g. carbons and such
SamI don't think this will do what you think you're doing either though. This is just a distraction that may or may not actually have anything to do with the security considerations and may or may not actually contain anything of value that's likely to be repeated.
SamIt's a nice thing to have, it just doesn't seem like the thing we want to drag users eyes to (and possibly away from other important normative things like security considerations)
SamEveryone only reads the examples and not the normative text, let's not also make them only read the CVEs and not the security considerations.
jonas’Sam, but they’re *already* not reading the security considerations.
SamSo don't make it worse.
SamIt's a separate problem is what I'm saying
MattJI don't have full context here, and don't have time to review the entire conversation, but if this is about relevant CVEs being highlighted in XEPs, that's definitely a thing we should do
SamAdd CVEs, that's a good idea I think. If you want to make people read the security considerations, highlight that, not the new non-normative may or may not exist or be relevant examples.
Ge0rGMattJ: it's about the format of that: https://op-co.de/tmp/xep-0280.html#security
SamI have no strong feelings about how this should be formatted, FWIW, I just want to suggest that adding more and more stuff isn't doing what you think it's doing.
SamOn first impressions the one Ge0rG just linked looks great to me and is enough extra formatting.
KevEspecially without context.
MattJOk, if it's just about bikeshed formatting, I definitely have other things to do... :)
MattJOh no, but I can't help it... FWIW I would group all the CVEs into a single box with "The following security vulnabilities have previously been found in some implementations of this specification:"
Ge0rGMattJ: that can be achieved by different XSLT, I'm sure.
KevMattJ: This isn’t all CVEs though, Jonas’ said it’s only those that were widely applicable.
jonas’"worth highlighting" for whatever definition of that
MattJI didn't say "all", did I?
KevOh, and exploited widely, in fact.
KevYou didn’t, but just saying “here are some CVEs” implies it’s somewhat more exhaustive than CVEs that have been widely exploited.
MattJThen insert "notable" somewhere, or something. Or don't :)
KevAnyway, if we’re only talking about vulnerabilities that were widely exploited (which has been precisely 0 vulneralibilities that I can remember), my concerns about them being overemphasised are probably overblown.
jonas’Kev, sorry, I didn’t mean to say "exploited"
jonas’but widely exploitable with simple-enough PoCs
jonas’but I am also fine with less strict constraints
flowlisting related CVEs is probably fine, but not like https://op-co.de/tmp/xep-0280.html#security please
flowthe text of the security considerations is more improtant than the related CVEs. but the currently proposed visualization puts the focus on the CVEs
jonas’flow, see above for my rationale for that
flowjonas’, not sure if I looked at the right rationale, at least I fail to see how this counters my argument
jonas’> so my opinion is roughly: If you don’t read the security considerations, you are a bad developer. No matter how emphasized they are compared to other sections. But there’s nothing wrong with us pointing out and highlighting exceptional cases where there are documented, wide-spread exploits because of such neglect with extra emphasis.
flowthat is what I read. But I don't interpret this as something that argues in favor of making the CVEs visually more prominent than the security considerations
flowif anything, be sparse with visual effects
flowIt feels like Ge0rG had the changelog of a software in mind when he designed this
SamWhat flow says. I don't have strong feelings about the current formatting, but we definitely shouldn't do much more than this (stop signs and big red backgrounds and whatever was being discussed before). And even as is now I still think it will be just like examples where users automatically read the shiny things and ignore the text assuming the examples (or CVEs) cover all the things they need to know.
Ge0rGSam: if the people read the CVE, that's a huge win already.
SamI kind of doubt it in most cases, especially if it comes at the cost of ignoring the text, but maybe.
Ge0rGSam: as jonas’ said before, the text is already being ignored
flowI am not sure if adding big red boxes under the text being ignored helps with that
SamGe0rG: right, and this won't fix it and could make it worse.
SamAnd now the only thing they maybe look at is some random examples that may or may not actually be a good representation of the actual problems and weren't actually a part of the XEP process.
flowIf anything, a short, potentially visually featured, sentenced at the beginning of the xep that states "This XEP has Security Considerations, make sure to read them", would be better IMHO✎
flowIf anything, a short, potentially visually featured, sentence at the beginning of the xep that states "This XEP has Security Considerations, make sure to read them", would be better IMHO ✏
Ge0rGwell, if they read the CVE text, the chances are higher that they'll come to the same conclusion that's implied in the security considerations
SamI doubt it. I'd bet most of them end up with one or two things that are mostly unrelated, or only cover one tiny part of the security considerations.
Steve Killehas left
Ge0rGWell, the list of CVEs is evidence that the current aproach does *not* work. Let's try the alternative suggestion as an A/B test then
SamIf that's actually the problem you're trying to solve, flow's alternative seems better.
ZashA/B tests \o/
Sam(FWIW if we had a way to actually A/B test this that would be great, but I don't think we do)
Daniel> Well, the list of CVEs is evidence that the current aproach does *not* work. Let's try the alternative suggestion as an A/B test then
Do we have evidence that the clients effected by the CVE ever read the xeps?
jonas’how would the know how to enable carbons if not?
DanielThe developers of those clients
Ge0rGDaniel: are you saying that you can implement a XEP without reading it?
Danieljonas’: gajim XML console
jonas’Daniel, please no
DanielLooking at other implementations
jonas’I’m going to get dinner now
moparisthebestreading the xeps don't even matter, what clients/servers send/accept in practice is what matters :D
jonas’because I can’t take that
DanielI'm fairly convinced that this is how a lot of those clients were developed
flowahh, the thought of XMPP devs not even looking briefly at XEPs when implementing them
flowenough xsf@ for today
KevI *know* there have been implementations of features done by looking at sent/received protocol, and not the XEPs.
KevThat’s not even hypothetical :)
Steve Killehas joined
DanielThat's how I implemented <session/>
moparisthebestaren't there plenty of things that are well known not to even be implementable looking at XEPs ? just "shared knowledge" stuff ?
DanielDidn't know what it was. Just knew that sending this magic made things work
SamI'd be willing to be that between what Daniel said, looking at the XEP but only at the examples, and copy/paste from Stack Overflow you'd cover over 99% of all XMPP development. I don't think I'm joking when I say that I'd put money on this.
moparisthebestif a client dev implemented OMEMO from the XEP today they'd probably be pretty sad when they couldn't interop with a single other client ?
SamAnd I'd bet that the other <1% are 99% people in this room :)
moparisthebestthere is a massive difference between what client/servers *should* accept/handle and what they actually *will* accept/handle in practice, you can't get that from looking at XEPs
Ge0rGmoparisthebest: that's actually also a statement about the horrible state of the OMEMO XEP
moparisthebestsame situation with RFCs, and everything in web-land too
moparisthebestcomputers: they bad
mathieuiSam, knowing ex-coworkers who have worked on XMPP for a client website project, that probably sums up 99% of all private-sector XMPP development for people not familiar with standards, yes
mathieui"I just loaded xmpp.js, why doesn’t it work!"
moparisthebestwhen I implemented XEP-0368 in Conversations I didn't know the XSF or XEPs existed
Sammathieui: indeed, I was specifically thinking of a colleague at HipChat who asked me a question about the protocol and I wasn't sure off the top of my head so I said "Here, pull up RFC 6120" and their response was "wait, you actually read these things?"
SamAlthough as far as libraries go, "I just loaded <library>, it should work" seems reasonable.
moparisthebestmy reasoning was roughly: email clients are fine doing direct-tls instead of starttls without any formal specification, why not XMPP
SamI mean, assuming they actually called it somehow, you know what I mea.n
mathieuiSam, well, except you need to at least know some part of the semantics and how they relate with what you want to do
KevI think there’s multiple things here.
* People understanding how they should learn what to do
* People being willing to do stuff properly
* People being competent to do stuff properly
* Doing stuff properly being possible to do
* Doing stuff properly being easy to do
KevAnd probably others.
mathieuiMost certainly others, yes.
Sammathieui: yah, I feel like that's a library design problem though. For most people I suspect they want to call conn = xmpp.Connect("domain.com"); conn.SendMessage("Hi") or something. I really want to eventually get my own stuff to that point
ZashDo we need to stick "The Official XMPP $Language SDK" sticker on some libraries?
KevI think it’s unduly naive to think we can have much influence over some of those, and showing that people aren’t getting it Right doesn’t, in itself, mean that if we just shout at them louder it’ll get better.
SamWhat Kev said.
KevOTOH, some of them (particularly the last two, but also the first) are entirely within our remit.
mathieuiSam, well, if I remember correctly it was something like they did not expose bosh or websocket in their ejabberd container
SamFair; ops is hard no matter what.
moparisthebestand don't get me wrong XEPs are super valuable and we should cram all the relevant info needed in them, if only for a place to point to other than "look what client X does" which sucks
moparisthebeststill, many times you have to dig into what X does, and assume many/most people use this instead of XEPs on how to learn it
moparisthebestTLS had the same problem with people hardcoding version numbers right?
moparisthebest"it works for the current input" not realizing it'd break on 1.3, 1.3 ended up working around it entirely