XSF Discussion - 2017-10-06

Ha this is the same argument as the one against e2e earlier https://www.quakenet.org/articles/99-trust-is-not-transitive-or-why-irc-over-ssl-is-pointless

moparisthebest: seems like the dude only concerned about mitm?

Hi! Awesome to see that JET is now experimental :D I noticed some formatting issues in the pdf though. The table under §5 is crippled. Since this is likely to occure elsewhere as well, I thought I'd bring that to your attention :)

vanitasvitae: the best approach is probably to open an issue on the xeps repo. Or even to provide a patch ;)

Guus told me, that SamWhited and jonasw are doing some work on this, so let me ping you :)

I'm not familiar with the pdf build process, so I think I'll just open an issue (if there is none yet)

I don't think they're still actively working on it - but things did change recently.

I opened https://github.com/xsf/xeps/issues/521

nobody is familiar with the pdf build process :D

yeah, I doubt we can do anything about that

(looking at the issue)

it’s simply too wide for the PDF output

yeah, I guess you're right

ideally editors would proofread the PDF output and ensure that it is nice, but ...

I’m actually more inclined to terminate PDF output altogether than doing that ;-)

In that case there is not much to do I guess :D

But pdfs are so nice... :D

I prefer the HTML version, esp. since Sams recent CSS fixes

one of the few things I prefer to have in my browser over a separate application

vanitasvitae: can you replace the namespace by a (shorter) reference to a namespace, somehow?

that would probably do the trick, yes

maybe get rid of the "-"s as a first step?

and shorten "nopadding" to "nopad"?

hey, the logo on the PDF (first page), looks weird

it's the old / broken logo, but also has black colors for the outside bits, instead of the blue?

thats an issue with firefox I think

weird

no

might be, but I'm using Chrome :)

it’s also in the original PDF of the logo

super weird

the logo is rendered differently in pdf viewers and browsers I think

at least I noticed that some time ago

can’t easily fix that though, because the PDF includes the "XMPP" text for which I don’t have the font I think

no, it is definitely also in the source files, vanitasvitae

what format is the source?

this is extremely ugly https://sotecware.net/images/dont-puush-me/FHNZUlDByHqPUgjwj1Cq2EhPat6zvV5sfbTtJ__tlLI.png

PDF

bah

I can try to mess with it to embed the new logo in that, should be doable

PDF missing the main purpose of its existence :D

I've got SVGs for the logo, but not the text

how did you make xmpp.png then?

by hand?

yeah, I erased the logo, copied in a newly generated one from SVG using the correct size

okay

interestingly, the page headers also have a (very small) logo, where the colors are correct.

yupp

those are two different files

patching them now

thanks :)

I'm somewhat surprised that the source components are PDFs themselves. Then again, I know nothing.

that’s usual for LaTeX

you can only have PDF as vector format without extra packages when building with {pdf,xe,lua}latex

now that’s interesting

https://sotecware.net/images/dont-puush-me/4jcYqbi6zp4l-yyi1U5yz7Dhwjj0O_q_ScQz9oN7Gvs.png

the pdf including the text contains quite a bit more

notably, the blue tones are not included in the design specs on the top left

Ah, that's by the original designer

Raja

he's who I talked to earlier.

also, it lists a typeface? :)

Eurostile Bold Extended

https://www.google.be/search?q=Eurostile+Bold+Extended&tbm=isch&tbo=u&source=univ&sa=X&ved=0ahUKEwjh86TbwtvWAhXQJFAKHca3B5EQsAQIMA&biw=1855&bih=990

seems to be it :)

that PDF is super weird

but I guess that’s what you get from opening PDFn with inkscape

those appear to be printing masters

it's probably what the original authors of the PDF generation had available at the time

making a test build with patched PDFs

(now I in fact wonder if all built PDFs contain the whole printing master...)

(or if something is smart enough to crop that out)

(which I doubt, because it’s pdflatex we’re speaking about)

well, xelatex

how big is it? If it's just a fraction of the total size, I wouldn't bother improving it further

a few kiB

I was just wondering conceptually

because that’s essentially the XMPP Corporate Design ;-)

thereifixedit: https://sotecware.net/files/noindex/xep-0391.pdf cc @ Guus

fun fact: the font used for the 'XMPP' text in our logo is also used in 2001: A Space Odyssey, for the interface of HAL. :)

ah, much better, thanks!

let’s push that

now I get the feeling that I did already quite a lot today! :-)

and it's only 10 am :)

exactly!

wanna pop over to jdev and see if you have feedback on my question there? :)

oh, you already were there :)

there you go ;-)

tx :)

It's 10 AM and I feel like weekend already

Ge0rG, good news: weekend for me already. wait. that’s only good news for me. sorry.

you just told us you were available.

that might've been a mistake :P

Guus, do you have power over the dockerhup by now? If so, does that include the xeps builds? That’d be good to know.

He does, yes.

great. Just in case there are issues again, but I suspect now that we don’t source stuff from sourceforge anymore, it should be fine

(what Kev said)

dwd: What was the motivation for renaming the 'mechanism' to 'task' in SASL2?

IIRC because it can do things other than present SASL mechs. I could be wrong.

k, thanks

It also can't do the things mechanisms do. Like change the authorization identifier. Plus they need one to start.

