XSF Discussion - 2019-09-11

Daniel: your tweet to upgrade Dino is a bit, let's say, sparse on detail :-D

which is probably a good thing?

I don't know?

Does has it shiny new features, or was there a horrible security issue?

it had all the CVEs. roster injection. carbon injection. mam injection. https://github.com/dino/dino/commits/master

Does it get a Combo Bonus 😃

:D

Nice.

i mean they fixed it pretty quick.

Daniel: but you didn't want to rub it in?

now someone should probably notify the debian maintainers

ralphm, it's extremly easy to exploit. and someone has exploited the roster one in this muc yesterday

so i don’t want to give details

Well, if someone is updating the CVEs, isn't that automatic?

Also, is there a changelog somewhere?

dino hasn't had a release yet

so no there is no changelog

aside from git

they should definitely allocate CVEs

they, or the researcher who found it?

"someone", actually

I don’t think you need to be affiliated with a project to allocate CVEs

yeah, when I find something, I typically allocate the CVEs myself

i'll probably write something down for the three bugs together

i mean it's the same general mistake

Nobody reads the Security Considerations

yes

is there a bold-red-blinking markup we can use at the top of https://xmpp.org/extensions/xep-0280.html#inbound ?

maybe. if people only read the examples; we should have bad examples

Ge0rG, having a thing in xep.dtd / xep.xsl which allows to mark up Important boxes would be neat

i mean explicitly examples showing you what kind of messages to reject

stuff like sphinx generates with .. warning::

Ge0rG, can you file a thing against xeps/XEP-0001?

that won’t help with RFC 6121, but it’s something

jonas’: an issue thing or a PR thing?

Daniel: that's actually an excellent idea

jonas’: https://github.com/xsf/xeps/issues/821

Daniel: how about https://op-co.de/tmp/xep-0280.html#example-11

The paragraph above that is also new?

Looks fine

Yeah that's probably a good improvement

Daniel: yeah

Daniel: but you can't link to paragraphs

and I didn't want to link to example 10

Makes you question why that wasn't in there before

Daniel: because XEP authors aren't security consultants

Maybe we want to go so far and in the security section say in <strong> *This has been exploited several times*

And link to the CVE

Probably a separate PR

it would mark my third PR for 0280 today.

I mean it is absolutely ridiculous that this has struck so many times in three different iterations

I suppose it is enough to have a negative example for "received", without one for "sent".

Yes

Hopefully...

Daniel: do you have the link to the initial incarnation?

This predates my involvement in xmpp

So no

Ge0rG, a PR thing would be even better than an issue thing

jonas’: yeah, but my work.

MattJ Any reason this room does not _warn the user that the discussions are logged_ ?

As for RFCs, I suppose it could be in errata, but then again, who reads those.

