XSF Discussion - 2019-06-20

moparisbest

my friend server has serious access from 127.0.0.1, brute force from sshd here is log: https://bgzashtita.es/tefter/raw/VbNthqzNKV can someone help.

my friend don't connect from 127.0.0.1, something illegaly connect from 127.0.0.1 and brute force my friend server for my friend password. maybe it is from sslh. can you comment how to compile latest sslh and show when ip is connecting in apache2 to show real ip and stop 127.0.0.1 from internet try connect my friend server.

neshtaxmpp, lol 127.0.0.1 is localhost, ie your friends own computer

but also every ssh on the internet that accepts password auth is bruteforced 100% of the time, fact of life

neshtaxmpp, set up this https://linode.com/docs/security/authentication/use-public-key-authentication-with-ssh/

moparisthebest: my friend server dont connect to him from 127.0.0.1. something from my friend server is using sshd to someone connecr from 127.0.0.1 do you know how to investigate what make 127.0.0.1: here is log: https://bgzashtita.es/tefter/VbNthqzNKV

here is other logs: https://bgzashtita.es/tefter/

neshtaxmpp: and did you follow the link

IP doesn't matter ignore it

my friend dont want use with certificate. my friend want to use with password. he is ok if they try with they real ip. but he is not ok " he dont like " 127.0.0.1 to be used from sshd. moparisthebest you comment " 127.0.0.1 is his own server " so this is serious issue. do you know how can help my friend investigate and block 127.0.0.1 becouse you confirm 127.0.0.1 is his server. thanks

Well then your friend is an idiot

Hope he has a good password set up

Read sslh docs if you want transparent forwarding with real IP

moparisthebest: do you have manuals that can work for debian... like compilong, what is necessary, what permission after compile, what directory, what plugins and etc. so it after make install work. ivan dont speak english so i translate him.

Nope just sslh docs

moparisthebest: some comands to investigate why and how 127.0.0.1 is connecting, when this 127.0.0.1 is for home access. official nobody outside my friend server can't connect from 127.0.0.1, then how is that possible.

How many ways can I repeat myself

Sslh docs

Transparent forwarding

Read docs from sslh

Sslh documentation, have a look

moparisthebest: How many ways can I repeat myself I dont understand them so i cant explain to him..

Then I guess you are shit outta luck my friend

moparisthebest, don’t you have an IRC->XMPP gateway running?

what are the requirements to be part of the organization on Github ? https://github.com/orgs/xsf/people

edhelas, asking nicely, probably

would it be possible to be added to be member of the XSF organisation on Github :3 ?

edhelas: it would probably help to commit to some task, so that nobody gets an impression that you are doing it for the sake of having an organization badge on your profile.

I'm sure the Editor team always needs a helping hand

I could have a look at the tasks yeah :)

vanitasvitae, I'm not sure I understand the discussion with disco for SCE?

Why would you need that. You'll have <eme/> with a namespace, and that namespace will tell you what encryption mechanism, and the encryption mechanism will be a profile of SCE, no?

let's try to formulate that in the email

yes, the editor team could use helping hands

pep., its not about detection if you receive a message

its about sending a message

you cant know if the recipient supports full stanza encryption or not

I think that's not the right question

You can know if somebody supports $encryptionMechanism, because they will be a dicovery mechanism for it most likely, just as OX and OMEMO have their key published

there is none

thats what the discussion is about

And all you care about is if somebody supports $encryptionMechanism, that will use SCE. You don't need to know about SCE itself

lovetox, well there is none because nobody is using SCE atm

yeah and the email is about how one can discover if a client can use SCE or OMEMO V2 or whatever

I wouldn't use SCE itself

what for?

You only need to know if somebody supports OMEMO2, that uses SCE

because you cant decrypt my message if you dont support sce

But that's an implementation detail knowing about SCE

If you support OMEMO2 you will support SCE

and how do i know if someone supports omemo2?

Because they publish their keys?

so you saying putting the info into pubsub for every device

urn:xmpp:omemo:0

thats what the discussion is about

and its not as bad as in disco info, but still bad

Skimming through the thread though I really feel like it's not focusing on the right questions

how is that bad?

"Hey you want to talk to me, you know where to check for my keys. If there's nothing there, maybe I don't do $encryptionMechanism then"

because there are multiple devices

sure, well that's already an issue with any e2ee thing

you need to determine a overall state, from all devices, implement logic according to it

Or any feature at all

and then you have to think about X cases

what if one device only supports X

You don't want to do that because as mentioned, carbons etc.

and the other only >

Y

And then MAM..

yes so its useless that there is one device publishing that it is omemo2 capable

You don't care if only one device supports it because there's no way of knowing

you just said we CAN know with pubsub

Do you need to know though?

so what is it now

omg

pep. this discussion makes me a bit tired :D

hmm?

I'm sorry it's the first time I go through this myself, I have seen it before though

yeah i noticed :) just think about it from the point of a developer wants his users to have a flawless conversion to a new standard

in this case there is no easy way

either you make a hard cut someday

or you implement lots of hacky logic that depends on multiple things, and will fail from time to time

