XSF Discussion - 2022-02-01

Should we take down xmpp.net until a replacement becomes available? It's hardly useful anymore. Might be doing more harm than good at this point.

Or just yolo flip over to the replacement?

Zash, if you handle the issue tracker

What issue tracker? :)

No issue tracker no problem

probably operators@ ;)

Disable it. Only patches welcome!

I know you're joking, but we can move that to that github repo that now holds the xmpp.net projects.

it goes largely unused anyway

xmpp.net isn't an official XSF project anyway, or?

no - it's sources never lived in an XSF-managed repo either.

of course, 100% of the people working on it are XSF-affiliated... :)

I'm not sure if it runs on XSF hardware - it might?

It does

Is it worth trying to upgrade the root certs on that server, to at least get around the LE failures, or shouldn't we bother anymore?

if the latter, I'd suggest taking it down for now.

the server isn't the problem, the docker container running the thing is

I actually tried upgrading the root cert package in the container but to no effect

you need to upgrade libssl

or remove the expired DST root

I don't _need_ to do anything!

But upgrading libssl isn't going to fly

maybe not flog a dead horse

Here's a handy copy/paste maintenance message that we could put up: https://gist.github.com/pitch-gist/2999707?permalink_comment_id=3984681#gistcomment-3984681

Does it make things easier if I replace index.php in xmppoke-frontend with that?

I suspect that all-round "easier" would be a warning banner that allows the site to still be used

Otherwise we'll be fending off "why doesn't xmpp.net work yet?" complaints endlessly

It's quite a well-used service

oooh, there's a common.php that holds a header

which doesn't include the header :/

What's an appropriate banner text?

> This service has gone unmaintained for quite some time. Results generated by this service might not be accurate.

How about: > This service is unmaintained and a replacement is planned. Meanwhile, results and advice generated by this service might not be accurate.

:+1:

Just unlurking momentarily to say "LGTM".

https://github.com/xmpp-observatory/xmppoke-frontend/pull/14

oh

search/replacing...

force-pushed

I wouldn't know how to roll this out, so I'm hoping for someone else to get to that (eventually).

(also, feel free to discard / completely replace - just wanted to get something tangible started).

I've no idea either, which probably means nobody does :)

Reading this: Can we discuss paying someone to do this task regarding our infrastructure and further with important projects if interference with XSF members is high (xmpp.net)

It was Docker hub builds before, I think

We might try building on the machine, but I don't remember what the environment is like on there these days

That should be doable

emus: I'm not categorically against that, if iteam supports that idea. Unsure if iteam has been / should be given budget for that.

fwiw, I built the /preview/ thing on the machine itself, and it was fine

Building was doable

Now just have to figure out how to replace the running container

Eh, these old scripts

I broke i t

Back

(old version)

Theory: This can't actually be built at all anymore

?!

It reported some PHP path problem

I'm not someone who debugs PHP problems anymore, for the sake of my own sanity.

ugh. Is it doable to shell into that container and apply the changes in the PR manually to each file?

I guess

Guus: `curl | patch` done 🙂

Thank you.

Thank _you_

