XSF Discussion - 2018-03-15

after reading https://gultsch.de/converse_bookmarks.html, I think we should adapt the security considerations of XEP-0223 to include a strong hint that discovering support is vital for security

jonasw: that or doing the probing limbo dance

probing limbo?

Where you publish with options set and then query what the server did out of that

BBL

and then your data is already public?

Trying with non-sensitive data first?

not convinced

discovering the feature seems more reasonable to me

Of course.

Are the required features recent additions or what's the issue here?

(assume I've lost all memory)

no, people just apparently don’t check if the service actually supports publish-options ✏

I approve of big angry warning in 223

Zash: PR or didn't happen

Ge0rG, #608

:P

https://github.com/xsf/xeps/pull/608

jonasw, +1

I was slightly shocked that a XEP which puts private data in pubsub boldly claimed that there were no security considerations above those in '60 and '163. I haven’t checked if "everything’s gonna be public" has been mentioned there, but not mentioning it in '223 anyways feels like negligent

jonasw: 👍 Also I remember documentation somewhere on how to publish to PEP in a secure way, but probably it predated the latest publish-options

Ge0rG, daniel has some on his site

Yeah, that

this one probably: https://gist.github.com/iNPUTmice/7c52785ed69787516abb60e31703dbd2

I was looking into crawling all my contacts' PEP for their bookmarks for a while, but I never was sufficiently good at scripting xmpp

Ge0rG, just subscribe to the node

does that give you a push when you come online?

yes that'll push you all your contacts bookmarks

neat

lemme try that

aehm +notify i mean

sure

daniel: you mentioned that, yes. But it still requires code to subscribe and to process events

heh

lemme aioxmpp that for you

If somebody writes a script that...

jonasw: yes please

`storage:bookmarks+notify` ?

Are there any other use cases of private PEP?

i justed added that to Conversations very quickly. that was like two lines of code

when i tested that last month

Just tried using clix. Boring, got nothing but disco#info queries at me.

yeah it's not very widespread it seems. nobody uses converse.js (to publish! bookmarks) and in poezio it's just a rare corner case

What's `urn:xmpp:inbox`

Ge0rG, aioxmpp git pull && cd examples && python3 listen_pep.py --namespace storage:bookmarks

stop it with Ctrl+C

I tested it with urn:xmpp:avatar:metadata

Uh, taking a thing that's meant for *broadcasting public data* and using it for storing private data?

it revealed the depressing amount of people using xep-0084

About a quarter of my contacts, it seems

note that you wont receive pep notifications for offline contacts on ejabberd servers

that might distort what ever you are 'testing'

jonasw: Nice caps2 you got there

:)

the resource tells you why

jonasw: ModuleNotFoundError: No module named 'aioxmpp' 😞

jonasw: Does it offer like an XML console/REPL hybrid thing? (like `clix raw`)

If not, make one, it's the best thing since sliced bread

Ge0rG, enter your jabbercat virtualenv ✏

Oh, yes.

Zash, yeah, it’s tricky to do that with asyncio though

like, really tricky

readline + asyncio doesn’t mix

Can't pretend that stdin is a socket somehow?

that’s not the main problem

writing things on stdout asynchronously and expecting readline or whatever’s handling your input to cope by redrawing is "nope"

I messed with that for some time and then gave up

closest thing I can do is something based on urwid (pure-python ncurses-like thing)

not to mention that doing actual raw XML is super-hard with aioxmpp

clix doesn't use readline, just the bare io lib for reading stdin, and some clever lies told to the network server

jonasw: so it's idling there after I entered my password. Does that mean everybody I know is safe?

Ge0rG, yeah

modulo what daniel said

I usually wrap it in rlwrap. Not that it gets happy about showing new stanzas while you are typing something...

ah, urn:xmpp:avatar:metadata happens to return a bunch of things.

Zash, yeah, that can probably be done easily, but that goes against my perfectionism ;-)

I demand a zemlyanka frontend.

a what

that used to be a TUI binding for one of the large X11 toolkits. GTK I think

creepy

I am waiting for a use case that mandates a resurrection of TurboVision

“13:27:28 Steve Kille> Ge0rG: military users like to have lots of tabs, so they can monitor many chats at once, with keyword highlighting to draw attention to things they care about. I have been told of an operator with 64 rooms displayed”, damn, I should get into this business, they’d see my poezio with 216 tabs (currently)!

216 is a great number

About half of those are private discussions, the rest are MUCs.

Link Mauve: You are promoted to General. Report to the president at once. ;)

