XSF Discussion - 2019-06-20


  1. neshtaxmpp

    moparisbest

  2. neshtaxmpp

    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.

  3. neshtaxmpp

    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.

  4. moparisthebest

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

  5. moparisthebest

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

  6. moparisthebest

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

  7. neshtaxmpp

    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

  8. neshtaxmpp

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

  9. moparisthebest

    neshtaxmpp: and did you follow the link

  10. moparisthebest

    IP doesn't matter ignore it

  11. neshtaxmpp

    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

  12. moparisthebest

    Well then your friend is an idiot

  13. moparisthebest

    Hope he has a good password set up

  14. moparisthebest

    Read sslh docs if you want transparent forwarding with real IP

  15. neshtaxmpp

    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.

  16. moparisthebest

    Nope just sslh docs

  17. neshtaxmpp

    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.

  18. moparisthebest

    How many ways can I repeat myself

  19. moparisthebest

    Sslh docs

  20. moparisthebest

    Transparent forwarding

  21. moparisthebest

    Read docs from sslh

  22. moparisthebest

    Sslh documentation, have a look

  23. neshtaxmpp

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

  24. moparisthebest

    Then I guess you are shit outta luck my friend

  25. jonas’

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

  26. edhelas

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

  27. jonas’

    edhelas, asking nicely, probably

  28. edhelas

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

  29. Ge0rG

    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.

  30. Ge0rG

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

  31. edhelas

    I could have a look at the tasks yeah :)

  32. pep.

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

  33. pep.

    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?

  34. pep.

    let's try to formulate that in the email

  35. jonas’

    yes, the editor team could use helping hands

  36. lovetox

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

  37. lovetox

    its about sending a message

  38. lovetox

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

  39. pep.

    I think that's not the right question

  40. pep.

    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

  41. lovetox

    there is none

  42. lovetox

    thats what the discussion is about

  43. pep.

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

  44. pep.

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

  45. lovetox

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

  46. pep.

    I wouldn't use SCE itself

  47. pep.

    what for?

  48. pep.

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

  49. lovetox

    because you cant decrypt my message if you dont support sce

  50. pep.

    But that's an implementation detail knowing about SCE

  51. pep.

    If you support OMEMO2 you will support SCE

  52. lovetox

    and how do i know if someone supports omemo2?

  53. pep.

    Because they publish their keys?

  54. lovetox

    so you saying putting the info into pubsub for every device

  55. pep.

    urn:xmpp:omemo:0

  56. lovetox

    thats what the discussion is about

  57. lovetox

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

  58. pep.

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

  59. pep.

    how is that bad?

  60. pep.

    "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"

  61. lovetox

    because there are multiple devices

  62. pep.

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

  63. lovetox

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

  64. pep.

    Or any feature at all

  65. lovetox

    and then you have to think about X cases

  66. lovetox

    what if one device only supports X

  67. pep.

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

  68. lovetox

    and the other only >

  69. lovetox

    Y

  70. pep.

    And then MAM..

  71. lovetox

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

  72. pep.

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

  73. lovetox

    you just said we CAN know with pubsub

  74. pep.

    Do you need to know though?

  75. lovetox

    so what is it now

  76. lovetox

    omg

  77. lovetox

    pep. this discussion makes me a bit tired :D

  78. pep.

    hmm?

  79. pep.

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

  80. lovetox

    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

  81. lovetox

    in this case there is no easy way

  82. lovetox

    either you make a hard cut someday

  83. lovetox

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

  84. pep.

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

  85. pep.

    It's just not possible here

  86. lovetox

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

  87. lovetox

    and in a year we switch to send support

  88. pep.

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

  89. pep.

    sce is but an implemntation detail

  90. pep.

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

  91. lovetox

    or that :)

  92. pep.

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

  93. vanitasvitae

    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.

  94. pep.

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

  95. vanitasvitae

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

  96. pep.

    hmm?

  97. pep.

    oh, wow

  98. pep.

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

  99. vanitasvitae

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

  100. vanitasvitae

    (If it was encrypted or not)

  101. pep.

    "you want to know"?

  102. pep.

    You will know, by decrypting it, right?

  103. vanitasvitae

    Yes

  104. vanitasvitae

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

  105. vanitasvitae

    As you probably want to communicate that to the user somehow

  106. vanitasvitae

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

  107. pep.

    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

  108. pep.

    Sure you can do that already without discovering anything

  109. pep.

    There's no need for protocol support here

  110. pep.

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

  111. pep.

    *an

  112. vanitasvitae

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

  113. vanitasvitae

    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.

  114. pep.

    that's.. weird

  115. pep.

    Maybe the API is just not what it should be

  116. vanitasvitae

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

  117. vanitasvitae

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

  118. pep.

    With slix I don't need all that

  119. vanitasvitae

    How does slix do listening for elements?

  120. pep.

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

  121. pep.

    "listening for elements"?

  122. vanitasvitae

    Hehe

  123. pep.

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

  124. vanitasvitae

    Ah so slix works rather different to smack

  125. vanitasvitae

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

  126. pep.

    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

  127. vanitasvitae

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

  128. vanitasvitae

    ah okay

  129. pep.

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

  130. pep.

    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

  131. vanitasvitae

    I see

  132. vanitasvitae

    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?

  133. pep.

    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

  134. vanitasvitae

    I'll have to think about that 😀

  135. pep.

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

  136. vanitasvitae

    what tag do you mean?

  137. pep.

    payload, body, replace, etc. etc.

  138. vanitasvitae

    ah

  139. vanitasvitae

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

  140. pep.

    sure

  141. pep.

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

  142. vanitasvitae

    hm i think i like the idea of profiles.

  143. pep.

    There's a bit of handwaving here I agree

  144. vanitasvitae

    How would you signal what profiles a client supports?

  145. vanitasvitae

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

  146. lovetox

    vanitasvitae, there should only one single profile for omemp

  147. lovetox

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

  148. pep.

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

  149. vanitasvitae

    Aggreed

  150. vanitasvitae

    But what about ox? :P

  151. vanitasvitae

    OX:1?

  152. pep.

    sure

  153. vanitasvitae

    Alright

  154. vanitasvitae

    Sounds reasonable

  155. lovetox

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

  156. lovetox

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

  157. nyco

    t-1 min

  158. nyco

    ding

  159. Seve

    Dong

  160. nyco

    \o/

  161. Guus

    hi

  162. nyco

    where's the gavel?

  163. Guus eyes ralphm

  164. ralphm

    Sorry, I was distracted.

  165. ralphm bangs gavel

  166. Guus mentions MattJ

  167. ralphm

    0. Welcome + Agenda

  168. ralphm

    MattJ has sent regrets.

  169. nyco

    :)

  170. Guus

    ah ok

  171. Guus

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

  172. ralphm

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

  173. ralphm

    (last week, I mean)

  174. ralphm

    1. Minute taker

  175. Guus

    oh, from trello, I'm missing something

  176. nyco

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

  177. Guus

    The M-Sec project email. Was that resolved?

  178. Guus

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

  179. Seve

    Doesn't look like

  180. ralphm

    2. Compliance Badges

  181. ralphm

    Where are we on this?

  182. nyco

    we should vote

  183. nyco

    board-only? members?

  184. nyco

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

  185. ralphm

    I don't think a members vote is needed.

  186. Guus

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

  187. Guus

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

  188. nyco

    it's visual design, the more people the better

  189. ralphm

    Guus: you did on May 23

  190. Guus

    I _did_ sent that request, on Thu, 23 May

  191. nyco

    small subset for qualitative feedback large set for quantitative

  192. ralphm

    I haven't seen any feedback

  193. Guus

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

  194. Guus

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

  195. Guus

    Ge0rG - did you happen to have more on this?

  196. nyco

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

  197. jonas’

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

  198. jonas’

    if I may humbly say so from the floor

  199. jonas’

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

  200. Guus

    not a hill for me to die on.

  201. ralphm

    I am ok with a poll.

  202. ralphm

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

  203. ralphm

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

  204. nyco

    good

  205. Guus

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

  206. Guus

    but, sure. Who wants to create a poll?

  207. ralphm

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

  208. Seve

    So do we choose a design already?

  209. ralphm

    :-) it seems so

  210. ralphm

    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)

  211. Seve

    Me as well

  212. Guus

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

  213. Guus

    I have no significant preference.

  214. nyco

    the two others follow the de facto standard for badges formats

  215. Guus

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

  216. nyco

    yep

  217. nyco

    feedback request followup, then poll

  218. ralphm

    WFM

  219. ralphm

    Guus: can you send that reminder?

  220. Seve

    +1

  221. Guus

    Can someone else please?

  222. nyco

    I will

  223. ralphm

    Thanks

  224. nyco

    for the poll, which tool?

  225. nyco

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

  226. ralphm

    not sure. maybe memberbot

  227. ralphm

    3. Fabian Sauter to join SCAM

  228. Guus

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

  229. ralphm

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

  230. ralphm

    Seve?

  231. Guus

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

  232. Seve

    I had the task to reach to him

  233. ralphm

    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

  234. ralphm

    (from 6-6)

  235. Seve

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

  236. ralphm

    I moved the item to the left

  237. ralphm

    4. Roadmap page

  238. ralphm

    Also discussed on the 6-6 meeting

  239. ralphm

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

  240. jonas’

    6-6 meeting?

  241. Guus

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

  242. ralphm

    2019-06-06, as a date

  243. ralphm

    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.

  244. Seve

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

  245. ralphm

    Seve: and that, too

  246. Seve

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

  247. nyco

    not a XEP-only roadmap please

  248. ralphm

    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.

  249. ralphm

    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.

  250. Guus

    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.

  251. Guus

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

  252. Guus

    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.

  253. ralphm

    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.

  254. nyco

    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

  255. Guus

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

  256. nyco

    me too, sorry

  257. ralphm

    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.

  258. nyco

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

  259. Seve

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

  260. Guus

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

  261. ralphm

    5. AOB

  262. Guus

    Vacation is upon us

  263. jonas’

    what is a 6-6 meeting?

  264. ralphm

    jonas’: it is date!

  265. ralphm

    a date

  266. Seve

    Haha

  267. ralphm

    on the calendar

  268. jonas’

    in the past

  269. Guus

    do we need to account for absence?

  270. ralphm

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

  271. jonas’

    I see

  272. jonas’

    nevermind me then

  273. ralphm

    I'm here next week

  274. ralphm

    But this is AOB

  275. jonas’

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

  276. Guus

    I ment it as AOB 🙂

  277. ralphm

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

  278. Guus

    ok

  279. ralphm

    6. Date of Next

  280. ralphm

    +1W

  281. nyco

    ok

  282. ralphm

    7. Close

  283. ralphm

    Thanks all!

  284. ralphm bangs gavel

  285. nyco

    thx all

  286. Seve

    Thank you guys :)

  287. Guus

    Thanks

  288. moparisthebest

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

  289. moparisthebest

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

  290. moparisthebest

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

  291. oli

    moparisthebest: do it (rewrite in Rust) ;)

  292. moparisthebest

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

  293. oli

    wait for MIX and ircv3 ;)

  294. pep.

    And add another few years to the ETA?

  295. oli

    never + a few years = never

  296. pep.

    I knew it! (*does the gesture*)

  297. moparisthebest

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

  298. Zash

    Any Decade Now™

  299. Seve

    Guus, thank you for the minutes

  300. Guus

    Np

  301. Zash

    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)

  302. Zash

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

  303. Zash

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