jonas` mentioned something about removing something on that machine. Would that be easy to do in the same way?

🤷️

ITT: modern humans trying to patch ancient alien technology

Hnnng

I'm a Java dev. Docker is futuristic mumblejumble to me.

https://github.com/xmpp-observatory/xmppoke/blob/master/Dockerfile#L1 I'm going to drink my coffee instead for now

> FROM debian:stretch Wow, it _is_ ancient

don't look at the things it does to libssl

It is possible to look this PR: https://github.com/xmpp-observatory/xmppoke-frontend/pull/11?

Guus, it would have to be removed inside the container, not on the machine.

jonas’ - I know, I was overextending my ask of Zash who was already manually applying changes in the running container to get a warning banner included.

ack

Yes, would be great what iTeam would think about it

any comments from iTeam on this. Would it be appreciated?

Neustradamus, I'm not clear from that PR what the goal was or why adding an extra link is helpful ? that's probably why you got no comments

emus, the board have previously agreed to allocate <undefined> resources to iteam, but requested that the first step would be defining the scope of the work and the resources required to accomplish it

Nobody has done that, and doing so is extra work compared to just doing what we're doing

Which isn't going terribly IMHO

But for example the deployment script for the website?

As I said, I don't believe it's going too badly. From what I can tell, on average the website gets deployed within an hour or two of someone requesting a deployment.

Deployment itself now only takes a minute or so of someone's time

It would be nice if it was automated, but that requires more than a minute of work ✏

Yes sure, it works fine, but still. You shouldnt tdo that. right?

A rare time when there are _two_ relevant XKCD: https://xkcd.com/1319/ https://xkcd.com/1205/

It doesn't bother me that much, I don't know if it bothers the other iteam members to do manual deploys

I know. but also xmpp.net for example. taking it down is not good I think and shows our limitations dunno how many other issues are open

xmpp.net is not an XSF project

It just happens to be hosted on XSF hardware for some historical reason

leaving it up seems far worse considering how it's totally broken ?

Worked on by only XSF people, running on XSF hardware… if it quacks like a duck.

98% of servers can only get a T right?

That's the problem, it's not *totally* broken

Zash: I know, but a certain important thing I think

just broken enough to give the impression there are 0 trusted xmpp servers

(FWIW I agree that leaving it up feels quite bad and it should probably go away, looks really bad as is)

I personally would rather the banner we have now than deal with a flood of complaints about it going away 100% until we get the replacement up

as an aside: outsourcing xmpp.net is probably hard/expensive because of very specific knowledge that is needed to maintain it.

Of course if consensus is to take it down, and someone volunteers to be the point of contact for these complaints... :)

dev_null@xmpp.org

But what's left to "get the replacement up" ?

I would rather move forwards with the new one than turn off the existing one at this point

I know a person who specializes in fixing / maintaining old PHP stuff that the original authors have abandoned; I don't know his rates, but I'd be happy to introduce people if that's something we're considering

We're not considering that

oh, "replacement" not "fixing", nevermind

I mean, there's the secret preview. It works.

PHP is not the issue

Sorry, saw a comment about that a while ago and have just been kind of sort of passively following the conversation.

The whole thing is built around, for example, a patched libssl from 200something

For some value of "works", which may or may not be considered production-ready

I'm not saying that this is a good idea, but if we were to want to outsource xmpp.net, we could ask the original authors for a quote. That said, having a suitable replacement is fine by me - although I do worry a bit that that replacement will eventually suffer the same fate.

We'd at least have had a functional service again before it does, though.

new maintainable partially-works seems better than old unmaintainable known-broken, why not just stand it up ?

there is still the question of what's missing from the 80% working new thing

the main bits missing, IIRC, are handling of edge cases, scoring and the badges ✏

scoring, apparently. Unless 'TBD' is an interesting acronym for a new type of score. :)

I hate the scoring

"How to score 'TBD' on xmpp.net using Prosody"

Is the scoring something that could be done as part of testssl.sh?

the scoring of ssllabs is underdocumented and looks sane at first, but the farther you get down the existing document, the more it becomes just a set of rules for A/B/C/D instead of the sensible percentage/weighting thing they had initially

well right now the only score anyone can get is T right ?

moparisthebest, if you're using LE, anyway

ok, right now the only score 98% of people can get is T right? :)

Mouhahaha "Don't use LE" 👹️

release the new thing giving everyone a T and we haven't lost anything

No, better that T, TBD

moparisthebest, if you wanna poke at it: https://xmpp.net/preview/

and https://xmpp.net/preview/scan/result/19 already seems to exhibit some weird edge case because there's no TLS scan for that one

https://github.com/drwetter/testssl.sh/issues/100 too

huh, glad to have this minimal replacement service available already. I thought TLS 1.0 had been disabled, but apparently not.

code is here https://github.com/horazont/testxmpp/ if anyone wants to ~file issues~ send PRs ✏

I mean that looks great, replace xmpp.net with it already ?

TBD isn't any worse than T

it doesn't seem to do TLS scans on s2s currently for some reason

> "TBD" > "T" true

and to be honest I'd prefer if this wasn't a bus factor one thing

While xmpp.net is bus factor zero?

yes, but it doesn't lie on my shoulders

in case anyone missed it, following the workaround gets you an A again .. https://github.com/xmpp-observatory/xmppoke/issues/10#issuecomment-932029749

https://xmpp.net/preview/scan/result/22 s2s seems to work?

isn't that the case already jonas’ ? but at least this one is maintainable

junaid, right, but that breaks the other set, old Android iirc ?

mellium.chat doesn't seem to have any c2s so the result for that seems expected

one way breaks old openssl, the other way breaks old Android

I don't expect us to get to any kind of ideal scenario. Can we get to an acceptable one, including functional requirements, but also things like jonas’ understandable reluctance to be the bus factor?

junaid, that workaround also locks out older androids (older than 7 IIRC) ✏

Zash, ah ok, then it just took a while. edge cases!

junaid, so it comes down to what the admin prefers: getting nice scores on xmpp.net, or allowing users with older phones to access their service :) ✏

ic ic. not a major problem for servers that primarily will only be accessed via s2s though. but for everyone else, it's gonna be a bit painful.

I'm not sure that catering to people who run outdated OpenSSL is the wisest choice

(or ejabberd)

Then xmpp.net is not broken :)

(mellium.chat is just a MUC/anon auth service, so that all seems right)

i'm following with Zash. score according to modern SSL standards. but maybe we introduce a new section to include some notes about edge cases? e.g. On C2S, "This service certs may not be trusted on Android <7"

ofc the "T" problem needs to be fixed

maybe silly question, but is our actual scoring process formally documented somewhere? or is the code the single source of truth?

what scoring process?

the one used by xmpp.net?

based on an old version of the ssllabs scoring method

jonas’, it seems to choke on my ipv6-only thing

Zash: what didn't build for you earlier today?

> b37bc4b830fa Fatal error: Only IPv6 address(es) for "use.ipv6.cerdale.zash.se." available, maybe add "-6" to /usr/local/bin/testssl > b37bc4b830fa WARNING:testxmpp.testssl.daemon:coordinator rejected our result: {...}

xmppoke builds from scratch for me.

Guus: frontend

ah ok

I'm using podman, not docker, which might be why. It built something on the xmpp.net server, but it did not work correctly.

Zash, meh, it doesn't auto-detect v6ness?

> -6 also use IPv6. Works only with supporting OpenSSL version and IPv6 connectivity

ok

should be easy to add

It also spits out a HUGE reject thing in some pythonesque format that seems too big to paste here

https://paste.debian.net/plain/1229197

yeah, that's ok

MattJ: I am also worried that no task will be touched that should be done, but no one wants to spend time on it. Or ensures we keep up operation/knowledge. Maybe one day people maybe just leave

I think between current iteam members there's not too much that only a single individual knows (or that can't be figured out easily enough)

UI nit: it would be nice if "c2s" and "s2s" were checkboxes and a single report on a single page was created if you chose both.

that's not a nit, that would be a complete data model redesign ;)

(if anyone is or does decide to work on this, that is)

or at least something considerable effort I suppose

Is the data model that tied into the UI?

the data model only knows one type per scan

Anyways, still a nit pick. Doesn't matter how huge the task is if it's a nit pick it's not the end of the world if it doesn't get done, just something that would be nice but doesn't really need to change.

right

But sure, if it's a lot of work probably not worth it for a nit.

(I double-checked, the scan type is an inherent property of the scan)

(though the UI could attempt to tie together s2s and c2s results somehow)

It could just start two scans and all you'd change is the report display code

yep

oops, yes, that

^5

except that I don't like doing much logic in UI code ;)

Sam, feel free to dump it here: https://github.com/horazont/testxmpp/issues/ ✏

I would think the logic would just be "add an <h1>c2s</h1> and print that template, do the same for s2s below it" or something, but obviously I haven't looked at anything in here

oh yeah that'd be simple, though I'd then rather link the other scan

(like the original xmpp.net currently does)

yah, could be as simple as that

I thought you meant something more sophisticated

like comparison tables or somesuch

still, file an issue because I can't work on that immediately

I might be going against my own advice to beat a dead horse, but bear with me: I've modified the xmppoke Dockerfile to now build against the latest HEAD of Openssl's repository (instead of the outdated fork it used up until now). Openssl builds without errors, with largely the same configure arguments. Is that expected to resolve the 'we need to update libssl' requirement?

wilco; no pressure obviously, was just a thought because on xmpp.net and this I pretty much always immediately start both

Guus, but the outdated fork was intentional, to get SSL 2.0 support

Do we need to know exactly what versions of old SSL are supported? Maybe just show newer supported things and then say "we got an error that an old no-longer-supported thing is used too! This is bad!"?

How does the replacement service offer SSL 2.0 support?

Guus, it uses testssl.sh and I don't know how it does that check

testssl.sh being an active project that we can use instead of duplicate (it's similar to xmppoke in scope) seems like argument enough for the replacement

I'm not against a replacement at all. I'm just experimenting if with less effort, we can revive aforementioned dead horse.

or at least make it slightly less dead.

If that'd only mean loosing SSL 2.0 support, then I'm with Sam. If I can get it to run at all, that is.

huh, my domain does not want to show up in the s2s tests list on the preview even though I'm pretty sure the scan has completed successfully twice (not that it matters, just FYI)

although I'm now running into issues with building luasec, I think

Guus, it's outdated forks all the way down I'm afraid

Sam, did you put your user jid in there?

just the domain

https://xmpp.net/preview/scan/result/29 how did this happen then?

oops, weird, maybe I typed it wrong the first time. Either way, this one worked: https://xmpp.net/preview/scan/result/30

Seems the testxmpp preview doesn't like direct tls on port 80 ^^ Although I checked with a client that it works. Maybe it doesn't do ALPN? https://xmpp.net/preview/scan/result/23

quite possibly

Is it Python or who's not rejecting '@' in domain names?

switched to non-forked luasec (which probably breaks more), but it now builds.

https://github.com/xmpp-observatory/xmppoke/pull/11

moparisthebest: The xmppoke PR number 11 is to have the xmpp.net at left part, client link on C2S part and server link on S2S part - https://xmpp.net/ - https://xmpp.net/result.php?domain=domain.tld&type=client - https://xmpp.net/result.php?domain=domain.tld&type=server

I have updated the description, thanks for your comment moparisthebest :)

It is linked to: https://github.com/xmpp-observatory/xmppoke-frontend/issues/9

Neustradamus, but that code is abandoned and work is being done to replace it, why change the layout?

Why wouldn't the whole badge link to one place? That's just needlessly confusing.

I've got the old xmpp.net with updated openssl running on my local host, but scheduling a check won't work. Does any of the docker containers keep logfiles?

Look into `docker logs` I guess

that doesn't give more information other than the probe has exited with error code 1.

ah, the poker can be invoked from the command line

"look ma! I'm doin' LUA!"

oh no, he's angered the gods of capitalization...

which may or may not have been intentional

`lua: xmppoke.lua:5406: attempt to index field 'x509' (a nil value)`

that line being:

`local cert_load = require "ssl".x509.load;`

any clue?

meh, in over my head. Commented on the PR with findings

the ssl module doesn't have that field anymore, but past that...

run

if you're touching luasec, run

Remember a while back when I said it was unmaintained forks all the way down?

mdosch, it indeed does not do ALPN

That may have been an evolutionary dead end, it's `require"ssl".loadcertificate` now.

> run > if you're touching luasec, run Is that a general advice or specific to xmppoke? 'Cause I have hopes of upstreaming some stuff 'ere

> Remember a while back when I said it was unmaintained forks all the way down? Naive me is hoping that all pertinent changes haven been merged upstream, and/or have been made irrelevant by later changes, and/or have only minor functional impact. That's why I was trying to move back to the upstream projects of the forks.

What part of "unmaintained forks all the way down" was unclear? Forks. With API differences.

mjk, it takes a certain kind of person to touch libssl bindings in general or luasec in particular and not come out scarred.

look at poor Zash over there

Ah, it's alright then, I'm not getting into C bindings... yet... I hope

I have no idea what you are talking about, I must have suppressed those memories. Best not remind me if so.

Just some fluffy ol' Lua

and in context of xmppoke… stay away from it in general, I suppose

It is async, predating the async in Prosody.

> and in context of xmppoke… stay away from it in general, I suppose Yeah, I'm good