XSF Discussion - 2019-10-09

“00:23:33 Zash> Wanna help with my WIP mod_nodeinfo2.lua?”, sure.

I also do fwiw

Damn, XEP-0076 violates the RFC by adding a second payload to an iq, and not having any @type on it.

This definitely needs fixing.

Link Mauve, are you going to fix it?

It would require a very different approach, which I’m not sure would fly.

Such as using a namespaced attribute!!!

Link Mauve, https://github.com/xsf/xeps/pull/842

Thanks.

But it means you have to add support for it in every single parser, rather than just once at the iq level.

Imagine I forgot to implement it in the disco#info parser, I would fail to notice that your disco#info reply was evil.

That in itself is a security issue.

Would that be true for a namespaced attribute also?

*Wouldn't that be

Kev, while I have you on the hook, did you have a chance to look at the docker hub thing? I didn’t have permissions to set up the builds myself. ✏

Oh, no, I didn't. I think that's you not having rights on github, as I've given you maximal rights on docker hub.

Kev, I’m not sure about that

also that web interface is extremely confusing

It is (confusing).

Kev, I think I’d need permissions on the org, not on the docker repo on docker hub to do this

I think you need permission on the org, not the repo, on github to do this. I could be wrong.

Included in the right you've been granted on dockerhub is linking to github, unless I forget what I read.

I’m pretty sure it’s on the docker hub side of things

because it briefly shows me the org settings before deciding that I shouldn’t be able to use those

this here is a 404 for me: https://cloud.docker.com/u/xmppxsf/settings/xmppxsf/dashboard

and it wants me to go there to connect to github

It's a 404 for me too.

m(

maybe this is a glitch in the software then

can *you* connect the repo to github?

https://cloud.docker.com/u/xmppxsf/repository/docker/xmppxsf/registry/builds via this

Yes, but it requires me to grant access to assorted organisations that I don't want to, it seems, which is why I left it for someone else to do.

But it does indeed seem to be doing it through the org settings, you're right.

so it’s GitHubs weird authz model again

Or what docker hub is asking for, possibly.

But it wants read/write access to the whole world.

yeah, which it gets unless the GitHub org has prevented that by default >.>

that’s GitHubs stupid model

https://docs.docker.com/docker-hub/builds/#service-users-for-team-autobuilds says something about this, haven't read it yet.

jonas’: So I think what needs to happen is the XSF to have an appropriately-limited service account created on github, and then an org owner on dockerhub to link them.

I'd suggest Matt getting himself owner access to Docker Hub would be a better start to this than continuing with me having access and other iteam not.

that sounds like a PITA

why does it work for xeps etc.?

I assume it was configured at some previous time when different access was needed.

Daniel, jonas’: I want to add JFT to CS-2020. Should I also mandate SOCKS5, IBB, or both? I tend to have IBB only as a minimum consensus.

ibb is a MUST in jingle ft iirc

Ge0rG, yes, IBB

The last fallback.

as minimum consensus

advanced should probably support SOCKS5

Daniel: ah, ok. Then it doesn't hurt to have it in CS2020.

Ge0rG, I’d like to nominate Jingle Encrypted Transport for Future Things ✏

jonas’: if JFT is an advanced feature, is S5B advanced-advanced?

i'd prefer to have http upload instead of jft

Daniel: that'll be in Core IM

vcard4, deprecate vcard-temp?

Ge0rG, good point, S5B should be honoruable mention, but don’t require it for advanced

jonas’: there is no column for honorable mentions

i hear cool use webrtc these days as transport

Ge0rG, "Future Things"? ;)

but i'm not cool

I'm pondering whether to add 0066 in "File Upload"

Ge0rG, I was thinking about that, too

it's tribal knowledge, so better have it in there

true

jonas’: added all your feedback to #841

Ge0rG: I'm sort of against bookmark conversion

Daniel: mind discussing that on-list?

yes please, I’m on my way out

If our changes to bookmarks 2 are accepted by the authors I hope to be able to deprecate conversion soon

I don't have a strong opinion on that, but it seemed useful to me.

Daniel: what's the migration path from private XML and PEP to Bookmarks2?

Ge0rG: bookmark 2 doing the conversion

The xep already hints at that. Our changes add features for that

> A server MAY choose to unify the bookmarks from both Private XML Storage (XEP-0049) [2] based and the current Bookmark Storage (XEP-0048) [1].

it's a hint only.

Ge0rG: yes

For now

Daniel: I will ask for an LC of CS2020 next week. Is the situation going to change until then?

Probably not

I need to move 0411 anyway, because it is a server-thing. ✏

no wait. Everything is good.

jonas’, it might actually be interesting to split CCG and the use-cases? I mean CCG is currently defined on "a string", but 3.2 and 3.3 could be different XEPs? and more could be added this way

That's in reaction to Ge0rG's PR on 423, I find it pretty restrictive (not the right word) to name the dep on 392 "User Name Coloring" ✏

pep.: do you have a better name suggestion?

I'd be happy to keep that name if we had a xep that requires CCG and is specifically for user name coloring :p

For CCG itself I'm not sure yeah

(And if it were split, it wouldn't make sense to include CCG itself anyway)

Zash, it’s even more confusing if you also are familiar with GGC, which is the Garbage Collector implementation GCC uses internally (while compiling)

@_@

The number of [GC]{3} is too damn high!

I think there’s also a dithering algorithm or something like that which is in that space of names

And, probably too obvious, the CCC.

mildly amusing: I just found this (<https://security.stackexchange.com/questions/51948/is-it-okay-to-normalize-unicode-passwords-with-nfc-nfd>) stackexchange question I wrote five years ago. I love the sentence: > I found that there is a stringprep (RFC 3454) profile called SASLprep (RFC 4013) which is appearantly used for passwords and usernames in some protocols.