Haha

Zash, it’s with the very concept of war that I have an issue, so sadly I can’t make use of my great poezio skills that way.

Link Mauve, sabotage them from the inside!

Any Boardies about?

Hi MattJ

ralphm, Guus

I'm here, but also in a telco

Can somebody else take the lead for this meeting?

I can

Thanks Martin

1. Roll Call:

Me, MattJ, and ralphm in his peripheral vision

2. Minutes.

Any volunteers?

I'd rather not volunteer, as I already have outstanding commitments...

I'm half here

I would, but I can’t promise that I don’t have to disappear in the next 30 minutes, sorry.

OK, I'll try and scribe after the fact

3. Topics for decisions

3.1 Board Priorities

From last week's minutes, seems like there's a meeting that needs arranging

Anyone know where that's at?

Nyco has asked me for availablity a couple of times

Don't know the current state.

OK, let's kick it along the road to next week

At some point, I think we should give up on this.

Sooner rather than later.

wfm

Let's give it another week, then see where we are

K

3.2 Bus factor / bank account

I failed to ping Peter

Still waiting on feedback from the bank, AFAIK

OK

4. Commitment list

4.1 Board priority meeting: dealt with above

4.2 Membership survey, MattJ?

Not finished, but I may send a draft for feedback to the board list in the next day or two

Cool

4.3 Prepare discussion points regarding the Fundraising and Financing discussion.

Guus?

I did not plan to be here today (I sent apologies) and did not prepare for that.

OK, no problem

Next week

5. Items for discussion

5.1 Fundraising & finance

I'm guessing we should postpone this topic given the above?

+1

Yup

6. AOBs

Any?

None here

Not from me

Righto

6. Date & time of next? Everyone OK with +1W, 14:30 UK time? (I know some DSTs kcik in)

wfm, I think everyone is going to switch at the same time anyway

It's 14:30 always, right?

Guus: It is indeed

Wfm

Excellent, then I think we're all done. Thanks all!

Thanks Martin :)

Tx

. . .

. .

.

Pidgin still uses legacy sessions? Oh rly?

Everything uses them

Some servers required it, and there wasn't any way to know that it was optional.

So it must be used if offered.

Or you risk not being able to login at all

And what if not offered?

yeah, learnt that the hard way with aioxmpp

Pidgin breaks? yay.

If not offered then ???

Now there is an <optional/> tag right ...

Probably some clients will do it anyways because reasons, and shoot themselves right in the connection.

if not offered then pidgin = "borked" end

XD

classic pidgin

Neustradamus, what you made me do :P

Holger: In an expired draft...

Zash: Well, yeah.

Prosody does add optional tho.

Holger, I (re-)added the optional and changed the default to not offer legacy sessions by default and guess what... An e-mail this morning stating someone using Pidgin can't login.

woohoo

Heh, https://hg.prosody.im/trunk/rev/0bbbc9042361

actually that might be good

Praise waqas

That might predate the draft

if they can't login with pidgin, then it's "pidgin sucks", if they login with pidgin successfully then it's "xmpp sucks"

moparisthebest: whoever touched it last gets the blame

moparisthebest: I think XMPP sucks if we break interop for no good reason.

First rule of Internet protocols: It has to work.

that's if you define pidgin's xmpp implementation as 'working otherwise'

Depending on the use case it works just fine of course.

for the use case of work like AIM in 1999 sure

That's the #1 strength of XMPP. We can add a ton of modern stuff without breaking Pidgin.

moparisthebest: Yes for many of my co-workers that use case hasn't changed.

I'm not so sure, whenever someone says 'XMPP Sucks' if you ask enough questions it usually boils down to 'Pidgin Sucks'

Saying it's good to break stuff for them because Pidgin doesn't fit your use cases is going for Matrix.

> If it ain't broke, don't fix it. Common saying about things that appear to work, but are actually horribly broken.

If I wouldn't care about compat I'd ditch XMPP and start from scratch.

moparisthebest: I'm sure he'll love XMPP if you break Pidgin's ability to initiate a session altogether.

Maybe even Pidgin with GTalk

I'm just saying virtually every time I've had a discussion with someone that said xmpp sucks, they meant pidgin connected to gmail sucks

luckily half of that is gone now

Is it really tho?

I thought it was?

Federation is dead

I think the solution for pidgin is either: A) Fix pidgin's xmpp support or B) convince distributions to ship something else by default.

moparisthebest: I do not doubt that. The thing I don't understand is how you come to the conclusion that breaking Pidgin helps with that problem.

