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’(or equivalent)
jonas’I think you already need that + endElement + magic to determine the stanza boundaries anyway
BASSGODhas left
mukt2has joined
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)
Andrzejhas joined
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 ;))
Guushas left
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’yes
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
yushyinhas joined
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
marekhas joined
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.
jonas’;)
millesimushas left
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
millesimushas joined
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?
mukt2has left
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
alexbay218has left
jonas’> Implementations are advised that using a prefix other than 'stream' for the stream namespace might result in interoperability problems.
moparisthebestah, nice
flowmoparisthebest, sounds like you have a new(?) project, what is it? :)
Aleksejhas joined
florettahas left
moparisthebestflow, reverse proxy https://github.com/moparisthebest/xmpp-proxy still super early, just started dogfooding it on my server recently :)
BASSGODhas left
mathijshas left
mathijshas joined
adiaholichas left
mukt2has joined
adiaholichas joined
menelhas joined
BASSGODhas joined
adiaholichas left
peetahhas left
peetahhas joined
adiaholichas joined
Sevehas joined
Vaulorhas joined
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.
eevvoorhas joined
moparisthebesthttps://github.com/surevine/Metre ? quite a bit different I guess
mukt2has left
debaclehas joined
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?
Andrzejhas left
KevOr is there a ‘I have verified trust, just do external’ flag being passed to the server-proper somehow?
Andrzejhas joined
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.
papatutuwawahas joined
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.
menelhas left
superkuhhas joined
antoinehas joined
dos1has joined
mukt2has joined
rdelaagehas joined
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.
florettahas joined
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.
millesimushas left
millesimushas joined
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.
Andrzejhas left
moparisthebestalso '< stream:stream' and a few other things, probably ok, it accomplishes it's goal
Andrzejhas joined
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.
wurstsalathas joined
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 :/
emushas left
KevI would be inclined to bring in an XML parser, personally.
alameyohas joined
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.
emushas joined
dwdmoparisthebest, This is true, but I can smell the faint odour of a DoS attack there somewhere.
beanhas joined
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)
adiaholichas left
adiaholichas joined
lskdjfhas joined
LNJhas joined
mukt2has left
adiaholichas left
Syndacehas left
Syndacehas joined
adiaholichas joined
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
mukt2has joined
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
menelhas joined
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
paulhas left
paulhas joined
BASSGODhas left
BASSGODhas joined
pasdesushihas joined
govanifyhas left
govanifyhas joined
pasdesushihas left
ralphmhas joined
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
BASSGODhas left
BASSGODhas joined
mathieuiindeed :/
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
menelhas left
jonas’https://modules.prosody.im/mod_client_proxy.html would like to have a word with you ;)
derwinhas left
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
Aleksejhas left
flowthat said, 140 chars is way to long
mathieuiflow: true, but one could influence the other
flownot really
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
mdoschhas left
mdoschhas joined
millesimushas left
florettahas left
Andrzejhas left
mukt2has left
hamishhas left
Steve Killehas left
dwdEvery now and then, I wonder about translation to a UUID in all cases. Mostly for the database efficiency.
edhelasdwd +1
Steve Killehas joined
mukt2has joined
Zash36 octets for 122(?) bits of entropy feels inefficient, plus they don't help with sort order
millesimushas joined
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
hamishhas joined
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
adiaholichas left
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
mathieuibut why
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.
adiaholichas joined
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.
Ge0rGYeah.
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
mukt2has left
menelhas joined
florettahas joined
jonas’what
goffihas joined
edhelastime to to XMPP stanza over XMPP messages ids
edhelas*do
stphas joined
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."
pasdesushihas joined
edhelasthe community manager of Profanity Inc. is a genius
edhelasi propose that the XSF hire him
Andrzejhas joined
florettahas left
DebXWoody#1520 \o/ We will be seen by movim :-)
adiaholichas joined
Andrzejhas left
Andrzejhas joined
mukt2has left
pasdesushihas left
Andrzejhas left
Andrzejhas joined
ti_gj06has left
KevCertainly the best issue I’ve read today.
derwinhas joined
ti_gj06has joined
lovetoxhas left
Andrzejhas left
pasdesushihas joined
ti_gj06has left
florettahas joined
ti_gj06has joined
lovetoxhas joined
deuillhas left
pasdesushihas left
deuillhas joined
deuillAnother one for XMPP2
mukt2has joined
pasdesushihas joined
pasdesushihas left
Andrzejhas joined
alameyohas left
adiaholichas left
adiaholichas joined
alameyohas joined
mukt2has left
mukt2has joined
adiaholichas left
alameyohas left
Andrzejhas left
mukt2has left
adiaholichas joined
millesimushas left
mukt2has joined
Andrzejhas joined
steffenhas left
jubalhHi guys
Zash👋️
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 :)
ZashThe XEP‽
jubalhI mean no rfc or XEP said anything (to my knowledge) about the length of an ID
Andrzejhas left
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 ;)
Ge0rGI noticed.
jubalhHahaha
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 ;)
amen brother
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.
Ge0rGmathieui: BWAHAHAHA
Ge0rGsorry.
mathieuilet me dream Ge0rG
mathieuiyou evil man
millesimushas joined
mukt2has left
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.
Andrzejhas joined
ZashKev, ~10MB?
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.
Kevhmac(base64(stanza))?
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)
jonas’ITYM ULID
Zash[IDLU]{4} 🤷️
mathieuiIIII
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.
> .
```
Aleksejhas joined
Zashruns away and hides `base64url(random.bytes(12))`
Aleksejhas left
deuillCo-Authored-By: Alex P
deuillThanks Zash
Calvinhas joined
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.
Freddyhas left
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 red-on-red would definitely make this worse
jonas’and yeah, weave is contrast-error marking all of that
jonas’ok, the black-on-red not, but green-on-red it doesn’t like
mukt2has joined
Ge0rGjonas’: I've reduced contrast of the red, can you shift+reload
Ge0rGmaybe you still have my old version cached
Zashjonas’, IIRC even counting to 2⁶⁴ in boil-the-oceans levels, but for IDs it's more about the chances of accidentally generating the same ID twice during the lifetime of the scope.
Zashjonas’, IIRC even counting to 2⁶⁴ is boil-the-oceans levels, but for IDs it's more about the chances of accidentally generating the same ID twice during the lifetime of the scope.
Ge0rGjonas’: maybe it's because the default text color is #444
ZashOh look, it has a table
jonas’Ge0rG, it’s complaining about the coloured text, not about the grayscale text
hamishhas joined
Ge0rGjonas’: another shift-reload?
jonas’I don’t see the link as link anymore
jonas’looks black to me
xeckshas left
jonas’(but weave is happy about the contrast… which is pointless though)
jonas’welcome to the world of making an accessible thing.
Ge0rGjonas’: is your monitor calibrated?
jonas’do I need a calibrated monitor to read XEPs?
xeckshas joined
Ge0rGjonas’: you need a calibrated monitor to complain about lack of contrast ;)
jonas’no, I don’t
Ge0rGjonas’: I *really* want that reddish background, because without it just looks naked
jonas’sorry for your loss
papatutuwawahas joined
jonas’I won’t accept a reddish background just because you prefer it if it renders XEPs less readable for people with visual deficiencies or under bad lighting conditions or whatever
jonas’I took great care during the XEP redesign to avoid such pitfalls, I’m not going to let you ruin that ;P
Ge0rGsaid the person who uses #444 instead of black for text.
Ge0rGjonas’: shift-reload again for the naked box.
Daniel> said the person who uses #444 instead of black for text.
That's better than #666
jonas’Ge0rG, LGTM
Ge0rGLe Sigh.
Ge0rGnow how do I add a huge red warning sign there?
jonas’but I knew that already, I tested your design with background-color disabled and was immediately happy
Ge0rGso we can't both be happy, right?
jonas’yes
Ge0rGwell, I can be happy if that box has a huge red ⚠️ in the left, but I don't know how to make it
jonas’Ge0rG, you need to do something with <img/> or background-image
steffenhas left
KevWhy should we be making these things prominent anyway?
jonas’to get a warning sign without disturbing a11y tools
KevSecurity considerations aren’t, for example.
SamYah, this seems like something to be aware of but not something that you absolutely definitely must see at all costs (as opposed to security considerations which are that)
SamThese are just non-normative examples of what can go wrong.
jonas’and examples of where the security considerations have been ignored, so placing them really prominently is something I’d deem useful
Ge0rGWhat jonas’ said
SamProminent placement is fine, but it's not important to specifically draw the users attention to them over other things like the security considerations
Ge0rGlet's add a red background to the security considerations then!
mathijshas left
chronosx88has left
chronosx88has joined
jonas’and make them blinking /s
Ge0rGjonas’: at least it won't complain about contrast then!
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.
steffenhas joined
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.
Sam+1 ^
mukt2has left
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
Ge0rGXMPP 2.0!
larmahas left
larmahas joined
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.
adiaholichas left
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.
mathijshas joined
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
Andrzejhas joined
jonas’but I am also fine with less strict constraints
karoshihas left
Freddyhas joined
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
Andrzejhas left
Andrzejhas joined
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
ti_gj06has joined
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.
werdanhas joined
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
karoshihas joined
jonas’-ENOTIME
flowIt feels like Ge0rG had the changelog of a software in mind when he designed this
BASSGODhas left
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
adiaholichas joined
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.
BASSGODhas joined
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.
adiaholichas left
ZashA/B tests \o/
mukt2has joined
adiaholichas joined
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’please no.
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
jonas’cries
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 ?
Sam*bet
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
mukt2has left
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
paulhas left
mathieuiSam, well, except you need to at least know some part of the semantics and how they relate with what you want to do
paulhas joined
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.
BASSGODhas left
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.
debaclehas left
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
mukt2has joined
goffihas left
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
adiaholichas left
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