nobody :(

up until recently i didn’t even know they existed

Licaon_Kter [cnvrs] looks like it only sends the signal when archiving is enabled or disabled.

And also the semantic difference between archiving and logging.

Maybe you should have two messages? :P

Link is in the subject and I /think/ also in some room metadata.

Some clients don't really show subjects in a prominent place anymore :(

Zash Subject/Title aside, Converse.js shows them, but will also show_"groupchat logging is now enabled"_ as per https://xmpp.org/extensions/xep-0045.html#enter-logging so, is Prosody not honouring that? Umm https://hg.prosody.im/trunk/file/tip/plugins/mod_muc_mam.lua#l99 maybe

he just answered you

I, obviously, did not undestand a thing 🙂

"when [it] is enabled or disabled."

It is missing a thing for when you join

Ok, right...

Report issue. Patches especially appreciated 🙂

True

But the public logs are provided by a separate module. Should that one add the tag?

IIRC both of them should only let you get logs/archives if you could join the room and get them yourself

If the user is entering a room in which the discussions are logged to a public archive (often accessible via HTTP), the service SHOULD allow the user to enter the room but MUST also warn the user that the discussions are logged.

So Zash this explicitly mentions http based logs

i would argue it does not matter how the server logs, what counts is that is publicly available, and the user should be warned about it

FYI, I only noticed this because ejabberd is announcing it every time Converse.js mysteriously dis/reconnects https://github.com/conversejs/converse.js/issues/1697

lovetox_: so it's also true for MAM

btw i've requested a CVE. i was a bit unsure on the how given that dino technically had no releases yet; but let's see if it gets accepted

Daniel, Requested a CVE for which issue exactly?

It speaks!

balu_der_baer, I put roster, carbons, and mam in one

...in Dino

probbaly not worth creating different ones

It would make sense to ask for one for Converse, though.

balu_der_baer, i can credit you on the carbon one

Right. JC also just fixed an issue in converse

Or is it just the 2017 one revamped?

It looks like it

pep.: but it was fixed back then

In these clients

for converse?

was converse hit back then?

pep.: converse was one of the clients, yes

heh, ok

I think the converse is the relevant one, given it is actually released software and not some "I compiled code from the internetz and is has bugz"

Isn't that the case for all software

balu_der_baer, yes probably. dino is in debian and some other distros tho

I think dino has been released hasn't it? It's in Debian and stuff.

and in fairly wide use

pep.: I've heard that there is software that you need to type from a book

Kev, nope

no release

pep.: https://packages.debian.org/search?keywords=dino-im - different project?

No

But no release

Then it's been released.

No

and that kids is why you dont make packages for git

Kev, https://tracker.debian.org/pkg/dino-im

look at the version string

Hey kids wanna get into a semantics discussion? What is a release?

I'm not saying that upstream say it's stable.

I'm saying that it has been released. I.e. it is available to users.

"It's in Debian so it's released!"

Ok let's leave the semantic discussions for later

Pretty much the definition of released is that it's available, yes.

Upstream hasn't cut a release yet, is all I'm saying.

Distributions do whatever they want with it

it is probably worthwhile to get a CVE for. and it has already been requested

so we don’t need to argue about it :-)

I understand that upstream may not have yet tagged a stable release. Just that that's largely irrelevant to users if they can apt install it.

So is it fine if I package it myself for my own use? Can I also say the software has been released? :)

I also understand that if someone uploaded it to Debian before upstream said it was ready for use, that sucks for upstream.

Or as long as it's published

Kev: that sucks for debian

That too.

it sucks for everyone

Ge0rG, you mean for Debian's users

That three.

upstream. debian. the users

Software releases are hard. Let's go shopping!

am i seeing this correctly that converse has different mam/carbon parsing code for muc vs 1:1

wtf

and it hit only muc because of that

I know that Dino developers tell people to not use the debians "release" build but always use the latest nightly instead. And my guess is that those patches are caused by them preparing for a first real release

Daniel assessing Dino to be vulnerable to the MAM issue predates the commit time of the fix to Dino master by 5 minutes. Either they were super fast, Daniel told them before writing here or they actually knew before 🤔️

A conspiracy within a conspiracy?

balu_der_baer, we were in here talking about how it is most likely vuln

but i was out for a midnight snack before i could be bothered to actually verify

They also have access to this muc :)

and also if you have just before that fixed the roster and carbon issue the mam fix could easily be done in 5 min

it's the exact same lines of code copy pasted

Is anyone filing a CVE for the stanza id bug in Prosody I discovered yesterday?

is it prosody not filtering out?

i didn’t catch you mentioning that

so i'm guessing

yes

obvious bugs are obvious

just get one yourself i guess?

I didn't mention any of the bugs, I left this task to you guys.

did it not filter in general? or just under certain conditions

well how would the stanza-id thing manifest itself?

aside from MAM catchup being fucked

I guess as long as nobody tries to use them for anything, it won't...

also there is code to do it…

I leave it to you or any other dev to find out when and why it doesn't work, I am not into Lua

well i'm not yet sure the bug exists

How would one find out?

balu_der_baer, hint? around what time?

I could go through the logs..

This one maybe?

this room doesn’t claim to do the cleaning

as a client you are supposed to parse the sid only if the server announces that