I think if you want "perfect" you need to control the whole ecosystem

It's just not possible here

yeah i would propose all clients impl read support for omemo with sce

and in a year we switch to send support

I'm sorry I'll repeat but "omemo with sce" doesn't mean anything

sce is but an implemntation detail

"omemo:0" that will be, I guess :)

or that :)

(to clarify a bit, "384 with sce" doesn't mean anything*, is what I wanted to say)

pep.: the main point is, that xmpp has a lot of features. A client implementing sce would need to be able to properly handle all the features it supports additionally in an encrypted context.

What I'm saying is, a client won't implement sce by itself

Therefore it may be desirable to negotiate features like "i understand sce, but only for body, chat state and feature xyz"

hmm?

oh, wow

I wasn't even thinking about that, but now I'm confused

If you receive a message with a chat state notification, you want to know if it was contained inside a sce element or not.

(If it was encrypted or not)

"you want to know"?

You will know, by decrypting it, right?

Yes

Yeah but all your listeners need to be modified to differentiate between a protected message correction and a plain one.

As you probably want to communicate that to the user somehow

Like "watch out, this message correction was not encrypted"

Yeah no that was the part I didn't really understand, and even now that I have this missing piece of info, I still find this overkill

Sure you can do that already without discovering anything

There's no need for protocol support here

A client parsing a e2ee payload using sce will know what is and what isn't in the container

*an

That was my initial impression as well, but some people suggest it may be more complicated

Take smack for example. Literally all listeners in smack need to be rewritten to carry some sort of security information that tell the user how the triggering element was encrypted.

that's.. weird

Maybe the API is just not what it should be

For that reason it may be good to gradually start an implementation with just a subset of the features.

The thing is, that an sce message can contain encrypted and unencrypted elements at the same time

With slix I don't need all that

How does slix do listening for elements?

I mean I don't have an implementation of a container, but I see more or less how I could do it

"listening for elements"?

Hehe

You don't, you have a Message object and you lookup what you want to

Ah so slix works rather different to smack

in smack the user registers listeners for certain events and gets notified when a stanza for that event is received

There are also signals sent if your message contains X or Y, but most likely in a client you'll want to ignore these, and only use the helpers from the library

like for example if a chat state arrived, that will cause a listener to be fired

ah okay

Yeah you could also do that in slix, but I don't like it

Because then if I fire an event for "message" and an event for "eme" with the same message, now I have to have more global state in my app to know these are the same messages

I see

So you suggest that SCE should be coupled to a new OMEMO namespace which then infers that the client knows how to handle any element inside the SCE content?

Maybe I'm missing some part of the picture, but I think SCE should be used by itself. It should be like 373/374, be used as profiles

I'll have to think about that 😀

For the encryption mechanism. What tag then goes inside is up to the sending client I guess?

what tag do you mean?

payload, body, replace, etc. etc.

ah

ideally the sending client would put all elements inside the content, that do not concern the server.

sure

The receiving client will know what's inside the encrypted payload, and can accordingly display a warning or not.

hm i think i like the idea of profiles.

There's a bit of handwaving here I agree

How would you signal what profiles a client supports?

I think the best way is to couple that information with the published keys somehow.

vanitasvitae, there should only one single profile for omemp

really we should not get into the situation that one resource supports X and another Y

yeah, it'll be urn:xmpp:omemo:0, that is a profile of SCE

Aggreed

But what about ox? :P

OX:1?

sure

Alright

Sounds reasonable

and yeah except for a gajim plugin there is no support in the wild for OX, so i think OX is easy to update

ah and your smack impl, but i dont know if you published it

t-1 min

ding

Dong

\o/

hi

where's the gavel?

Sorry, I was distracted.

0. Welcome + Agenda

MattJ has sent regrets.

:)

ah ok

nothing for the agenda for me. I neglected to read up the chat logs for the last three meetings (that I missed)

For the record, there was no meeting. Instead I discussed infra with MattJ.

(last week, I mean)

1. Minute taker

oh, from trello, I'm missing something

I've missed meetings as well, sorry, and did not read minutes

The M-Sec project email. Was that resolved?

I'll do after-the-fact minutes of this meeting

Doesn't look like

2. Compliance Badges

Where are we on this?

we should vote

board-only? members?

board-only is fast but non-democratic members is longer, but safer meaning collective intelligence

I don't think a members vote is needed.

... Did I sent a call for feedback, as I promised on this?

(if so, it didn't get any feedback. If I neglected, shame on me)

it's visual design, the more people the better

Guus: you did on May 23

I _did_ sent that request, on Thu, 23 May

small subset for qualitative feedback large set for quantitative

I haven't seen any feedback

we've got no feedback. I'm unsure if asking for a vote would result in any meaningful feedback, tbh.

Design shouldn't be a democratic endeavor, I think.

Ge0rG - did you happen to have more on this?

design process, agree design decision: the masses decide, one way or another (adoption vs rejection)

I think a poll from the members to get an impression should be done

if I may humbly say so from the floor

the members voted for the XMPP logo (IIRC?), and I think that should also happen for the CS badges

not a hill for me to die on.

I am ok with a poll.

But I wouldn't make a big deal on this.

I.e. we could reiterate the request for feedback. If there is no response, again, we can just choose a design as Board.

good

Ge0rG suggested requesting for feedback, rather than 'picking one', to improve the existing designs (as a prelude to choosing one) iirc

but, sure. Who wants to create a poll?

A good suggestion, but it seems no one so far has cared to provide any.

So do we choose a design already?

:-) it seems so

