XSF Discussion - 2019-10-09

  1. Link Mauve

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

  2. pep.

    I also do fwiw

  3. Link Mauve

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

  4. Link Mauve

    This definitely needs fixing.

  5. flow

    Link Mauve, are you going to fix it?

  6. Link Mauve

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

  7. Link Mauve

    Such as using a namespaced attribute!!!

  8. flow

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

  9. Link Mauve


  10. Link Mauve

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

  11. Link Mauve

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

  12. Link Mauve

    That in itself is a security issue.

  13. flow

    Would that be true for a namespaced attribute also?

  14. flow

    *Wouldn't that be

  15. jonas’

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

  16. jonas’

    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.

  17. Kev

    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.

  18. jonas’

    Kev, I’m not sure about that

  19. jonas’

    also that web interface is extremely confusing

  20. Kev

    It is (confusing).

  21. jonas’

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

  22. Kev

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

  23. Kev

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

  24. jonas’

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

  25. jonas’

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

  26. jonas’

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

  27. jonas’

    and it wants me to go there to connect to github

  28. Kev

    It's a 404 for me too.

  29. jonas’


  30. jonas’

    maybe this is a glitch in the software then

  31. jonas’

    can *you* connect the repo to github?

  32. jonas’

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

  33. Kev

    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.

  34. Kev

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

  35. jonas’

    so it’s GitHubs weird authz model again

  36. Kev

    Or what docker hub is asking for, possibly.

  37. Kev

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

  38. jonas’

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

  39. jonas’

    that’s GitHubs stupid model

  40. Kev

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

  41. Kev

    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.

  42. Kev

    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.

  43. jonas’

    that sounds like a PITA

  44. jonas’

    why does it work for xeps etc.?

  45. Kev

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

  46. Ge0rG

    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.

  47. Daniel

    ibb is a MUST in jingle ft iirc

  48. jonas’

    Ge0rG, yes, IBB

  49. Zash

    The last fallback.

  50. jonas’

    as minimum consensus

  51. jonas’

    advanced should probably support SOCKS5

  52. Ge0rG

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

  53. jonas’

    Ge0rG, I’d like to nominate Jingle Encryption for Future things

  54. jonas’

    Ge0rG, I’d like to nominate Jingle Encryption for Future Things

  55. jonas’

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

  56. Ge0rG

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

  57. Daniel

    i'd prefer to have http upload instead of jft

  58. Ge0rG

    Daniel: that'll be in Core IM

  59. Zash

    vcard4, deprecate vcard-temp?

  60. jonas’

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

  61. Ge0rG

    jonas’: there is no column for honorable mentions

  62. Daniel

    i hear cool use webrtc these days as transport

  63. jonas’

    Ge0rG, "Future Things"? ;)

  64. Daniel

    but i'm not cool

  65. Ge0rG

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

  66. jonas’

    Ge0rG, I was thinking about that, too

  67. Ge0rG

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

  68. jonas’


  69. Ge0rG

    jonas’: added all your feedback to #841

  70. Daniel

    Ge0rG: I'm sort of against bookmark conversion

  71. Ge0rG

    Daniel: mind discussing that on-list?

  72. jonas’

    yes please, I’m on my way out

  73. Daniel

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

  74. Ge0rG

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

  75. Ge0rG

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

  76. Daniel

    Ge0rG: bookmark 2 doing the conversion

  77. Daniel

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

  78. Ge0rG

    > 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].

  79. Ge0rG

    it's a hint only.

  80. Daniel

    Ge0rG: yes

  81. Daniel

    For now

  82. Ge0rG

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

  83. Daniel

    Probably not

  84. Ge0rG

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

  85. Ge0rG

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

  86. Ge0rG

    no wait. Everything is good.

  87. pep.

    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

  88. pep.

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

  89. pep.

    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"

  90. Ge0rG

    pep.: do you have a better name suggestion?

  91. pep.

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

  92. pep.

    For CCG itself I'm not sure yeah

  93. pep.

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

  94. Zash read "GCC"

  95. jonas’

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

  96. Seve


  97. Zash

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

  98. jonas’

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

  99. Ge0rG

    And, probably too obvious, the CCC.

  100. jonas’

    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.