I'm somewhat happy poezio didn't display the second message, "Or this one"

<body xmlns="broken">Or this one</body>

Daniel, Technically correct.

<message xml:lang="en" type="groupchat" to="pep@bouah.net/poezio-C7iY" from="xsf@muc.xmpp.org/balu_der_baer" id="c090def67ff04d4dae5cfc260bf71522"><body>This one maybe?</body><stanza-id xmlns="urn:xmpp:sid:0" by="xsf@muc.xmpp.org" id="2019-09-11-185b3f943380209c" /><stanza-id xmlns="urn:xmpp:sid:0" by="xsf@muc.xmpp.org" id="2019-09-11-a55228b004fa960d" /><origin-id xmlns="urn:xmpp:sid:0" id="c090def67ff04d4dae5cfc260bf71522" /></message> <message xml:lang="en" type="groupchat" to="pep@bouah.net/poezio-C7iY" from="xsf@muc.xmpp.org/balu_der_baer" id="e11708f4ba544d3e8ceee73bf579544d"><body xmlns="broken">Or this one</body><stanza-id xmlns="urn:xmpp:sid:0" by="xsf@muc.xmpp.org" id="2019-09-11-185b3f943380209c" /><origin-id xmlns="urn:xmpp:sid:0" id="e11708f4ba544d3e8ceee73bf579544d" /></message>

For reference

so if you find a client that uses this for catchup (or anything) then you have your bug

When a message is archived, the server MUST add an stanza-id element as defined in Unique and Stable Stanza IDs (XEP-0359) [2] to the message, which informs the recipient of where and under what ID the message is stored. When doing this the server MUST follow the business rules defined in XEP-0359.

hmm.

That first message was cut in poezio.

Because of the <stanza-id /> :/

<message xml:lang="en" type="groupchat" to="pep@bouah.net/poezio-C7iY" from="xsf@muc.xmpp.org/balu_der_baer" id="b23f6efec2cf4ac2ad23d7da18fb7367"><body>When a message is archived, the server MUST add an <stanza-id /> element as defined in Unique and Stable Stanza IDs (XEP-0359) [2] to the message, which informs the recipient of where and under what ID the message is stored. When doing this the server MUST follow the business rules defined in XEP-0359.</body><stanza-id xmlns="urn:xmpp:sid:0" by="xsf@muc.xmpp.org" id="2019-09-11-e360996b290c9aae" /><origin-id xmlns="urn:xmpp:sid:0" id="b23f6efec2cf4ac2ad23d7da18fb7367" /></message>

I admit, it's funny to see how different clients screw up different things. None of them seems to be really solid about anything so far.

indeed

le fuck wat

balu_der_baer, which client is that?

version string says Movim 0.15

nice

There's the @by. This server needs some upgrades, but that part looks correct?

jonas, openssl s_client

report an issue against movim ✏

heh

Was using Gajim before, but it's XML console does too many sanity checks for doing such evil things

Maybe poezio's /rawxml doesn't :-°

I’ll just leave now

how is <body>foo <bar/> something</body> supposed to render?

It's not, because that's illegal.

not render the entire message?

The server is allowed to bounce it, even. But if it gets through to a client, anything's fair game, I think.

that's what I would do, and as server close the client session (of course configurable, so that if you really want to support broken clients)

The body element MUST NOT contain mixed content (as defined in Section 3.2.2 of [XML]).

balu_der_baer, IIRC this is not even mixed content

flow: It's not?

maybe it is

If it's not then my understanding of mixed content is off.

I just though thtat mixed content is text content + element

and not text content + element + text content

An element type has mixed content when elements of that type may contain character data, optionally interspersed with child elements.

luckily there is a reference where I can lookup this and refresh my memory

or I let balu_der_baer do the work ;)

afaik mixed just means multiple types are used (both element and text nodes), it doesn't mean a specific order or number of nodes

That's certainly how the XMPP specs have used the term, yes.

yep, convinced, and we don't do that in xmpp

i mean cutting your own c2s when your server sends you this is probably not ideal

