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


  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


  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


  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


  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


  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


  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


  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