jdev - 2019-12-17

  1. Zash has left

  2. Daniel has left

  3. Zash has joined

  4. Daniel has joined

  5. Daniel has left

  6. kikuchiyo has left

  7. kikuchiyo has joined

  8. Daniel has joined

  9. alexis has left

  10. alexis has joined

  11. kikuchiyo has left

  12. kikuchiyo has joined

  13. kikuchiyo has left

  14. Daniel has left

  15. kikuchiyo has joined

  16. kikuchiyo has left

  17. Daniel has joined

  18. kikuchiyo has joined

  19. Daniel has left

  20. Daniel has joined

  21. Lance has left

  22. Daniel has left

  23. kikuchiyo has left

  24. kikuchiyo has joined

  25. wurstsalat has left

  26. asterix has joined

  27. Daniel has joined

  28. kikuchiyo has left

  29. marc0s has left

  30. marc0s has joined

  31. wurstsalat has joined

  32. asterix has left

  33. asterix has joined

  34. asterix has left

  35. asterix has joined

  36. Daniel has left

  37. kikuchiyo has joined

  38. asterix has left

  39. asterix has joined

  40. asterix has left

  41. asterix has joined

  42. asterix has left

  43. asterix has joined

  44. asterix has left

  45. asterix has joined

  46. Daniel has joined

  47. Daniel has left

  48. Daniel has joined

  49. pulkomandy has left

  50. pulkomandy has joined

  51. sonny has joined

  52. goffi has joined

  53. sonny has left

  54. larma has left

  55. larma has joined

  56. pulkomandy has left

  57. pulkomandy has joined

  58. larma has left

  59. larma has joined

  60. sonny has joined

  61. msggrid has joined

  62. pulkomandy has left

  63. pulkomandy has joined

  64. pulkomandy has left

  65. pulkomandy has joined

  66. sonny has left

  67. sonny has joined

  68. goffi

    Hi. I'm implemeting OMEMO media sharing, and it seems that there is an incoherence: doc says that key is 32 bytes and IV 12 bytes, in hex it's 64 + 24 = 88 but the example URL fragment is 96 bytes, and a quick test with Gajim give me a fragment of 96 bytes too. So it the XEP text wrong or am I missing something?

  69. goffi

    (talking about the URL in example at https://xmpp.org/extensions/inbox/omemo-media-sharing.html#aesgcm)

  70. pulkomandy has left

  71. Daniel

    we originally used 16 byte IVs; but the aes-gcm spec says you should use 12

  72. Daniel

    so for legacy reasons everyone keeps sending 16 for now; but have read support for 12

  73. Daniel

    except chatsecure i think which only supports reading 16

  74. Daniel

    which is why we haven’t switched over yet

  75. pulkomandy has joined

  76. goffi

    ok so for reading both should be implemented. For writting is it still recommanded to use 16 or should I use 12? Is there any client not supporting reading 12?

  77. Daniel

    yes chatsecure; last time i checked

  78. goffi

    ah right sorry you just say that above :)

  79. goffi

    Thanks Daniel

  80. pulkomandy has left

  81. pulkomandy has joined

  82. debacle has joined

  83. sonny has left

  84. pulkomandy has left

  85. debacle has left

  86. sonny has joined

  87. sonny has left

  88. Wojtek has joined

  89. debacle has joined

  90. Alex has left

  91. sonny has joined

  92. pulkomandy has joined

  93. msggrid has left

  94. larma has left

  95. larma has joined

  96. Alex has joined

  97. pulkomandy has left

  98. pulkomandy has joined

  99. sonny has left

  100. pulkomandy has left

  101. pulkomandy has joined

  102. Kev has joined

  103. pulkomandy has left

  104. pulkomandy has joined

  105. Alex has left

  106. Wojtek has left

  107. Alex has joined

  108. renken has joined

  109. pulkomandy has left

  110. pulkomandy has joined

  111. renken

    are there tests provided to verify the correctness of a given RFC implementation? I'm working on implementing RFC 6122 and I'd like to improve and extend my test cases. The dependency on Unicode makes it a bit complex to come up with a complete set of tests

  112. Zash

    Hm, wasn't there a project for that?

  113. alexis has left

  114. Zash

    There's a few test cases in in https://github.com/igniterealtime/jxmpp/tree/master/jxmpp-strings-testframework/src/main/resources/xmpp-strings/jids

  115. alexis has joined

  116. Zash

    Not sure about the coverage of Unicode yet tho

  117. renken

    the ones you provided are very helpful, thanks Zash.

  118. Zash

    And then there's the thing with RFC 6122 being obsoleted by RFC 7622 but I don't know if anyone is there yet

  119. renken

    PRECIS isn't implemented yet as far as I know

  120. renken

    libidn2 team were thinking about releasing libprecis but no news. ICU team's case is vague too https://unicode-org.atlassian.net/browse/ICU-11981 https://libidn.gitlab.io/libidn2/manual/libidn2.html#Stringprep-and-libidn2

  121. Zash

    I've got that ICU ticket bookmarked 🙂

  122. renken


  123. renken

    prosody discussed PRECIS as well https://issues.prosody.im/533

  124. Guus

    didn't sco0ter do PRCIES?

  125. Guus

    didn't sco0ter do PRECIS?

  126. Zash

    libidn being obsoleted by libidn2 when we're using the stringprep stuff .. looks like we're going with ICU for now

  127. Guus

    (in Babbler?)

  128. renken

    Guus, I'm not familiar with sco0ter sorry. Zash, it leaves us with a hybrid implementation. 6122 for localpart and resourcepart, 7622 for domainpart (IDNA2008)

  129. Zash

    There were rumors of some Rust folks maybe planning on some PRECIS stuff

  130. Zash


  131. Zash

    Isn't 6122 IDNA2008 + STRINGPREP?

  132. renken


  133. renken

    6122 IDNA2003 + STRINGPREP

  134. Zash

    Wasn't that what was before 6122?

  135. renken


  136. Zash

    https://tools.ietf.org/html/rfc6122#section-1.1 sounds like IDNA2008 or do I need to read more carefully?

  137. renken

    well I follow https://tools.ietf.org/html/rfc6122#section-2.2

  138. renken

    >A domainpart consisting of a fully qualified domain name MUST be an "internationalized domain name" as defined in [IDNA2003];

  139. Zash

    > or do I need to read more carefully? No, I need make dinner. Looking at these things only leads to tears 🙁

  140. renken

    eat well

  141. Zash

    It does say > software implementations are encouraged to begin migrating to IDNA2008

  142. renken

    yeah that's what I meant by "hybrid"

  143. Zash

    I think there's also some compat options in IDNA2008 (or at least in ICU) that somehow minimizes the differences (and hopefully, pain) between '03 and '08

  144. renken

    of course. both PRECIS and IDNA2008 are backward compatible as far as I know

  145. Zash

    `UIDNA_NONTRANSITIONAL_TO_ASCII` does ... something (in ICU)

  146. renken

    their docs are a bit vague ...

  147. pulkomandy has left

  148. lovetox has joined

  149. pulkomandy has joined

  150. alexis has left

  151. pulkomandy has left

  152. pulkomandy has joined

  153. bhaveshsgupta has joined

  154. pulkomandy has left

  155. pulkomandy has joined

  156. Lance has joined

  157. debacle has left

  158. Alex has left

  159. asterix has left

  160. pulkomandy has left

  161. asterix has joined

  162. pulkomandy has joined

  163. Alex has joined

  164. marc0s has left

  165. marc0s has joined

  166. rion has left

  167. rion has joined

  168. rion has left

  169. asterix has left

  170. rion has joined

  171. rion has left

  172. pulkomandy has left

  173. pulkomandy has joined

  174. rion has joined

  175. rion has left

  176. rion has joined

  177. rion

    Can you guys make a page maybe on xsf wiki how to live with c/c++ and without PRECIS implementation?

  178. rion

    It seems some distros are eager to remove old libidn :(

  179. renken

    if distros are eager to remove libidn, it's because the libidn team is pushing idn2? no? iirc libidn also offers stringprep whereas libidn2 doesn't offer anything (neither stringprep nor precis)

  180. pulkomandy has left

  181. renken

    an alternative would be to use ICU because it offers (deprecated) idna2003 support, idna2008 and stringprep

  182. Zash

    ICU also has "confusable" mapping stuff

  183. renken

    such as?

  184. Zash


  185. renken

    oh yeah that's neat. it helps with address spoofing and forging

  186. Zash

    Right, that, like if someone joins as "Zаsh" (using a cyrillic small letter a)

  187. renken

    I assume XMPP users are nice people and delay security considerations until later oops

  188. pulkomandy has joined

  189. renken

    oh yeah Zash, apparently HenryⅣ `\u2163` gets mapped to Henryiv in stringprep however it's illegal in precis. interesting

  190. renken


  191. Zash


  192. jonas’

    and this is why we don’t go there (PRECIS)

  193. Zash

    I'd like to have the option but I'm not sure if there's any rush

  194. renken

    I don't know. I'm still a beginner but personally PRECIS seems more organized and structured properly

  195. renken

    care to elaborate, jonas’?

  196. Lance has left

  197. jonas’

    renken, PRECIS and Stringprep aren’t compatible. if some entities are on PRECIS, and some are on stringprep, chaos ensues

  198. strar has left

  199. jonas’

    in addition, PRECIS isn’t pinned to a unicode version, so different entities on different unicode versions coudl very well be of different opinions on what constitutes a "legal" string

  200. strar has joined

  201. Zash

    Bad enough things happen already

  202. Zash

    🤖️ says hi

  203. jonas’


  204. renken

    I see. thanks for the explanation

  205. renken

    sad unicode life

  206. jonas’

    read also: https://mailarchive.ietf.org/arch/msg/xmpp/a-WhzOTyOq168GujQHgzQ1-DURI

  207. pulkomandy has left

  208. Zash

    jonas’, how much chaos do we get if we do the postel thing?

  209. jonas’


  210. Zash

    "be conservative in what you send, liberal in what you receive"

  211. pulkomandy has joined

  212. jonas’

    helps only partially

  213. jonas’

    it helps with the plain out rejection, but if unicode comes up with different normalisation mappings, you’ll get havoc with user passwords and stuff

  214. Zash

    Altho here I mean being Very Strict when creating things locally, while not being as strict with incoming data

  215. jonas’

    I’d also expect a MUC service to enforce a single unicode version across all nicknames it allows

  216. Zash

    Yeah, that.

  217. Zash

    And locally created users.

  218. Zash


  219. bhaveshsgupta has left

  220. bhaveshsgupta has joined

  221. Zash

    Hm did we already add that to Prosody for MUC?

  222. Zash

    Ah yeah (trunk tho)

  223. Zash

    and room localparts

  224. debacle has joined

  225. jonas’

    flow, is there any documentation on creating a MAXS plugin?

  226. pulkomandy has left

  227. pulkomandy has joined

  228. pulkomandy has left

  229. pulkomandy has joined

  230. bhaveshsgupta has left

  231. rion has left

  232. rion has joined

  233. alexis has joined

  234. alexis has left

  235. alexis has joined

  236. alexis has left

  237. asterix has joined

  238. asterix has left

  239. asterix has joined

  240. lovetox has left

  241. pulkomandy has left

  242. pulkomandy has joined

  243. wurstsalat has left

  244. asterix has left

  245. Alex has left

  246. goffi has left

  247. allie has left

  248. allie has joined

  249. Lance has joined