jjrh: Too attractive to ship one thing, get all the protocols

Zash, I'd be interested in how many people actually use pidgin for much other than XMPP and possibly IRC.

pidgin user's should be used to stuff breaking, lync support always broke when I used pidgin for it

of course official lync client isn't much better...

moparisthebest: Have you tried suggesting alternative clients when you reach the conclution that pidgin is the problem? Assuming they understand or admit it themselves?

yea, every one I've convinced to try Conversations really likes it

I mean ummm 5 or so years ago pidgin was okay. You could connect to a bunch of chat systems with it. These days everything has broken their support. I migrated to bitlbee for a while then gave up and just open browser tabs

moparisthebest: because that's probably one of the times they'd be most receptive to it

it sure doesn't work to say something like "your thing sucsk, try mine"

Even less so if your thing was a desktop client and mine runs on Android.

Pidgin dev is pretty dead by the looks of things. :P

Sure.

Last news update was 2016

So what? It's not like I recommend Pidgin to anyone, ever. It's just that I don't fancy breaking Pidgin for no good reason, that's all.

(And Pidgin just being an example, of course.)

not for no good reason, but you also wouldn't want to hold everything else back just for pidgin compat

it's a balance I guess

Last commit seems to be less than a month ago tho

No I agree - breaking a client isn't a good idea. My point is more the reason pidgin is used - even if it's ONLY for xmpp - is because it's installed by default on the majority of popular distributions.

moparisthebest: This was about offering <session/> (as a no-op). This doesn't hold back anything.

It can't really be removed at this point, but adding <optional> allows it to be skipped by aware clients

Yes I'm all for <optional/> (and ejabberd adds it as well).

Without <optional/> it does hold back saving that round trip of course.

Holger I don't think Pidgin cares about optional.

:P

Clients that don't know about <optional> pay the round trip price.

Maranda: Of course not.

And it will say "error initializing session" if it's not offered as well lol.

Maranda: Yes. Optional is the way to allow modern clients to save the round trip without breaking old ones.

(Am I not stating the obvious?)

I'm not sure if I should change the default of legacy session offering back to true.

Why not?

I suppose so.

Holger, I didn't consider Pidgin would break, I should have probably.

Well I'm obviously not complaining about an oversight, just about an "it's fine to break old clients" attitude.

Holger, oh I didn't want to break anything I didn't expect it to break :P

Can we fight over dialback instead?

zash: you can fight with me!

Zash: It should die who cares about old servers!!

Kill it with fire!

Or at least get xep-0178 to match whatever current consensus is

Yeah 0178 should be fixed.

Next issue we ran into with Dialback is 0198 feature negotiation.

Because it's not advertised on unauthenticated connections? And there's no advertising at all after authentication-by-dialback

0198 says "negotiate when authenticated" Dialback says "go go go when authenticated!".

Zash: Right.

Which means it has to be advertised before auth

Or limited to connections with SASL EXTERNAL

I wonder if BIDI didn't have some similar issue

In at least one of those cases I just went with EXTERNAL-only

Yeah I think I'm going for limiting it to SASL EXTERNAL. So I'm back to "burn Dialback with fire".

well yes you can't use db on the same stream for bidi.

You need to open another.

holger: mind you, in the past when those specs were written the percentage of servers that had usable certificates was single-digit

fippo: Yes, sure :-)

Some things do improve.

Holger, or it's even worse maybe....

no it's not.