nobody suggested this

no. i was just thinking out loud if i need to do something different in Conversations

Daniel: No, especially as servers are allowed to send you crap. But I don't think we're suggesting that.

Daniel, You need to fix the <body xmlns="broken"> thing

balu_der_baer, already made a note

I also opened issues in poezio.

Though that's probably in slixmpp

background? implementations do not consider the namespace of body elements?

I have the feeling its super productive if random people just push random stanzas in xsf@ 😉

let's do that more often

> None of them seems to be really solid about anything so far. Nobody has complained about yaxim so far. But don't even try to put different xml:langs into the game ;)

An ancient one is simply putting in multiple <body> (same namespace and xml:lang)

Some clients would render the first, some the last

yeah, having multiple elements with the same name in any kind of hashmap is a well known security issue

⚠ Your client renders a first body when it shouldn't

What should it render?

Nothing, it's an invalid message

I think a few clients have a history of trying to fix received namespaces to work around very old bugs

Why do we try to keep compat with broken stuff? :(

Then we in turn we end up broken

pep., some do, some avoid workarounds for broken implementations

You don't have a lot of choice dealing with broken stuff.

I wish we'd do that as a collective effort to push broken stuff away

At least not in an open ecosystem.

I am in the latter camp FWIW

I also am

You might not try to 'fix up' the broken content, but you have to deal with it.

Kev, I don't think this is true.

Kev, you do, you can just ignore them

pep.: Which is dealing with it.

Yes, while some others try to keep compat

When we began Prosody, many of the other servers were "broken" in various ways... nobody would have used Prosody if we hadn't added workarounds for them

Kev, sounded more like you meant that we don't have a choice besides adding workarounds into our code

flow: Yes, that's right.

Not being able to s2s to 99% of the existing network was not an option :)

MattJ, now that you're a bit more notorious, here's your time :)

Like when ejabberd's PEP module sent tonnes of spurious messages, and if you wanted to avoid annoying your users you had to do something about them.

Right, I'm just pointing out that you can't just make that your blanket stance towards issues like this

(ignore them, in fact, but it took code to ignore them)

Is there consensus that a client MUST NOT render any bodies from a message that contains multiple bodies?

(assuming equal xml:lang)

Ge0rG: You mean multiple bodies in the stream namespace, without distinguishing xml:lang, which might itself come from the stream?

MattJ, true, it is always a per case decission, but to often that decission is "just add a workaround"

In Prosody our policy is to avoid workarounds, and if that's not feasible then we add the workaround with a 'COMPAT' comment that explains when it was added and why (referencing bug reports, etc.)

pep.: Right when we're a bit behind on compliance features in core? Are you working for P1? ;)

Kev: yes

In which case, no, I don't think there's anything in 612[01] that suggests a client would have to do that.

and then we periodically review these and remove old ones that are no longer needed (as much?)

Zash, :P

Kev: I'm pretty sure it's illegal, and the question arises which of the bodies will end up rendered

Ge0rG, what would make it illegal?

flow: 612[01] rules do.

Kev, multiple bodies with the same xml:lang?

Yes.

ahh right, it's in rfc6121 5.2.3

https://xmpp.org/rfcs/rfc6121.html#message-syntax-body

couldn't find a rule in rfc6120 though

6120 just says to use the rules in 6121.

but §5.2.3 doesn't contain a statement on how to handle violations

most things do not contain a statement on how to handle violations

but yes, not showing a body at all appears sensible, probably even if there is a unique body-xmllang for your xmllang

This is the opposite of "make everything you can to show the message content"

https://tools.ietf.org/html/draft-iab-protocol-maintenance-03

MattJ, \o/

this

yep, this

I hate this document.

It only makes sense in a closed system.

With a dozen of actively used XMPP implementations, and a tail distribution of less widely used ones, how am I supposed to know that blocking "invalid" messages won't break the interop with some of them?

It probably will

But if everyone agreed to be strict, that tail would soon be fixed (or rightly let die)

The question is if the outcome is better than being liberal in what to accept

