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 :D
  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 Hm?
  131. Zash Isn't 6122 IDNA2008 + STRINGPREP?
  132. renken no
  133. renken 6122 IDNA2003 + STRINGPREP
  134. Zash Wasn't that what was before 6122?
  135. renken yeah
  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 http://www.unicode.org/reports/tr39/
  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 henry*
  191. Zash Fun
  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’ #robotface
  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’ postel?
  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 usernames*
  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