(Then again, if the attacker can mess with DNS to circumvent Dialback he can also get a Let's Encrypt cert, no?)

holger: dialback is online. getting a certificate is an offline attack.

Did anyone ever formalise "samecert"?

zash: dwd and me talked about it. i might even have implemented it but not sure if i ever pushed it somewhere

<<Pidgin client working with Lightwitch again (starting ~11:30am CT). Thanks! >>

aww

well if you have BIDI and dialback you need to support dialback errors because the BIDI XEP mandates so anyways

fippo: I might have done a plugin with half of it (in one direction if there's already an open session in the other)

and d-w-d

so if you don't... well I'm not sure what you need to do since db support is advertised right on the stream header yay.

So pretty

brb

if a server only supported the latest state of the art of everything, and no legacy, it probably would interop just fine with all somewhat recently updated servers right?

a server?

Disable dialback and see what happens

yeah

although most servers now do SASL external since alle the free certificateness.

I guess what I'm asking is, if you were writing a server from scratch today, would you support dialback?

I'm thinking you wouldn't have to

yes

moparisthebest, you need it if SASL external fails for whatever reason.

Security related failure, let's proceed anyways!

well or you just, fail

Zash, *security* le like self-signed certificate? CA error? Let me think. Hmm yes let's continue anyways.

how many servers today don't have valid CA signed certs that you actually want to communicate with?

I would hope few to none

could grep through xmpp.net database

moparisthebest: 1/3 according to xmpp.net/stats

or ask holger to grep through his one on messaging.one

oh neat

sure I bet there are a couple with IBR enabled from 2005 or whatever, but you explicitly do not want those to s2s with you

well I said "that you want to communicate with" :)

https://xmpp.net/reports.php#trust

because if your CA isn't included in someone's OS does it make it "not valid"? Just saying trust is one thing validity another me thinks. ✏

moparisthebest, probably you want to communicate with all of them, otherwise you’re like microsoft who think that blacklisting whole IP ranges is okay.

there is essentially 1 CA list, and that's whatever mozilla/google uses

Yay

I'm not really sure what's going on on the reports.php page

is the trust numbers only of those servers that do TLS

because you don't want to talk to any non-TLS ones anyway

ha, or the 1 with the 512 bit RSA key lol

but yea my point is there are whole classes of servers you do not want to s2s with, look at the ones using SSLv2, even SSLv3

Just because someone is on a server that uses SSLv2, do I not want to communicate with them?

yes, all decent servers shouldn't communicate them so they'll fix it or move

Yes, it has weak/no transport security, but does it automatically follow that I would never want to communicate with them? :)

moparisthebest, I think you're confusing security with identity trust. ✏

they are 2 different issues, but both lead me to not want to interop with that server

when dialback got dished out I think it was more about asserting and authenticating identity but that's me, and while the two things may go hand to hand someone may say. ✏

well it also allows for insecure connections, so it's a bit of a mixed bag

Encrypted streams when Jabber was Jabber?

:P

or following short after?

or even now? *eyes cisco.com*

I haven't been around it that long :P

and maybe that's the reason I view it like this

but things that made sense then like dialback, haven't made sense now for a long time, and I see no reason to support legacy code to interop with a server last updated in 2005

moparisthebest: lucrative customer wants to talk to you. they use an ancient jabberd release from the 1800s and support only SSL 3. what do you do?

I guess you could say "I'll talk to you only if we upgrade your server" :P

I once dropped a contracting side job because they wouldn't drop windows XP

moparisthebest, to talk with cisco.com I need dialback, to talk with M-Link I often need dialback because it complains the purpose of my certificate is wrong I suppose (YAY).

ah yes, LE certs aren't technically/strictly valid for XMPP s2s or somesuch

seems like a lot of work to talk to legacy systems that need to burn

Zash: I think they are. Or at least they don't miss that bit that the StartSSL certs missed.

Holger: The bit saying "This is ok as client certificate"?

Yeah.

Web Client Whatever Something.

TLS Web Client Authentication

hmm does xmpp.net not say what IP it's connecting to? or at least v4 vs v6 ?

moparisthebest, I think it can only do v4

due to deployment fubar

ah ok, would be nice eventually to test both like http://ssllabs.com/ does for https

Is anyone aware of any remaining Group Chat 1.0 clients?

Or is can we get rid of that without breaking anything

Zash: didn't you plan to write something to log GC1 joins?

Maybe combined with version-querying the respective client, so we can check if it's just presence desync

I volunteer to run that code on yax.im for a week, and then to make a PR against 0045.

[I feel lucky]

Well I did add some logging already.

Is it already deployed on my server? :>

Probably not

Can I deploy it without restarting the server?

Not running trunk with debug logging enabled right?

Zash: {version yax.im} ✏

sans bot

Zash: yax.im is running Prosody version 0.10 nightly build 460 (2018-02-03, 980d2daf3ed4) on Linux

quoting. It drives me crazy.

Hm, I thought I had that code excracted out already

Ge0rG: Link Mauve did report some numbers that I didn't write down, unscientific as I am.

Or did I dream that?

Wait, let me read the backlog.

Zash: I remember that as well.

I think the number of GC1 clients reported was 0

Ah right, over a period of one week (our debug log retention time) we saw 47 GC1.0 joins, zero of which from a client which didn’t support MUC.

(And only from two bare JIDs in total, but multiple times.)

I'd like to replicate the measurement on my server

https://xmpp.org/rfcs/ <-- a lot of RFCs are missing no?

which ones?