And not everyone has to agree to be strict, just the dominant players

Just like when people went TLS

Prosody fixed many client bugs by being more strict in what it accepted than any of the existing servers

Except dominant players didn't.. at the time

(gmail)

and we don't even go very far

MattJ: but I don't have any leverage on those implementations. And people will blame me for the bugs

I feel your pain, many of us have experienced that

and as I said, we have put in (clearly marked) workarounds for things like that

what is the problem about body with different namespace? so what i dont check the namespace of body if i dont have to, this is certainly no security issue

Ge0rG, or on deployments..

while simultaneously trying to get it fixed

lovetox_, I can include a message that only gajim users will see and not others

yeah and? its a feautre i would say

Is it?

lovetox_, I am not sure if I can't be exploited somehow. The main problem is that implementations treat an element as body when it is not

lovetox_, it's a potential human security issue - if people disagree on what to render for a message, the logs will be showing one thing, clients will be showing another

But I can only come up with very constructed scenarious how this could cause an security issue

despite it being a pretty poor messaging application that can't agree on how to render a text message :)

Like a bot which accepts commands via <body/> and a screening service checking that the commands in <body/> are safe

XSF board meeting logs could all be faked by board members, and someone will put <body>+1</body><body>-1</body> to make people think they voted one way on a contentious issue, but the chair would see them voting a different way

Consistency is good, inconsistency is bad

word

Consistency in a distributed open network isn't always easy

But if we at least specify the right way to do things, that's a great start

Right now nobody can even claim any particular client is buggy, because there is no correct decision about what to render (which may include nothing)

(or an error)

I'll note that even excluding potentially-illegal <body> constructs, this issue will still exist for multiple <body> with different xml:lang (I can show different versions of the same message to different languages, they don't have to say the same thing)

But at least in that case a client could indicate to the user that other versions of the message exist, and allow them to view them

Mhh I now have uncommitted code that skips messages with body of the same language. Not really sure if I should commit that. I mean it's definitely illegal. And it probably won't happen on accident

flow: do I need to pull a CVE number for Smack delivering the first of multiple equally xml-langed bodies?

Ge0rG: is that a security issue?

Daniel: what MattJ wrote. <body>+1</body><body>-1</body>

https://logs.xmpp.org/xsf/2019-09-11#2019-09-11-869b4f1282d0a054

Daniel: if there is only one implementation rendering the _last_ body from that list, it is a security issue

Ge0rG, what else are you supposed to do?

That's a user confusion/unreliability issue. I'm not convinced it's a security issue.

aioxmpp will take one, which one is officially undefined (but it will be the lastmost in the stanza)

jonas’: tear down s2s!

for ever!

Ge0rG, seriously though. what should I do as a client library?

send back an error?

I see how this is a problem, I just don’t know the correct course of action

jonas’: me neither

that will get you kicked from the muc lol

and presence leak

(potential)

Kev, I'm surprised that in the environments you're involved in, you don't see user confusion as a security (or safety) issue

jonas’, i just opted for ignoring it

will happen infrequently enough to not be a real issue

Especially if you add enforcement or auditing tools to the mix, which might disagree about which <body> to use/allow

MattJ: maybe because it's scoped to the sending user.

flow, uh--- that’s an interesting one, I think you can make aioxmpp auto-reply to a message if you violate the schema hard enough

If somebody wants to play mind tricks with you, the impact is limited to what you'd believe them

jonas’, take the stanzas out of the stream, send an error back if the sending entity is subscribed to your presence and log an error

Why has it been specified that a MUC should kick us on message @type=error btw?

pep.: yes.

Daniel, so you drop the entire stanza if there is more than one <body/> with same-language?

because if your session dies?

jonas’, yes

flow, yeah, no, the part which sends errors back wouldn’t know about that type of stuff

Ge0rG, am I onto something?

jonas’, I never said it is easy ;)

jonas’, i mean no; i return the body as null. it might run through other paths

Daniel, right

pep.: I was going to elaborate, but Daniel came first