From what I've seen, the proposals in Guus' mail are all work in progress. I have a clear preference for the direction suggested by mray (https://opensourcedesign.net/jobs/jobs/2019-03-19-design-of-badges-for-different-xmpp-compliance-levels)

Me as well

Note that there's a good chance that we've lost his attention span

I have no significant preference.

the two others follow the de facto standard for badges formats

I badly want to avoid us taking the rest of this meeting discussing this though. Can we do this out-of-band?

yep

feedback request followup, then poll

WFM

Guus: can you send that reminder?

+1

Can someone else please?

I will

Thanks

for the poll, which tool?

(fast answer or none, so we go to the next agenda item)

not sure. maybe memberbot

3. Fabian Sauter to join SCAM

If google forms can include pictures, that might be handy.

from an earlier meeting I remember that we'd ask him for his motivation to join, beyond just wanting to

Seve?

I don't recall this, but it seems sensible. Did we relay that request to him?

I had the task to reach to him

ralphm: Seve can you ask him to expand on what he wants to do on SCAM? Seve: Yes, I will try to reach to him

(from 6-6)

I didn't send him an email unfortunately, I will do that right after the meeting, my bad.

I moved the item to the left

4. Roadmap page

Also discussed on the 6-6 meeting

I'll send an e-mail to ask Council what they'd want to do with this.

6-6 meeting?

Although I'd be happy for Council's feedback, i feel that this is a Board thingy

2019-06-06, as a date

Guus: given that Council is the body regarding our core business, standards development, and the current page lists mostly items concerning those, I think it more than just a Board thingy.

We can decide on XSF topics, but I wonder if we can put ourselves some roadmap for XEPs

Seve: and that, too

So I guess it depends on what kind of roadmap are we talking about

not a XEP-only roadmap please

A goal could be, for example, to get more of our specification to move forward in the process, with a focus on certain (groups of) XEPs.

The original topic is whether we want to link to the Roadmap page, and the question then became two-fold: 1) do we still want a formal roadmap, 2) what should be on it, if so.

The XMPP Council is the technical steering group that approves XMPP Extension Protocols. It can have it's own goals, but the XSF roadmap should, in my opinion, be driven by Board - with backing from the community / membership, of which Council is an important part.

I think we should want one, but I fear we currently lack momentum to follow through on it.

As long as it takes us months to decide on something simple as a badge design, I fear that formalizing a roadmap is a bridge to far.

The point I tried to make, and I think Seve, too, is that we don't, as an organization, *create* standards. We take proposals from the community, and then foster their standardization, weighing them against other similar proposals, and the existing set of specifications.

1/ yes, absolutely, we want, they want a roadmap, gives a general idea on our direction, no need to be precise though 2/ we should put non-tech-only content, but also maybe community, business, communication, whatever, I d'ont know yet, knowing that tech is our main thing

I'm pressed for time, and this meeting is running over.

me too, sorry

Ok, Let's pick this one up next week. Please all think about what, if anything, *concretely* could be on here, but I'm with Guus that I'm not optimistic about us getting anywhere with it.

anyway, our currently online roadmap is outdated, I suggest to start from here and revise it

We may want to put it offline in the meantime, while a decision is being made.

we should prevent this turning into the 'setting priorities' thingy from last year.

5. AOB

Vacation is upon us

what is a 6-6 meeting?

jonas’: it is date!

a date

Haha

on the calendar

in the past

do we need to account for absence?

jonas’: yes, a reference to what was discussed before

I see

nevermind me then

I'm here next week

But this is AOB

(I somehow thought it was board+council, but that doesn’t make sense now because we’re just 5 people each)

I ment it as AOB 🙂

oh, well, generally we just keep the calendar going. If we don't have quorum, no meeting.

ok

6. Date of Next

+1W

ok

7. Close

Thanks all!

thx all

Thank you guys :)

Thanks

I don't currently run it jonas’ but https://github.com/moparisthebest/xmpp-ircd

it "works", no authentication (like nickserv) is the reason I currently don't run it

but also before I touched it again I'd rewrite in Rust, so, have at it :)

moparisthebest: do it (rewrite in Rust) ;)

it's pretty far down on my list, ETA "years to never" :/

wait for MIX and ircv3 ;)

And add another few years to the ETA?

never + a few years = never

I knew it! (*does the gesture*)

yea so you could say it's got the same ETA as MIX >:)

Any Decade Now™

Guus, thank you for the minutes

Np

Hm, when unblocking a JID per XEP-0191 it says you should send the JID your current presence (assuming they're allowed to see it)

However it doesn't say anything about the previously blocked JIDs presence

Is it implied that you probably wanna re-probe or somesuch?