can <task> could also contain a SASL mech?

Doubtful.

Wasn' t one idea that multiple mechs could be chained with SASL2?

did you use two different clients just now, dwd?

your nickname had different colors in Spark

Guus, Conversations for both those (Gajim for this one). Probably Conversations was detached; it looks like it injected a delay stamp.

Flow, So yes, the idea originally was that all these things are SASL mechs. But in practise, when developing, they're not. The first thing is a SASL mech, any subsequent ones are similar to mechanisms but distinct in that they're provided with an authzid, and cannot change it.

authzid was the thing which would allow you to impersonate another entity, right?

Not impersonate, but yes.

Flow, No, the authzid is the (most important) output of the SASL process. In XMPP, it's your jid.

ahh, ok, then it's the authcid I was thinking about

It's the thing that tells you what you are.

Flow, Probably not.

then what's the authcid again?

you authentiCate with authcid, you are then authoriZed for using authzid

An authorization identity is an OPTIONAL identity included by the initiating entity to specify an identity to act as

Flow, The authentication identifier is the identifier used to identify you to the SASL mechanism. Typically you don't specify an authzid, and again typically in XMPP the authcid is just the local-part of the jid and the authzid is then figured out from that.

That does sound like authzid is what I said it is

Flow, It is optional to supply, because it can be derived (normally).

Flow, You do, always, end up with an authzid. Worth looking at TLS+EXTERNAL as an example - your authcid there is the certificate (or arguably the Subject of it). The authzid might be derived from it (usually from a SAN) or you might supply it.

Flow, There's no "impersonation" going on, though that, too, in as option (known as "Proxy Authentication", because you're authenticating to be a proxy for another user)

So what exactly is the problem that following SASL mechs can't change the authzid? Usually you either never provide the authzid or you provide it, in which case all chained mechs should/must provide the same

Flow, There's absolutely no power on earth that'll make me try to implement that. It's a nightmare.

And what is the point in being able to optionally supply the authzid? Re-using the same credentials for different accounts?

Anyway, I don't see a problem that subsequent mechs can not change the authzid

I'm no expert, but, I thought it was primarily used when the username you authenticate with isn't an exact match with the account name that you're authenticate for.

Flow, Sometimes to avoid confusion (like with TLS+EXTERNAL), sometimes for Proxy Auth. Also, if you've a username from, say, Active Directory that's not valid for XMPP, this be a way around that problem too.

I think we mixing two aspects of authzid: The one is where a sasl mech can optionally provide it, the other one is that you only know your full JID after being authenticated

Flow, Input and output, is all.

For chaining mechs, only the former can be possibly relevant, and I don't see why we can't simply say that all chained mechs must provide the same authzid, if they provide any at all

Flow, Why do you want to?

Guus: Yep, besides that your username can be completly different from the localpart of the JID you get

dwd: Why do I want to chain SASL mechs? Well the idea sounded appealing to me back then. And I don't see why we gave up on it

Flow, Because I tried implementing it and it was horrible.

Flow, Whereas I *have* implemented the current spec, along with TOTP etc, and it all works well.

dwd: Maybe, but what is different by having tasks now? SASL mechs are basically just a sequences of challenges and responses, surely tasks are very similar to that?

Flow, Yes, the protocol interface is the same, but the internal server-side interface is pretty different.

dwd: shouldn't ex4 in xep388 show a bare jid, or, when do I get a full JID at this stage?

ahh, we do bind2 there also

uh and bind2 still has no support for a client provided part ☹

Is anyone ready to implement bind2? If so I'll try to find time to add that.

and sasl2 can be used without bind2? A lot of possibilities ☺

(but it's getting complicated)

dwd: Did you do bind2 with sasl2, or not?

Kev, I've been toying with a bind2 embedded in sasl2 in my implementation just to see, but I've not tried it yet.

Kev: ex2 in xep388 hints at bind2

Flow, Also ISR. But I've not quite finished 198 resumption yet, so...

Flow, I think I said (read: I meant it to say) it was a hypoethetical extension, in ex2.

ha AOL is finally killing AIM

I... didn't know it was still alive

ya, just read the news here: https://aimemories.tumblr.com/

That's AIM, MSN Messenger, and Yahoo Messenger all gone… the 90's are finally over :'(

well we still have XML >:)

Only the worst part of the 90's are still around…

moparisthebest, Where? We're now using a "React-like wire protocol", remember?

dwd, I haven't heard of that but it sounds terrifying

No, no. It's great. It'll get us all the cool kids now. Better than json.

I heard you use this argument a few days ago

so presumably, there now is a newer fashion.

...

longtime guy in IRC channel mentions jabber, I say that's awesome when did you start using it

he says just now to try to talk to some drug dealers from darkweb sites

so, that's nice haha

definitely success

moparisthebest, Well, at least we have a dedicated niche market.

yea use is exploding in a certain market segment I guess

anyone want to sign up and ask about usability issues, UI problems etc

yeah, lets fix those nasty spam control issues that they're experiencing for them

I can probably get the .onion site domain haha

see here is a segment that probably values forward secrecy over long term archives right?

moparisthebest, Depends if they have a sideline in blackmail, I guess.

guess the 'seller' is using jodo.im I'm guessing it has IBR enabled judging by the flash 9.0 required on the http page