for all languages or only for the buggy one, Daniel?

if my session dies?

good question 🙂 no for all messages

jonas’, remember when we talked about providing a callback to the user which informs him what exactly went where wrong in the incoming processing chain?

pep.: yes, the MUC needs to kick you out if your client silenty disconnected

flow, exists, but that is not an error condition yet

But what if my client doesn't silently disconnect and I'm just trying to point out errors to others

and I’m not sure what type of error condition it should be

pep.: send a PM

@type=error?

pep.: yes, those won't get you kicked IIRC

I see

I have no idea how clients will behave ;)

I guess this + ignoring a message should be good

Ge0rG, so auto-reply from the library woudln’t get me kicked either since that would go to the full JID ✏

pep.: presence leak

rrr

Can you stop finding issues

So can we now decide whether it's a security issue or not?

pep.: no

life would be boring otherwise. Also, blame balu_der_baer

But that's probably going in the logs anyway and not actually visible by the user.

I'll "fix it" in that i will ignore it in the future but i wont rush out another release

I would like if a client would tell me "There is an error" (and aggregate them) "please report that to the dev"

Daniel: can you rush out releases again? Or is Play store still imposing multi-day delays?

yes i could

was meaning to tweet that

i fixed the PS issue

but i was doing so much tweeting lately

My other app is broken on Android 10 because Google finally removed the deprecated Apache HttpClient library which is used by... the Google Maps v1 library.

Daniel: as much as @xmpp?

not as annoying as @xmpp

my tweets are super high quality

I've been struggling to convey this message to the person responsible, for some days now.

doesn’t someone else have access to that account and can single-handedly change the password?

I think we'd rather fix this socially

jonas’: nobody knows who that "someone else" is

access yes. can’t change the pw though

Not technically

pep.: full agreement here.

Which account what where?

i mean sometimes i do tweet on @xmpp. but when i do it's only the best tweets

Maybe I should just stop trying though, I'm probably the least empathetic person to attempt it

Kev: twitter.com/xmpp

Daniel, of course

Ge0rG, Daniel, actually I think we just need to agree on *which* of the multiple bodies to show and it’s a non-issue, right?

jonas’: right

Is that the XSF's one? I thought I had credentials for the XSF Twitter (although 1password is failing me)

well rfc says it's illegal. so just dropping it is easier?

Kev: yes

I wonder why I don't currently have it.

Daniel: I'm sure some clients/bots will end up sending a default body and one in an explicit language, and the explicit language accidentally being the default one

jonas’, coming up with a selection algorithm could be hard

so we know it's not Kev whos doing the annoying tweets…

flow, "first"

jonas’, first in XML?

LinkedHashMap to the rescue!

flow, yes ✏

jonas’, what if "first" is different per recipient

flow, how is that supposed to happen?

nothing gurantees that the order of the elements is stable when a stanza passes a hop

flow, the order of elements with the same namespace-uri/local-name pair?

I think we’d be in trouble already if that was violated.

especially the order of those elements yes

Hmm. Looks like my tweetdeck doesn't have it either. I'm finding this very confusing.

> Ge0rG> Daniel: I'm sure some clients/bots will end up sending a default body and one in an explicit language, and the explicit language accidentally being the default one Let's agree to fix these bots?

jonas’, like where?

flow, [thinking ...]

flow, forms?

Kev: escalate to the A-team?

it’s not strictly required there, but would be a major UX pain if the elements were reordered there

are child elements of <x/>

I am taking just about first level child elements of stanzas

flow, oh, you’re only talking direct children of the stanza?

huh

why would that follow different rules?

well mostly, for forms the order is actually important

for first level stanza childs it is usually not

Right. I have control of @xmpp.

Awaiting further orders :)

change the password until someone has found the person spamming newsletter ads on it ;)

I believe it to be at least unspecified that it has to be stable when processing a stanza, and while most implementations may keep the order, we should not depend on unspecified behavior

Changing the password won't help, people are granted access via tweetdeck.

I mean, unless it's genuinely compromised.

