XSF Discussion - 2020-03-03

jonas’, thanks for the lengthy and detailed response about Reminders. I really appreciate it

you’re welcome

So, since I’m now doing an internship, I probably should change my member status.

How can I do that?

Also hi, I’m adding XEP-0284 support to Inkscape. o/

Link Mauve, member status?

jonas’, the employer thing.

I just edit my wiki page

I don’t have one yet. :-°

Link Mauve, yeah, xep284 is one of my all time favorites (along with the gobby protocol)

What are the differences between them?

you may want to compare those two from a protocl perspective, although the gobby one isn't that well documented IIRC

Also with other protocols such as Etherpad’s or CryptPad’s?

I have no idea which one is better. But it could be worth putting some research effort into a survey of the existing protocols for collaborative xml editing

Yeah.

And then merge all of the improvements into XEP-0284. :p

stay away from etherpad

it uses the broken JavaScript unicode model

with UTF-16 everywhere.

if you have to stay away from broken javascript that's like 99% of the web

though now that you mention it, sounds kind of nice...

I've heard there are still parts of the web that you can surf with noscript.

s.j.n for example

though you won’t get the fancy charts

jonas’, I’m using XMPP, so UTF-8 everywhere.

Link Mauve, the etherpad protocol data model assumes UTF-16

so stay away from that

Ok.

nothing is wrong with UTF-16. It's only when you treat it as UCS-2 when things start going wrong.

is https://xmpp.org/software/servers.html a pretty complete list still? does anyone know of widely deployed public servers not on this list?

In the XEP schema, <dl/> is specified as only taking a list of <di/>, each containing a <dt/> and a <dd/>.

The <di/> is not specified in XHTML AFAIK, why is it present here?

XEP ≠ XHTML tho

But the XSLT transfers the <di/> to the generated HTML5.

As is.

That sounds like a bug

Indeed.

I’ll use it in the meantime, but I’ll keep it in mind.

other than prosody, XMPP servers seem very bad about having a place to report security problems...

ejabberd and tigase just link to github issues, openfire links to a forum and public issue tracker

Link Mauve, feel free to file an issue and/or patch

isode, iot broker, astrachat nothing at all

apache vysper joins prosody in having a very visible defined way to report security issues

jonas’, https://github.com/xsf/xeps/pull/900

moparisthebest, maybe report them the issue?

and the rest have a developer email/jid if you dig deep enough, which isn't *terrible*

Link Mauve, looks good, I’ll add it to the queue for tonight

Link Mauve, right, how :D

moparisthebest, using a normal issue I guess? ^^'

moparisthebest, you could use a normal issue to report the problem that there’s no security contact.

though github issues nowadays also have a way to be hidden for security reasons, IIRC

Oh, do they?

And the 3 servers that have no way to contact anyone at all?

Email sales?

fulldisclosure@seclists.org

I don't think I care that much, if they don't, why should I

I'll just post it on a blog or something and if they are vulnerable to a 0 day maybe they'll create a security email :)

Isode provides snail mail, phone, fax and email (through web form) contact details on the website, and customers obviously have a support system to submit things through. So I think 'nothing at all' in terms of ability to get in contact is pushing it a little bit.

and no place to report specifically security issues, I guess a web form might go to someone who could handle them, it's not obvious though

Any (provided) contact mechanism would ultimately end up at someone who could handle the query.

Or if you think you've found a vulnerability in M-Link, feel free to just bypass that and email me. ✏

in this case it's more of a general bug that may affect multiple servers, but just in general having a dedicated security problem reporting method is ideal

It's not clear to me that it would be any more useful than the generic contact details, TBH.

I can see how for an OSS project where the contact details are "Open a public ticket viewable by the world" it would be.

Kev, in 90% of the companies, the generic contact form will end up at a clueless person who deflects your request or it takes ages to proceed

having a proper security contact is superior to that

https://www.apache.org/security/ this is considered a good way to handle it

jonas’: I don't believe that to be true at Isode.

In fact, I believe we have precisely 0 clueless people on staff.

https://www.astrachat.com/Contact.aspx for example only has sales emails

Kev, but as a security researcher, you can’t know in advance

https://letsencrypt.org/contact/ https://prosody.im/bugs/ also examples of prominent "security issues go here"

moparisthebest in case of Tigase you can use contact form here https://tigase.net/technical-support (3rd option, though naming may be confusing); besides - due to size and how we handle communication internally we didn't/don't fee that dedicated security channel was required

Wojtek, the "If you have our support subscription use the form to send us a message" button?

you give example of LE, and even they put a bold: "Please do not write to this address unless your message concerns a security issue with Let’s Encrypt." because, from experience, when you put an email in public place, it's quite often spammed with people ignoring it's intend sadly ¯\_(ツ)_/¯

yes, this one (as I said - naming may be confusing - I'll forward your suggestion to relevant person)

ah yea, I would not have used that unless you said :)

sooorryyy :-)

in general support without subscription should go to github :-)

btw. wasn't there a XSF security mailing list?

there is still, maybe. Seems abandonned though

yeah, but it also seems public so I'm not sure it's viable in this case (I *thought* that it wasn't, or at least it's archive wasn't)

@moparisthebest could you ping me on xmpp:wojtek@tigase.org ?

there was a server-devs mailing list which was created and then used for the dialback bugs.

unused since probably

Indeed, but is intended for this type of thing.

did those bugs let you crash a good amount of public servers though?

that sounds fun

crash as in crash?

as in total DoS?

this probably shouldn't be public until fixes are out, I've sent it to a number of server devs so far

via s2s or authenticated c2s or unauthenticated c2s?

yeah

no data leaks, just crash (thankfully?)

sounds like something to embargo

no crashes, it was an authentication bypass.

unauthenticated c2s :'( (probably s2s also)

It wasn't a crash, it was an authentication bypass.

Heh.

also just checking: its not a variant of billion laughs?

I haven't heard of that

moparisthebest, ouchie

https://en.wikipedia.org/wiki/Billion_laughs_attack -- there was an xmpp variant of it as well

moparisthebest, billion laughs is exponential entity expansion. define an XML entity &foo; which expands to &bar;&bar;, define &bar; to expand to &baz;&baz; and so on.

ah, now that's nice, but no this isn't the same

aren't XMPP parsers not supposed to handle undefined entities? ✏

pep., and, more importantly, not supposed to handle entity definitions ;)

Indeed.

right

Not quite the same as people doing the right thing, though :)

pep., as we all know, people take shortcuts when implementing stuff

and if the shortcut is "not configuring your parser properly" ...

Indeed

well, this came up again a couple of years after the initial CVE. Happens all the time.

now those are some hilarious links https://www.cio.com/article/3082084/xml-is-toast-long-live-json.html https://github.com/kubernetes/kubernetes/issues/83253 "CVE-2019-11253: Kubernetes API Server JSON/YAML parsing vulnerable to resource exhaustion attack"

relevant: https://noyaml.com

When I got my dozen of xmpp clients CVE, I contacted all the developers manually