XSF Discussion - 2016-01-21

  1. Jake1984 has joined
  2. foss81405971 has joined
  3. stpeter has joined
  4. bjc has joined
  5. bjc has left
  6. waqas has left
  7. waqas has joined
  8. Lance has joined
  9. waqas has left
  10. waqas has joined
  11. daniel has joined
  12. Lance has joined
  13. intosi has joined
  14. Tobias has left
  15. arty has left
  16. arty has joined
  17. intosi has joined
  18. bjc has joined
  19. ralphm has left
  20. bjc has left
  21. waqas has left
  22. Jake1984 has left
  23. Jake1984 has joined
  24. Lance has joined
  25. Neustradamus has left
  26. narcode has left
  27. Lance has joined
  28. ralphm has left
  29. stpeter has left
  30. narcode has joined
  31. Neustradamus has joined
  32. ralphm has left
  33. bjc has joined
  34. stpeter has joined
  35. stpeter has left
  36. ralphm has left
  37. bjc has left
  38. bjc has joined
  39. foss81405971 has joined
  40. intosi has left
  41. intosi has joined
  42. bjc has left
  43. Kev has left
  44. Kev has left
  45. intosi has left
  46. intosi has joined
  47. intosi has left
  48. intosi has joined
  49. bjc has joined
  50. ralphm has left
  51. dwd has left
  52. intosi has left
  53. ralphm has left
  54. ralphm has left
  55. moparisthebest has left
  56. moparisthebest has left
  57. moparisthebest has joined
  58. SamWhited has left
  59. ralphm has left
  60. bjc has left
  61. bjc has joined
  62. Lance has left
  63. ralphm has left
  64. ralphm has left
  65. Flow has joined
  66. soul has left
  67. Flow has joined
  68. ThUnD3r|Gr33n has joined
  69. Tobias has left
  70. Flow has joined
  71. winfried has joined
  72. intosi has joined
  73. thorsten has left
  74. thorsten has joined
  75. Alex has joined
  76. winfried has left
  77. Kev has joined
  78. goffi has joined
  79. intosi has joined
  80. waqas has joined
  81. Martin has joined
  82. lloyd has joined
  83. intosi has left
  84. intosi has joined
  85. Alex has left
  86. Alex has joined
  87. dwd has left
  88. dwd has left
  89. dwd has left
  90. Jake1984 has left
  91. Jake1984 has joined
  92. Jake1984 has left
  93. foss81405971 has joined
  94. xnyhps has joined
  95. Ashley Ward has joined
  96. dwd has left
  97. dwd has left
  98. soul has joined
  99. intosi has left
  100. ralphm has left
  101. soul has left
  102. soul has joined
  103. soul has left
  104. soul has joined
  105. soul has left
  106. soul has joined
  107. tim@boese-ban.de has joined
  108. ralphm has left
  109. ralphm has left
  110. soul has left
  111. soul has joined
  112. mark.erd has joined
  113. mark.erd has left
  114. intosi has left
  115. intosi has joined
  116. winfried has joined
  117. Alex has left
  118. Alex has joined
  119. ralphm has left
  120. thorsten has left
  121. thorsten has joined
  122. Ashley Ward has left
  123. Ashley Ward has joined
  124. Tobias has joined
  125. Link Mauve Flow, what’s the rationale for having moved everything out of signcrypt, in OX?
  126. Flow Link Mauve: please define "everything" :)
  127. Link Mauve Err, not out, more like moved the attributes to elements.
  128. Flow ahh I assumed that is what you meant
  129. Flow short answer: because you can't have multiple attributes with the same name
  130. Link Mauve And you want to, in this case?
  131. Flow and we want to be able to specify multiple recipients
  132. Flow so the initial idea was to <signcrypt to='foo@bar.com' to='baz@bar.com'>
  133. Flow but that's not valid xml
  134. Flow so now we have <signcrypt ...><to .../><to .../>...
  135. Link Mauve Oh, the <to/> are there to list every recipient that can decrypt?
  136. Tobias has joined
  137. Flow Link Mauve: Yes "OpenPGP content elements MUST possess at least one 'to' ..." and "The 'to' element(s) MUST have a 'jid' attribute which contains the intended recipient's XMPP address..."
  138. Link Mauve s/recipient's/recipients'/ then.
  139. Flow RFC 4880 already allows multiple recipients and there is no reasion to restrict an OX OpenPGP content element to one
  140. Link Mauve So should there always be a <to/> for yourself?
  141. Link Mauve Always?
  142. Flow Link Mauve: I don't think so
  143. Flow The encrypt to self is to allow users to read their own send messages
  144. Flow The <to/> in OpenPGP content elements is there to prevent attacks where the message is send by an attacker to a third party
  145. Flow which was not the intended recipient in the first place
  146. Link Mauve It might be useful to define what to do if you (the recipient) don’t match any of the <to/>.
  147. Flow Link Mauve: I think what we have in OX § 3.2 is sufficient right now
  148. Flow You can't specify what an implementation should to if the verification fails
  149. Flow If I wouild ask you what you plan to do in profanity, and then I would ask daniel what he plans to do in conversations, I would likely get two different answers.
  150. Link Mauve poezio* :)
  151. Link Mauve Actually, just slixmpp for now.
  152. Flow Link Mauve: Uhh, sorry.
  153. Flow Isn't the profanity dev also here?
  154. Link Mauve I know the mcabber dev is here, coucou McKael.
  155. Link Mauve Also the primitivus dev is here, coucou goffi.
  156. Flow Link Mauve: Are you going to the Summit/FOSDEM?
  157. Link Mauve Sure. :)
  158. Link Mauve Will miss the first morning of Summit though. :(
  159. goffi I need to check this OX stuff, it can be interesting for our private blog feature
  160. Alex has joined
  161. mathieui afaik the profanity dev is boothj5, and he’s not here
  162. Kev has left
  163. Kev has left
  164. bjc has left
  165. Ge0rG am I reading OX right, that the <openpgp> element contains base64-encoded xml elements?
  166. Flow Ge0rG: no base64 encoded RFC 4880 messages which contain an encrypted and/or signed UTF-8 string which contains XML.
  167. Flow bbl
  168. Ge0rG maybe section 3 should more clearly state that, and provide a rationale
  169. Flow a rationale for?
  170. Ge0rG a rationale for putting base64-encoded xml into xml.
  171. Flow But that's not the case
  172. Ge0rG besides, there is no format specification in section 3, and only a brief examle of one of the three use cases
  173. Flow I admit that § 3.1 format specification is not very well written, but it is there: "The text content <openpgp/> (BASE64_OPENPGP_MESSAGE) is a Base64 encoded, as specified in RFC 4648 [3] § 4, OpenPGP message which contains an encrypted and/or signed UTF-8 encoded string. Note that OpenPGP's ASCII armor is not used, instead the XMPP client MUST encode the raw OpenPGP message, as specified in RFC 4880 [4], using Base64. This string MUST represent exactly one OpenPGP content element, that is either a <signcrypt/>, a <sign/> or a <crypt/> extension element qualified by the 'urn:xmpp:openpgp:0' namespace."
  174. Ge0rG also why use base64 over ascii armor?
  175. Steffen Larsen has joined
  176. Flow because we encode the OpenPGP message
  177. Ge0rG "This string MUST represent ..." maybe "correspond to" would be a better wording.
  178. Steffen Larsen has left
  179. intosi has joined
  180. Ge0rG the OpenPGP message format also encodes whether it's a signed/encrypted message and which key-ids it is encrypted for. Why is this data duplicated inside?
  181. Flow key-ids != jids
  182. Zash wat
  183. Zash Ge0rG: I thougt "ascii armor" was base64?
  184. moparisthebest Ge0rG, it looks like base64 is used INSTEAD of ascii armor, not over it?
  185. Ge0rG moparisthebest: that's what I intended to say
  186. Flow and as for <signcrypt/>, <sign/> and <crypt>, for one, it is a fail safe, if an implementation constructs a <signcrypt/> message, because it wants to send a signed and encrtyped message, but only encrypts it using OpenPGP
  187. Ge0rG Zash: yes, but with dashes and headers added.
  188. moparisthebest oh so is it the same as the old spec? ascii armor stripped of whitespace and headers?
  189. Ge0rG Flow: how should a client receiving such a failed message behave?
  190. Flow Ge0rG: What woud you suggest?
  191. moparisthebest explosions
  192. Flow atomic ones?
  193. moparisthebest I was thinking more firecracker-like
  194. Flow uhh :(
  195. Flow Ge0rG: Link Mauve asked a similar question just before you today. I don't have an answer other then "it should consider the message as unverified", and I don't think a spec should specify what a client should/must do if a message is unverified.
  196. Zash Light the thermite failsafe device
  197. moparisthebest clients don't do nearly the same with with current pgp if decryption fails, I was messing around with this yesterday with a command-line pgp-capable sendxmpp command
  198. Flow moparisthebest: "don't do nearly the same"?
  199. moparisthebest conversations displays "can't decrypt, maybe you don't have the right private key?" even when 'encrypted content' is 'bla'
  200. moparisthebest and gajim sometimes displays the content of <body>, and sometimes shows no indication of having received a message at all
  201. Flow ahh
  202. moparisthebest Flow, I'm saying they aren't consistent in what they do when receiving bad pgp encrypted messages
  203. boothj5 has joined
  204. moparisthebest it would be nice if they were somewhat consistent though, I don't like gajim just dropping messages silently
  205. moparisthebest you probably don't want to specify what exactly they should say, maybe you could just specify they should inform the user in some way?
  206. Ge0rG what about sending an error back?
  207. Ge0rG though what do you do if a client (of multiple) just doesn't have the right key?
  208. Ge0rG Flow: by not having the redundancy, one could prevent the existence of these border cases.
  209. Flow Ge0rG: error as response of a presence has the potential for a presence leak, but if you check before sending that the entity has access to your presence anyway, then yes why not
  210. moparisthebest and they could *get* the key later, due to the nature of pgp
  211. moparisthebest like I set up conversations on a new phone and haven't set up openkeychain yet
  212. Ge0rG sending an error as a response to a malformed message doesn't seem too far-reached
  213. moparisthebest and do you still send the error back when you are retrieving with MAM ?
  214. Flow Ge0rG: I think a bad programmer is more likely to be able to construct an XML string prefixed with <signcrypt/>, <crypt/> and <sign/> then to use a OpenPGP library correctly
  215. moparisthebest or do all your devices receiving the carbon send messages?
  216. Flow So it's not about removinga border case, but about having a fail safe for this case
  217. moparisthebest there might be a difference to what you do if you don't have a key vs not-pgp, I'm not sure it'd be a problem outside of development
  218. Ge0rG Flow: I think that adding this redundancy creates the border cases in the first place
  219. Ge0rG "in the range of tenth of kilobytes" --> "in the range of tens of kilobytes" I suppose
  220. boothj5 has left
  221. Ge0rG the timestamp is redundant as well.
  222. Flow Yep
  223. Ge0rG so a client may receive a message with three (different) timestamps. XEP-203, openpgp and <time>
  224. Ge0rG which one do you display?
  225. Flow I would display <time>
  226. Alex has left
  227. xnyhps Ge0rG: And possibly timestamps added by multiple different servers. ;)
  228. Flow xnyhps: Which remindes me, I wanted to reply to your latest mail on standards@
  229. xnyhps Timestamps are quite messy because it's not easy to say who to trust in general.
  230. Flow I'd be interested in persuing the added:by approach
  231. Flow And from what I can read, daniel too
  232. Flow I'd like to hear from some more server guys what they think about it
  233. Flow I believe most of the business rules from xep359 could go into the added:by xep
  234. mathieui has joined
  235. Tobias has joined
  236. xnyhps Flow: Some of them, yeah
  237. xnyhps Still not sure the complexity is really worth it.
  238. Flow xnyhps: That's basically why I didn't replly initially
  239. xnyhps My main reason was that the things the server strips might have changed between when the message was originally sent and when the client received it (from MAM), but as long as servers also strip messages outgoing on MAM that's not a problem.
  240. intosi has joined
  241. intosi has left
  242. intosi has joined
  243. Tobias has joined
  244. dwd has left
  245. intosi has left
  246. intosi has joined
  247. Holger has left
  248. dwd has left
  249. Holger has joined
  250. dwd has left
  251. edhelas has left
  252. intosi has left
  253. intosi has joined
  254. edhelas has joined
  255. intosi has left
  256. intosi has joined
  257. ralphm has left
  258. dwd has left
  259. Link Mauve Flow, might be useful to add a section about what to do if there are e.g. both an openpgp and a body element in a message or presence (iq obviously can’t have that).
  260. Alex has joined
  261. tim@boese-ban.de has left
  262. ralphm has left
  263. waqas has left
  264. SamWhited has left
  265. xnyhps has left
  266. intosi has joined
  267. winfried has left
  268. waqas has joined
  269. Martin has left
  270. Flow Link Mauve: Hmmm, undecided, I personally don't think it is necessary
  271. Flow but patches welcome :)
  272. Flow XMPP-IM neither specifies what to do when a message with two <body/> arrives
  273. Flow (or maybe it does and I don't remember)
  274. dwd has left
  275. bjc has joined
  276. foss81405971 has joined
  277. intosi has joined
  278. Jake1984 has joined
  279. Ge0rG Flow: "For example, direct child elements found in either <signcrypt/>, <sign/> and <crypt/> could be: " <- shouldn't that read "For example, <payload/> child elements..."?
  280. Flow Ge0rG: Thanks, that is a leftover from the attribute to elements migration
  281. Flow fixing right now
  282. Ge0rG Flow: also s/my/by/ in the §8.3 text
  283. Flow fixed
  284. intosi has joined
  285. intosi has left
  286. intosi has joined
  287. Ge0rG Flow: the link from §6.1 to http://tools.ietf.org/html/rfc4880#section-5.5.2 talks about key packets, not about message formats
  288. Flow has joined
  289. Holger has left
  290. Holger has joined
  291. foss81405971 has joined
  292. Holger has joined
  293. Tobias has joined
  294. intosi has joined
  295. Ge0rG I hope I didn't kill the OX thread with my long response.
  296. daniel has left
  297. daniel has joined
  298. Tobias has joined
  299. daniel has left
  300. daniel has joined
  301. Link Mauve Given the date, I’d even say the opposite. :)
  302. daniel has left
  303. daniel has joined
  304. fippo has joined
  305. Ge0rG Link Mauve: oh, right. I've been on holiday and missed it. Just found the time to read up, and the messages all were "new" to me
  306. dwd has left
  307. dwd has left
  308. foss81405971 has joined
  309. Lance has joined
  310. dwd has left
  311. lloyd has left
  312. dwd has left
  313. dwd has left
  314. dwd has left
  315. dwd has left
  316. moparisthebest has left
  317. soul has left
  318. SouL has left
  319. ThUnD3r|Gr33n has joined
  320. mathieui has joined
  321. mark.erd has joined
  322. mathieui has left
  323. mathieui has joined
  324. mark.erd has left
  325. ralphm has left
  326. mark.erd has joined
  327. SouL has left
  328. mark.erd has left
  329. intosi has joined
  330. SouL has left
  331. SouL has joined
  332. Holger has left
  333. dwd has left
  334. Lance has joined
  335. Lance has joined
  336. Lance has joined
  337. Lance has joined
  338. intosi has left
  339. intosi has joined
  340. soul has joined
  341. Holger has joined
  342. waqas has left
  343. waqas has joined
  344. Tobias has joined
  345. Flow has joined
  346. dwd has left
  347. dwd has left
  348. Tobias has left
  349. dwd has left
  350. Flow Ge0rG: it's just an example of packets where v4 must be used. The most important one, but just an example
  351. soul has left
  352. soul has joined
  353. Flow has left
  354. winfried has joined
  355. dwd has left
  356. dwd has left
  357. dwd has left
  358. dwd has left
  359. draft9 has joined
  360. soul has left
  361. soul has joined
  362. draft9 has left
  363. draft9 has joined
  364. soul has left
  365. soul has joined
  366. goffi has left
  367. soul has left
  368. soul has joined
  369. Tobias has joined
  370. dwd has left
  371. dwd has left
  372. dwd has left
  373. dwd has left
  374. soul has left
  375. soul has joined
  376. dwd has left
  377. waqas has left
  378. Kev has joined
  379. Tobias has joined
  380. Tobias has joined
  381. foss81405971 has joined
  382. waqas has joined
  383. waqas has left
  384. waqas has joined
  385. Jake1984 has left
  386. Jake1984 has joined
  387. dwd has left
  388. foss81405971 has joined
  389. Jake1984 has left
  390. soul has left
  391. foss81405971 has joined
  392. soul has joined
  393. Lance has joined
  394. Jake1984 has joined
  395. dwd has left
  396. dwd has left
  397. intosi has joined
  398. dwd has left
  399. dwd has left
  400. Tobias has joined
  401. dwd has left
  402. Lance has joined
  403. Alex has left
  404. Tobias has joined
  405. foss81405971 has joined
  406. Alex has joined
  407. dwd has left
  408. tim@boese-ban.de has left
  409. Jake1984 has left
  410. dwd has left
  411. dwd has left
  412. Tobias has joined
  413. goffi has joined
  414. dwd has joined
  415. Tobias has left
  416. moparisthebest has left
  417. Tobias has joined
  418. Lance has joined
  419. Lance has joined
  420. SamWhited has left
  421. tim@boese-ban.de has joined
  422. tim@boese-ban.de has joined
  423. dwd has left
  424. dwd has left
  425. Ashley Ward has left
  426. intosi has joined
  427. foss81405971 has joined
  428. tim@boese-ban.de has left
  429. tim@boese-ban.de has joined
  430. daniel has left
  431. daniel has joined
  432. boothj5 has joined
  433. boothj5 has left
  434. andy has joined
  435. foss81405971 has joined
  436. narcode has left