Kev, you can probably access analytics though? I think that came up yesterday in commteam@

looks more like "well meant but went too far"

jonas’: I know who that person is

And they're not hiding it either

If someone from Board tells me to, I'll strip access down in tweetdeck.

i think it has stopped anyway

Daniel, no it hasn't, it won't, read commteam@ :)

Kev: yeah, can you check analytics for the number of new followers vs. gone followers since September 3rd?

No clue, can I?

regarding the twitter activity, there was some wiki acitivty: https://wiki.xmpp.org/web/index.php?title=Special:RecentChanges&days=1&from=

Kev: it was said to be on https://analytics.twitter.com

https://wiki.xmpp.org/web/CommTeam/Newsletter_Twitter_campaign

i'm confused

I do not believe I can get past stats on follower counts.

Bummer.

28 day summary sees tweet count up, impressions up, mentions up, profile visits down 17%, followers I think stable, unless I'm misreading, or unless it's not giving the info.

Kev: thanks

In that case, it looks like the spam strategy is working out

assuming this are good metrics…

I can only report what's in front of me.

For clarity, as discussed in commteam@, those news letter tweets were sent by nyco. Some of the conversation might have been a bit harsh on him, as he is just trying to help.

I'm very sorry that I hit the wrong notes in trying to talk to him :(

To be honest, I was the one raising the issue in that room, and here before that, but I think we can take a lesson in seeing things from other perspectives, as well trying out things.

In the mean while, should you have interesting stuff that could be (re-)tweeted from @xmpp, do let them know.

I don't think I've (deliberately, at least) passed any judgement other than offering to do what I'm told.

Scheduled tweets interspersed with other stuff would already be a lot better.

Kev: not calling anyone out specifically. And not even just on this topic.

Ah, my stats were September.

yes. we actually have a lot of things going on in the community to increase # of tweets w/o repeating ourselves

I assume everyone tries their best.

So for August we lost followers, and for July we gained (more) followers.

In fact, as far back as we've got stats, August is the only time we've lost followers rather than gaining.

also 'we' probably react more sensitive to obvious advertisment than a regular person would

Daniel: or without uttering things that look like cheap SEO

Or that.

I'm back in 2017, and we've gained double-digits of followers each month, other than losing them in August.

I'm going to stop looking at stats now.

how about re-tweeting https://twitter.com/iNPUTmice/status/1171678611897835520 ?

jonas’: it lacks hashtags

:-)

i literally loled

speaking of high-quality content

#thatshouldhaveacve?

jonas’, fwiw i usually RT my own tweets with xmpp if i consider them neutral and quality enough

cheap self-promotion!

:D

good morning you should update dino did not make my own quality standards

I like it actually

Had Daniel's mentioned that you should because of security issues, I would have retweeted it right away.

to my defense I did wrote that before i had coffee

that’s not to diminish dino, but it’s the kind of near-sarcastic security black humor I’m into w.r.t. announcements ✏

Noted. Daniel: don't 🐦 before ☕

Well on that note, you should also update converse. Maybe we can have a tweet with all of them.

And then retweet! When we get CVEs assigned

All PR is good PR right

FTR, Docker Hub is an awful thing

> Created 44 minutes ago > Queue time 1 minute > Duration 0 min

> Logs are not available yet

what kind of infrasturcture is this?

A free one?

A terrible one

Ge0rG, re MUC & errors / presence leak, a client could theoretically (not saying I'm going to do it) buffer these error messages going out, and only send them when the user sends chatstates or messages in the MUC.

What about chat markers btw, are they also used in MUC? receipts are this I know. Isn't that a good enough presence leak already?

Why would you send errors after a while? A server is likely not going to have anything it wants to do at that point?

Sending error to the participant jid, in hope that that gets logged by the clients and there's some kind of hint displayed to the user to actually contact devs. (Yes I'm pretty hopeful)

By that time the user could be gone for sure

Just like they could be gone when I connect and fetch messages ✏

Correlation is not fun with random long delays, maybe.

hmm

True

But then people shout "presence leak"

