We really need to move beyond having half the board every week
millesimushas left
millesimushas joined
werdanhas joined
arc
Ralph?
MattJ
I'll send an email about some stuff, and this
sebastianhas left
sebastianhas joined
arc
Thanks. If we need to move to monthly, longer meetings so be it. Its just frustrating to set time aside every week and most of the time we don't have attendance
dwd
Ooops. I am here, too, just distracted by Something Interesting I FOund On The Internet.
arc
Ok so, agenda?
dwd
Agenda, I cannot help with. But:
chronosx88has left
chronosx88has joined
arc
Fiscal sponsorship update.. CoC..
dwd
* Financial Host stuff: I think we're waiting on Peter, though Sam has been pushing forward with draft policies etc.
MattJ
There is a pending PR for review
dwd
* CoC: I'm just coming to the end of my notice period, which has been pretty disruptive (and the job hunting bit beofrehand), so will get back onto this and the associated Provacy Policy I think we should have.
MattJ
I'd also like to work out what the next steps are on the CoC stuff
MattJ
:)
MattJ
Thanks!
dwd
On a personal note, I will be changing employer at the end of the month. As part of this change, I'm dropping to 4 days a week, and I'm aiming to generally use that "extra" day for XSF and OSS stuff.
MattJ
Congratulations :)
arc
Nice
Kevhas left
arc
Ok, aob?
Kevhas joined
dwd
No, though I do have some thoughts/research on CoC I'd like to discuss.
MattJ
I think that was everything
ti_gj06has joined
arc
Go ahead
dwd
Primarily, we previously talked about a CoC based aorund positive behaviour we wanted to see. However, the research I've managed to do so far actually recommends against this.
dwd
This is somewhat to my surprise, to be honest.
Andrzejhas left
arc
Why is that?
dwd
The argument is that it is easier for a bad actor to claim their behaviour is, for exampe, respectful ("But they're just deliberately taking it badly") than to argue it is not, for example, an ad-hominem attack.
Kevhas left
Kevhas joined
arc
I totally get that. But do we really want to be in a position to parent bad actors?
dwd
No.
pjnhas left
dwd
I'm merely saying that Codes of Conduct seem a lot more complicated than i'd hoped, and opnions seem generally divided on how to write them.
arc
100%
BASSGODhas left
dwd
Anyway, it seems that any code of conduct we put in place is very likely to upset a bunch of people, and not only the people whose behaviour would be affected by a CoC.
MattJ
I've seen advocates of both styles. I can't claim to know the best option - I would personally prefer a positive-leading one, but I understand the concerns with that. My concern with a list of bad behaviours is that there is a potentially infinite list of such behaviours.
dwd
That's not to say we shouldn't put in place a CoC, but we need to manage the entire process carefully.
archas left
archas joined
MattJ
https://www.contributor-covenant.org/ (originally posted by Sam) seemed good to me at a first glance, it struck me as a decent balance of both
dwd
Yes, but it's been a focus of political ire as well. Broadly adopted as-is by the Linux kernel community, and that met with quite some resistance.
dwd
There's also the Debian one, which seems to have been mostly controversy-free, but might not have been as effective as people would have liked.
BASSGODhas joined
MattJ
The Debian one controversy-free? :)
Steve Killehas left
dwd
Anyway, I'm broadly leaning toward something like the FLOSSUK one - https://www.flossuk.org/about/code-of-conduct/- that seems to state aims in terms of positive behaviours, and then gives a non-exhuatsive list of bad behaviour.
MattJ
Not from the mailing lists I'm on
Steve Killehas joined
Steve Killehas left
Steve Killehas joined
MattJ
I've yet to see a CoC adopted at any org without controversy
meetpal_sangrahas left
MattJ
But you know, we can be the first :)
dwd
MattJ, We can hope.
archas left
archas joined
archas left
archas joined
archas left
archas joined
arc
Sounds like we have reached the end of the meeting?
Kevhas left
Kevhas joined
dwd
Yes, sorry. Kind of rambling on a bit.
arc
These are important conversations
arc
But it sounds like we've come to a close so
arc
+1w?
dwd
Sounds good.
pjnhas joined
arc
Things the virtual gavel
arc
Bangs
Kevhas left
Kevhas joined
arc
I have been driving so I'm on voice and put
meetpal_sangrahas joined
govanifyhas left
govanifyhas joined
govanifyhas left
govanifyhas joined
Kevhas left
papatutuwawahas joined
Kevhas joined
arc
Input
arc
I also serve on the board of the neighborhood community garden which meets every week at 10:00 a.m.! 😅
BASSGODhas left
govanifyhas left
govanifyhas joined
govanifyhas left
govanifyhas joined
arc
Meetings here are far less exciting than XSF board meetings. I'm the youngest member of this board by about 20 years
govanifyhas left
govanifyhas joined
BASSGODhas joined
govanifyhas left
govanifyhas joined
govanifyhas left
govanifyhas joined
archas left
archas joined
govanifyhas left
govanifyhas joined
govanifyhas left
govanifyhas joined
wladmishas left
pjnhas left
andrey.ghas joined
govanifyhas left
govanifyhas joined
pjnhas joined
meetpal_sangrahas left
Wojtekhas left
govanifyhas left
govanifyhas joined
debaclehas joined
govanifyhas left
govanifyhas joined
meetpal_sangrahas joined
wladmishas joined
marc0shas left
marc0shas joined
govanifyhas left
govanifyhas joined
govanifyhas left
govanifyhas joined
govanifyhas left
govanifyhas joined
Yagizahas left
wladmishas left
Andrzejhas joined
moparisthebest
so I accidentally discovered a DNS-only DOS against ejabberd, but also, my guess is, most other XMPP servers
Yagizahas joined
moparisthebest
so here's the question, on outgoing S2S, if you don't *receive* anything over the connection, how can you be sure you are connected to what you should be ?
xutaxkamayhas left
xutaxkamayhas joined
moparisthebest
do you... try to receive data on the connection and if you receive anything at all, abort it and move onto the next SRV record ? or what ?
moparisthebest
how do you avoid the case where someone who only controls your DNS, or someone who only controls a route between you and 1 of the SRV records, can entirely block your ability to connect to the remote domain ?
MattJ
Mmm, that's not really preventable, is it? :)
MattJ
If they control it they can drop DNS/SYN
moparisthebest
yea possibly DNS isn't able to be worked around, what about the second case though ?
moparisthebest
you have 2 SRV targets in different locations, an attacker who controls only the route to the lowest priority one shouldn't be able to prevent you from falling back to the second, right ?
BASSGODhas left
archas left
archas joined
karoshihas left
archas left
archas joined
moparisthebest
right now, with ejabberd, and I suspect most other servers, if you redirect the first to an HTTPS server for instance, the second is never attempted
moparisthebest
(I accidentally broke all incoming federation from ejabberd servers to mine this way :))
karoshihas joined
pjnhas left
pjnhas joined
moparisthebest
c2s doesn't suffer from this problem because it's bi-directional
govanifyhas left
govanifyhas joined
Kev
But C2S does suffer the same problem.
Kev
If you can drop someone’s connections, you can drop someone’s connections.
BASSGODhas joined
Kev
Or I’ve not understood properly.
moparisthebest
dropping is easy, you can fallback to the next SRV record
Kev
When, though?
moparisthebest
and if you've validated the TLS properly, and get valid XMPP, you are connected to a c2s port
Kev
If you connect and authenticate to the server ok, and then it drops, you shouldn’t drop back to the other SRV should yoU?
moparisthebest
how do you determine if you've connected to a valid s2s port though
Kev
It doesn’t matter, does it?
Kev
If your transit is malicious, it will allow enough through to cause you to authenticate, and then terminate.
Kev
(Which is much easier with C2S than S2S, because of rountrip counting)
Kev
And because you had a live connection, you won’t fallback.
Kev
So even “If I didn’t manage to authenticate, fallback” doesn’t save you there.
moparisthebest
what's the point of SRV records if having the first one misbehave blocks you from trying the rest ?
Kev
What does ‘misbehave’ mean though?
govanifyhas left
govanifyhas joined
moparisthebest
so maybe it needs some consideration in c2s too "if the connection is "too flakey" (todo: define "too flakey") fallback"
moparisthebest
misbehave as in anything someone not in control of the TLS certificate can do
Kev
Flakiness protection is horrible, but it’s what you’d need here, yes.
Kev
(And the same for S2S)
archas left
archas joined
govanifyhas left
govanifyhas joined
Kev
We actually do have protection against this sort of thing for our X2X support, but less so for S2S.
Kev
(Because, as you noted, bidirectional)
moparisthebest
so what's a start for defense against this in S2S? only what I mentioned?
> try to receive data on the connection and if you receive anything at all, abort it and move onto the next SRV record ?
Kev
afk sorry
moparisthebest
I guess that brings back my question from the other day, do any XMPP servers in the wild ever send anything over normal (non-bidi) incoming S2S connections ?
BASSGODhas left
BASSGODhas joined
ti_gj06has left
Andrzejhas left
archas left
archas joined
archas left
archas joined
MattJ
Except for stream header, stream errors, stream close, and potentially 198 or whitespace... no?
ti_gj06has joined
chronosx88has left
chronosx88has joined
ti_gj06has left
mukt2has left
marc0shas left
marc0shas joined
marc0shas left
marc0shas joined
govanifyhas left
govanifyhas joined
govanifyhas left
govanifyhas joined
Kev
Matt - I saw you removed dwd from Prosody, was that just getting rid of dialback stuff, or you found security issues, or …?
Kev
(Or did I misread the release notes)
Zash
Only the part that's mostly equivalent to SASL EXTERNAL
Kev
Hmm. Is it?
dwd
I kept calling it LUA.
Zash
Kev: It had a security issue, but we opted to remove it. We don't have any test coverage and poor confidence in it working correctly.
moparisthebest
MattJ, I think they only send pre-TLS stuff, after TLS is started it seems even stream errors are sent over the other connection ?
Kev
Stream errors always have to be sent over the stream they relate to.
Zash
And by "equivalent to SASL EXTERNAL" I mean that it could optionally check your dialback request against the cert and short-circuit it.
govanifyhas left
govanifyhas joined
Zash
It was disabled by default and I don't think I ever saw it used.
moparisthebest
I'll have to test again, I swear I saw them being sent over the other one...
Zash
Not sure if it was even documented.
Kev
I’m not going to say you didn’t see it - but you shouldn’t have :)
Zash
moparisthebest, dialback stuff too maybe, in addition to the stuff MattJ listed
moparisthebest
if there doesn't exist a way to *request* something back on the same connection (that won't terminate it, like a stream error), maybe that's the solution
Kev
198 can request traffic.
moparisthebest
a simple ping, but on this s2s connection
MattJ
moparisthebest: a solution, but I'm not sure I understand the problem
chronosx88has left
chronosx88has joined
Kev
I don’t think it’s a solution to the proposed problem, if we’re still on “transit terminates your connection as a DOS"
moparisthebest
the problem is, once an S2S connection is established, and TLS verified, how do you detect if you are actually connected to an XMPP server, or something else (like HTTPS)
moparisthebest
because if you aren't you need to fallback to the next SRV target
Kev
If you’re not connected to S2S you don’t get stream headers?
Kev
And if by ‘established’ you mean you’ve already authenticated, doesn’t that mean you already know you’re S2S?
moparisthebest
the pre-TLS ones ?
Kev
The post-TLS ones.
mukt2has joined
Kev
But the pre-TLS ones if you’re doing starttls mean you’re talking to XMPP too.
BASSGODhas left
APachhas joined
moparisthebest
not necessarily
moparisthebest
an evil MITM in front of that target could fake XMPP before TLS, then just redirect traffic from an HTTPS server with the proper certificate
Kev
That would be why you bin everything once you start TLS.
chronosx88has left
chronosx88has joined
Kev
(Well, ‘that’ - that you can’t trust pre-TLS in general)
moparisthebest
it does protect against accidental misconfiguration, just not active attacks
moparisthebest
which is why I suspect this bug has lasted so long in SRV implementations, it's just easier to spot with direct TLS
MattJ
It's not really a bug, it's just the internet
chronosx88has left
chronosx88has joined
APachhas left
pjnhas left
moparisthebest
if your SRV implementation connects, tries to send a stanza, gets an HTTP response and the connection is closed, and it doesn't fallback to the next SRV target, that's a bug