what is a presence leak?

i previously thought of it as a resource leak

Daniel, you connect, your client fetches archive from MUC, finds an error and attempts to send that to the participant jid responsible for it. You're then effectively telling them you just came online

(or that you're somehow available)

in a group chat?

Is presence leak really a thing for MUC (as opposed to MIX)?

didn’t you just did the same by joining?

This

I wasn't the one to shout "presence leak"!

:)

But yeah, I actually agree. let me dismiss that issue then

Maybe combined with MSN? One of your clients didn't notice, the other connects and you send these errors. But then oh well

Now, in theory, for MIX this is a bit different. There, sending presence can be optional.

But then you might have markers or somesuch.

It's fine I'm not concerned about MIX for now, poezio doesn't have an implementation :)

This is the XSF channel though, and not jdev 🤣

heh

So you can do MIX PR just fine? :P

Kev, (moving this from council@), but what stops me from sending you a random type=error (think spam)?

if you make swift show a popup and interrupt the user, that’s bad design IMO

Daniel> i previously thought of it as a resource leak It is the same, but "presence leak" is the term rfc6120 uses

I guess that also dismisses most of the recent discussions on Unicode and security issues in implementations. 😃

yes. but by that definition sending chat markers does not leak your resource

chat markers leak that you are present

but that's not what the term means

(at least that what i've thought)

jonas’: I never said anything about popups (Swift policy is to never trigger popups from protocol).

But if you start receiving errors from someone, it'll tell you in the chat log with that person.

Kev, that, I think, is fine

even with CC-all-the-errors

it shows that something you did on your phone went wrong and that you might want to pay attention (essentially)

But not if it's bare-JID errors.

> Daniel> chat markers leak that you are present Depends on the situation i'd say. Client should usually not send stanzas to other clients that are otherwhise unable to determine if you are online, that's what I'd call a "presence leak".

i dont understand the benefit of the token XEP

it says something about that the password can be stolen

lovetox, maybe on-list?

but a token is the same, if its stolen, i can change the account password

I haven’t read it yet and I have to go AFK now

at least its nice that the xep gives the user some knowledge about what devices have access to the account

You could simply not allow that

you mean the server?

so how would then someone change his password

Login properly

tokens are opaque and properly randomized; also they are not often stored on a stick-it note ;)

there is also very much value in one-time tokens to on-board a new device to your account

without having a password in a URL or QR code

but this is not about one-time tokens, so why are you mention it?

because its also a "token"?

its basically a password replacement that has absolutley the same propertys, full access to the account

so as i said i think it adds value because you know what devices are in use, it does not really provide any additional security

Hm? Per-device passwords?

Per device passwords

and it was always weird for me that the register xep does not have an option where the server can demand your current password

You somehow logged into the account

yeah ..

I mean per device passwords is not necessarily a bad thing. I don't know if the xep is a good implementation of that

I haven't read it yet

But I wouldn't dismiss per device passwords on principle

I wonder if you can hijack the authzid for something like that

i didnt dismiss it Daniel if you got that from what i said

the XEP talks a bit about security

so thats what i questioned

its definitly nice to know what device are connected and beeing able to remotley log them off and revoke them

> its definitly nice to know what device are connected and beeing able to remotley log them off and revoke them Yes

I wouldn't be opposed to tokens that have limited permissions behind, like not being allowed to change the password or to issue further tokens; also a limit to one connection per token

All that

lovetox, in SASL EXTERNAL with client certs (XEP-0257 IIRC), it is said that if the user tries to change their password, they should get an error and then asked for the previous password first.

Yes, with a data form

In the non-error part of an error iq. ;_;

> Yes, with a data form Data forms are definitely in the top five of my favorite forms

I think auth tokens could be reusing RFC7628 and in general be more OAuth compatible

Oh, and XEP-0235

oh, TIL

oh they gave me three CVE

Maybe it's a special offer on Wednesdays.

can't get enough of that wonderful CVEs

Gotta catch them all!

They need to motivate the six digit numbers!

Do you win something if you get there first?