XSF Discussion - 2018-12-31


  1. vanitasvitae

    I think I'm on a tagged version

  2. vanitasvitae

    Have to upgrade soon anyways ;D

  3. lovetox

    hm one moment

  4. lovetox

    what could also be is that the xml lib of dino prints this wrong

  5. lovetox

    but i guess less likely as it would have to happen with all stanzas then

  6. lovetox

    really weird bug

  7. efrit has left

  8. labdsf has left

  9. labdsf has joined

  10. edhelas has left

  11. edhelas has joined

  12. oli has joined

  13. oli has joined

  14. lnj has left

  15. thorsten has left

  16. UsL has left

  17. thorsten has joined

  18. UsL has joined

  19. oli has joined

  20. oli has joined

  21. Neustradamus

    It is possible to add new SCRAM in next XMPP Compliance Suites?

  22. lovetox has left

  23. efrit has joined

  24. waqas has left

  25. waqas has joined

  26. oli has left

  27. oli has left

  28. oli has joined

  29. waqas has left

  30. waqas has joined

  31. lumi has left

  32. waqas has left

  33. waqas has joined

  34. waqas has left

  35. waqas has joined

  36. waqas has left

  37. waqas has joined

  38. waqas has left

  39. waqas has joined

  40. dos has left

  41. pep. has left

  42. waqas has left

  43. waqas has joined

  44. waqas has left

  45. waqas has joined

  46. waqas has left

  47. waqas has joined

  48. waqas has left

  49. waqas has joined

  50. waqas has left

  51. waqas has joined

  52. lnj has left

  53. waqas has left

  54. waqas has joined

  55. waqas has left

  56. oli has joined

  57. lnj has left

  58. vanitasvitae has left

  59. lnj has joined

  60. Zash has left

  61. lnj has left

  62. ThibG has left

  63. ThibG has joined

  64. efrit has left

  65. edhelas has left

  66. alacer has joined

  67. moparisthebest has left

  68. Tobias has joined

  69. Tobias has joined

  70. MattJ has left

  71. moparisthebest has left

  72. ThibG has left

  73. ThibG has joined

  74. chunk has left

  75. chunk has joined

  76. ThibG has left

  77. ThibG has joined

  78. moparisthebest has joined

  79. moparisthebest has left

  80. Yagiza has joined

  81. moparisthebest has joined

  82. moparisthebest has left

  83. moparisthebest has left

  84. moparisthebest has left

  85. moparisthebest has left

  86. moparisthebest has joined

  87. Nekit has joined

  88. moparisthebest has joined

  89. Zash has left

  90. moparisthebest has left

  91. moparisthebest has joined

  92. moparisthebest has joined

  93. moparisthebest has left

  94. moparisthebest has left

  95. erkanfiles has left

  96. Nekit has left

  97. Nekit has joined

  98. chunk has left

  99. chunk has joined

  100. ThibG has joined

  101. ThibG has joined

  102. Yagiza has left

  103. sezuan has left

  104. waqas has joined

  105. alacer has left

  106. moparisthebest has joined

  107. lorddavidiii has joined

  108. frainz has left

  109. frainz has joined

  110. l has joined

  111. neshtaxmpp has left

  112. neshtaxmpp has left

  113. lorddavidiii has left

  114. lorddavidiii has joined

  115. oli has joined

  116. oli has left

  117. oli has left

  118. oli has joined

  119. lorddavidiii has left

  120. jjrh has left

  121. waqas has left

  122. Seve has left

  123. lorddavidiii has joined

  124. jjrh has left

  125. waqas has joined

  126. mrDoctorWho has joined

  127. oli has left

  128. oli has joined

  129. lovetox has joined

  130. alacer has joined

  131. genofire has left

  132. genofire has joined

  133. Wiktor

    > I thought "xmlns='urn:xmpp:bob'" would be illegal. Xml namespaces are URIs but practically any XML lib treats them as strings anyway (no validation). In your case the namespace is URN, colons are frequent in URNs :) (check out Wikipedia)

  134. moparisthebest has joined

  135. moparisthebest has joined

  136. waqas has left

  137. edhelas has joined

  138. alacer has left

  139. alacer has joined

  140. Yagiza has joined

  141. edhelas has left

  142. edhelas has joined

  143. waqas has joined

  144. alacer has left

  145. !xsf_Martin has joined

  146. edhelas has left

  147. edhelas has joined

  148. !xsf_Martin has left

  149. !xsf_Martin has joined

  150. !xsf_Martin has left

  151. edhelas has left

  152. edhelas has joined

  153. lskdjf has joined

  154. chunk has left

  155. marc_ has joined

  156. alacer has joined

  157. Yagiza has left

  158. daniel has joined

  159. waqas has left

  160. l has left

  161. l has joined

  162. Fahrgast has left

  163. Fahrgast has joined

  164. Fahrgast has left

  165. l has left

  166. l has joined

  167. vaulor has joined

  168. marc_ has left

  169. jonas’

    huh

  170. jonas’

    vanitasvitae, that bug sounds familiar

  171. jonas’

    daniel, see above, I think you had the same thing the other day?

  172. Nekit has left

  173. Nekit has joined

  174. jonas’

    vanitasvitae, what you’re seeing there sounds very much like what daniel had in https://github.com/siacs/Conversations/issues/3315

  175. jonas’

    there seems to be some ejabberd bug there

  176. vanitasvitae

    jonas’: thanks for the link

  177. jonas’

    Neustradamus, new SCRAM? what are you talking about?

  178. Guus has left

  179. efrit has joined

  180. vinx55 has joined

  181. l has joined

  182. l has joined

  183. l has joined

  184. lovetox

    SCRAM-256

  185. jonas’

    are the weakened security properties of SHA-1 relevant for SCRAM?

  186. Zash

    Nope

  187. jonas’

    then I don’t think it’s worth the trouble

  188. Zash

    Not that I know of at least

  189. Zash

    IIRC even HMAC-SHA1 is fine for things that HMACs are appropriate for

  190. lskdjf has joined

  191. Zash

    So yeah, combined with that you can't convert the hashes, it's not really worth it

  192. lovetox

    why was it then specified?

  193. jonas’

    for new deployments probably

  194. Zash

    Hm?

  195. lovetox

    but why if it doesnt increase security

  196. jonas’

    but in existing deployments, migrating the SCRAM version is a PITA -- you need a password change to achieve that

  197. jonas’

    safe is better than sorry?

  198. lovetox

    hm not really convincing ..

  199. Zash

    Why use modern crypto?

  200. lovetox

    This document registers the SASL mechanisms SCRAM-SHA-256 and SCRAM- SHA-256-PLUS. SHA-256 has stronger security properties than SHA-1, and it is expected that SCRAM mechanisms based on it will have greater predicted longevity than the SCRAM mechanisms based on SHA-1.

  201. lovetox

    seems to be it does play indeed a role and is relevant

  202. Zash

    > SHA-256 has stronger security properties than SHA-1, This is true.

  203. Zash

    But whether that matters for how they are used in SCRAM is something different

  204. lovetox

    does not make much sense to specify a hash with great seurity properties, if you dont need these properties at all

  205. pep.

    Just like ipv6 was specified in the past, and still not used in the present, maybe someday in the future..

  206. Zash

    The real question is why not just wait for SCRAM-SHA-3

  207. jonas’

    See [RFC4270] and [RFC6194] for reasons to move from SHA-1 to a strong security mechanism like SHA-256.

  208. jonas’

    hah

  209. Zash

    What do they say?

  210. jonas’

    TL;DR (yet)

  211. Zash

    Attacks on Cryptographic Hashes in Internet Protocols Ctrl-F "HMAC" - 0 matches

  212. jonas’

    3.3. HMAC-SHA-1 As of today, there is no indication that attacks on SHA-1 can be extended to HMAC-SHA-1.

  213. Zash

    lovetox: it's an improvement, but relatively small improvement.

  214. lovetox

    yeah probably :)

  215. jonas’

    I’m composing a question on crypto.stackexchange about this

  216. Zash

    Remember that the state of the art before SCRAM was DIGEST-MD5 and storing plain text passwords.

  217. Zash

    DIGEST-MD5 -> SCRAM is a huge improvement all around

  218. Zash

    SCRAM-SHA-1 -> SCRAM-SHA-256 is a small improvement that would cost a lot for existing deployments

  219. mightyBroccoli has joined

  220. Zash

    Converting plain text passwords to hashed form is easy. Converting hashed form to a different hashed form is Hard

  221. alacer has left

  222. lovetox

    im not arguing for or against this new standard, it just was a contradiction to me that the ietf goes through the motion of making a new standard with a more expensive hash method, if it has no effect at all on security

  223. lovetox

    maybe it was "better save than sorry" but bringing such a standard to live seems to me a bit of work that nobody would do just because he feels like 256 is a prettier number

  224. Zash

    not no effect, it's better. but not enough better to outweight the cost of switching

  225. lovetox

    yeah you are probably right on that

  226. vinx55 has left

  227. lovetox

    it is though really easy to implement if you already have a SHA1 impl

  228. Zash

    depends

  229. Zash

    In theory it's just replacing the hash function

  230. Zash

    So if you have code that makes that easy then it's easy

  231. jonas’

    there we go https://crypto.stackexchange.com/q/66195/16902

  232. rion has joined

  233. lovetox

    great writeup :)

  234. Zash

    There's one spot in SCRAM where it uses bare SHA-1 tho, for converting the ClientKey into StoredKey

  235. Zash

    StoredKey := H(ClientKey)

  236. jonas’

    oh, I missed that

  237. jonas’

    but storedkey is never transferred and only used as key in the hmac

  238. Zash

    But ClientKey is HMAC output and not combined with anything

  239. rion

    Does any XEP describe disco#info get requests with non-empty query element? Just found this in iris code w/o any reference to specs.

  240. oli has left

  241. oli has joined

  242. Zash

    rion: I think there's something like disco-subscriptions somewhere, but I'm not sure if there's a XEP

  243. oli has left

  244. rion

    I see xep-0230 but there is disco#items

  245. rion

    Ok, thanks Zash. I'll put it under #if 0 for now

  246. alacer has joined

  247. matlag has left

  248. lumi has joined

  249. lnj has joined

  250. UsL has left

  251. UsL has joined

  252. oli

    didn't we had the sha-256 discussion before? or was it at ejabberd?

  253. Zash has left

  254. daniel has left

  255. daniel has joined

  256. l has left

  257. chunk has left

  258. !xsf_Martin has joined

  259. chunk has joined

  260. MattJ has joined

  261. lskdjf has joined

  262. half-shot_ has joined

  263. rion has left

  264. Kev has joined

  265. ThibG has joined

  266. ThibG has joined

  267. Ge0rG has left

  268. !xsf_Martin has left

  269. !xsf_Martin has joined

  270. l has joined

  271. Ge0rG

    rion: IIRC it is also used in MIX to distinguish between MUC protocol and MIX protocol, but maybe it was disco#items as well

  272. jonas’

    Ge0rG, no

  273. jonas’

    MIX uses the node for that

  274. jonas’

    *used

  275. jonas’

    you confuse that with the roster query

  276. jonas’

    so I’ve been thinking about MUC self ping. thinking about it, using a silent, non-archived <message/> might actually be the most traffic-efficient way to do it.

  277. Ge0rG

    jonas’: wasn't there disco#items on the MIX room JID to get a list of all nodes?

  278. Ge0rG

    jonas’: a message to whom?

  279. jonas’

    Ge0rG, through the MUC

  280. jonas’

    so to everyone, essentially

  281. Ge0rG

    jonas’: to the MUC?

  282. Ge0rG

    How's that more traffic efficient?

  283. jonas’

    it is a ping for everyone. only one needs to send it, everyone else also learns that they themselves are still connected.

  284. jonas’

    it is a ping for everyone. only one client needs to send it, everyone else also learns that they themselves are still connected.

  285. jonas’

    so it saves sending the ping for everyone but one client.

  286. lorddavidiii has left

  287. jonas’

    Ge0rG, MIX uses @node='mix' to qualify that; no need for child elements on the <{…disco#items}query/>

  288. jonas’

    back to muc self-ping: if everyone implements it with "after N+random(-1, 1) minutes of no message received through the MUC, send a ping <message/>; if after N+M (M>2) minutes no message was received, conclude that we’re disconnected", the one with the lowest random() output will be the one who sends the pings, and everyone else silently benefits from it.

  289. jonas’

    does that make sense?

  290. lovetox

    sounds weird, but somehow i like it

  291. lovetox

    wonder if this has any downsides

  292. Ge0rG

    jonas’: provided that we can normalize N. Also there might be minor inefficiency when multiple clients roll the same number. But I fear there will be clients making a short cut and not checking for the last incoming message, just sending anyway

  293. jonas’

    potential downsides: if the MUC eats the <message/> (because it’s bodyless or whatever), it breaks. if the MUC archives the message, it pollutes the archive massively.

  294. jonas’

    Ge0rG, slap those clients then.

  295. lovetox

    there are store hints for exactly that usecase

  296. lovetox

    and bodyless is no problem in any muc

  297. jonas’

    lovetox, it may be with biboumi

  298. jonas’

    but I think even biboumi simply reflects those on the XMPP side and drops them on the IRC side

  299. Ge0rG

    jonas’: but how is it better than the 0410 proposal?

  300. jonas’

    Ge0rG, 1. it requires no server-side implementation; 2. in my specific implementation, it is easier to keep multiple <messages/> in flight and have a catch-all handler for the replies than with IQs (because IQs are request-response, and each in-flight IQ needs an entry in the response handler table -> memory use); 3. what happens when you send a message to a MUC you’re not joined to is more well-defined than IQ, 4. no race conditions with nickname changes or whatever

  301. lovetox

    the self ping has on its positive side that its easier to implement

  302. Ge0rG

    Also it might make sense to have different N for mobile vs desktop clients, and your suggestion ends up with `min(N) ` over all participants

  303. jonas’

    (I don’t find it easier to implement, see (2) above)

  304. Ge0rG

    jonas’: some MUCs allow messages from non participants. What now?

  305. jonas’

    Ge0rG, that’s a true point. For what it’s worth, a MUC implementation could still not forward the message to all participants but only reflect it to the sending client, if we find that it’s a battery hog.

  306. jonas’

    Ge0rG, eh, why :D

  307. jonas’

    I think with that, my proposal falls down the drain

  308. jonas’

    good that we talked about it though

  309. Ge0rG

    jonas’: don't know why. Also some bridge implementations (looking at you, biboumi) will accept a message from a non joined resource of a joined user

  310. lovetox

    it is jonas in my opinion, one is just send an iq and wait for response, the other is, check messages for something then start a timer that i have to reset on the next message, and deal with over multiple scenarios like disconnect etc

  311. jonas’

    lovetox, how long do you wait for a response for the IQ?

  312. lovetox

    lots of space to have bugs

  313. jonas’

    no, you don’t need ot check messages for something

  314. jonas’

    *every* message you receive lets you know you’re joined

  315. jonas’

    you need that timer anyways if you want to implement self-ping efficiently.

  316. jonas’

    you don’t need to send a ping when you just received a message from the MUC.

  317. lovetox

    hm yeah

  318. lovetox

    seems similar

  319. jonas’

    (hint: the same thing goes for your main xml stream ;-))

  320. jonas’

    problem with the IQ ping is the timeout

  321. jonas’

    using a long timeout has the downside that if the MUC was temporarily blackholed, you have to wait very long until you can resync

  322. jonas’

    using a short timeout has the downside that you won’t resync automatically in a high-latency situation.

  323. ThibG has joined

  324. jonas’

    using multiple interleaved pings with long timeout has the memory cost issue

  325. Ge0rG

    jonas’: on timeout you should just mark the MUC as not responding, and schedule a new ping

  326. jonas’

    Ge0rG, that’s obvious

  327. Ge0rG

    No need to have multiple interleaving pings

  328. jonas’

    which timeout should I use for the ping then?

  329. lorddavidiii has joined

  330. lovetox

    i dont know what you are talking about memory, a timeout, compared to a full fletched gui client Oo

  331. jonas’

    lovetox, aioxmpp might very well be used for a bot which runs ~forever and if it loses connectivity which isn’t restored, I don’t want it to turn into a memory hog

  332. jonas’

    I don’t like ever-growing tables.

  333. jonas’

    (and by "loses connectivity" I mean "a MUC in which it is joined becomes blackholed")

  334. Ge0rG

    jonas’: have a ping timeout of 60s and a ping interval of 10m after the last activity

  335. half-shot_ has left

  336. jonas’

    Ge0rG, so if my link has a latency higher than 60s, I don’t ever resync to the MUC; it is "not responding" forever.

  337. Ge0rG

    jonas’: correct.

  338. jonas’

    meh.

  339. Ge0rG

    Make it configurable for the military satellite use case

  340. jonas’

    me not likey

  341. jonas’

    lovetox, by the way, XEP-0410 even tells you to not self-ping unless the MUC is silent: > After an adequate amount of silence from a given MUC (e.g. 15 minutes), or from all MUCs from a given service domain, a client should initiate a self-ping.

  342. lovetox

    i just dont like timers, i pass a callback to some timer api, and later it comes back and bites me, either because the object for the callback is not there anymore, or because i forgot to cancel the timer if any of X events happen

  343. Ge0rG

    Yeah

  344. jonas’

    which is why I wrapped this specific logic (which I already needed for the main xml stream anyways) in a class which takes care of handling the timer

  345. jonas’

    I just should "nevermind, I got data!" at that class from time to time, and when I don’t do that, it’ll tell me "hey, no data for X time, wanna do something about that?"

  346. jonas’

    I just shout "nevermind, I got data!" at that class from time to time, and when I don’t do that, it’ll tell me "hey, no data for X time, wanna do something about that?"

  347. Zash

    Prosody has something like that too.

  348. jonas’

    so I can be reasonably confident that when that event triggers, something is wrong

  349. lovetox

    you just described a callback...

  350. lovetox

    i think we all know how this works

  351. jonas’

    lovetox, typical callback APIs are a bit more convoluted than that though

  352. jonas’

    (also, this has in fact two timers, a soft and a hard timeout)

  353. jonas’

    you normally need to store some handle and exchange that whenever you re-set the timer

  354. jonas’

    but that’s implementation details

  355. jonas’

    I’m just saying one can make this rather painless

  356. !xsf_Martin has left

  357. !xsf_Martin has joined

  358. lovetox

    its painless if you have not many events that need the timer to be deleted, like an xml stream, what is there, essentially disconnect() thats the only event where you stop the timer

  359. jonas’

    same goes for a MUC room. "leave" is the only thing where you stop the timer.

  360. lovetox

    think about chatstates, i have a inactive timer, it has to be reset whener the mouse moves over the window, if i switch the window, if i close the window, if i disconnect, etc this goes on and on

  361. lovetox

    but yeah, i see it depends on what you do with the timer

  362. lovetox

    :)

  363. thorsten has left

  364. marc_ has joined

  365. valo has joined

  366. valo has joined

  367. Yagiza has joined

  368. 404.city has joined

  369. jjrh has left

  370. vaulor has left

  371. vaulor has joined

  372. half-shot_ has joined

  373. chunk has left

  374. thorsten has joined

  375. tux has joined

  376. mimi89999 has joined

  377. half-shot_ has left

  378. lskdjf has joined

  379. lskdjf has left

  380. lskdjf has left

  381. genofire has left

  382. frainz has joined

  383. lskdjf has left

  384. lskdjf has left

  385. lskdjf has left

  386. lskdjf has left

  387. lskdjf has joined

  388. oli has left

  389. lskdjf has joined

  390. genofire has joined

  391. lskdjf has joined

  392. oli has left

  393. oli has left

  394. half-shot_ has joined

  395. half-shot_ has left

  396. half-shot_ has joined

  397. half-shot_ has left

  398. ta has left

  399. oli has left

  400. frainz has left

  401. oli has left

  402. frainz has joined

  403. genofire has left

  404. genofire has joined

  405. oli has joined

  406. lorddavidiii has left

  407. neshtaxmpp has joined

  408. moparisthebest has joined

  409. moparisthebest has joined

  410. genofire has left

  411. genofire has joined

  412. jjrh has left

  413. labdsf has left

  414. labdsf has joined

  415. genofire has left

  416. genofire has joined

  417. Zash has left

  418. Zash has left

  419. Zash has left

  420. lnj has left

  421. labdsf has left

  422. labdsf has joined

  423. mrDoctorWho has joined

  424. Yagiza has left

  425. Zash has left

  426. efrit has left

  427. genofire has left

  428. Guus has left

  429. jjrh has left

  430. jjrh has left

  431. Zash has left

  432. 404.city has left

  433. Yagiza has joined

  434. genofire has joined

  435. lnj has left

  436. Andrew Nenakhov has left

  437. Andrew Nenakhov has joined

  438. Andrew Nenakhov has left

  439. Andrew Nenakhov has joined

  440. oli has left

  441. lskdjf has left

  442. lovetox has left

  443. Neustradamus

    jonas’: https://tools.ietf.org/html/rfc7677 + https://tools.ietf.org/html/draft-ietf-mile-xmpp-grid-08

  444. lskdjf has left

  445. !xsf_Martin has left

  446. lskdjf has left

  447. lskdjf has left

  448. Marc Laporte has joined

  449. lnj has joined

  450. labdsf has left

  451. labdsf has joined

  452. labdsf has left

  453. labdsf has joined

  454. lnj has left

  455. Marc Laporte has left

  456. half-shot_ has joined

  457. moparisthebest has joined

  458. marc_ has left

  459. Steve Kille has left

  460. sezuan has left

  461. half-shot_ has left

  462. moparisthebest has joined

  463. Steve Kille has joined

  464. jjrh has left

  465. Maranda has left

  466. Maranda has joined

  467. jjrh has left

  468. jjrh has left

  469. Guus has left

  470. jjrh has left

  471. Neustradamus has left

  472. Neustradamus has joined

  473. Zash has left

  474. Zash has joined

  475. jjrh has left

  476. jjrh has left

  477. lnj has joined

  478. waqas has joined

  479. jjrh has left

  480. jjrh has left

  481. jjrh has left

  482. alacer has left

  483. UsL has left

  484. UsL has joined

  485. owl has joined

  486. pep. has left

  487. erkanfiles has joined

  488. erkanfiles has joined

  489. 404.city has joined

  490. igoose has left

  491. igoose has joined

  492. Nekit has left

  493. Nekit has joined

  494. alacer has joined

  495. marc_ has joined

  496. owl has left

  497. oli has left

  498. labdsf has left

  499. labdsf has joined

  500. Yagiza has left

  501. igoose has left

  502. igoose has joined

  503. lorddavidiii has joined

  504. marc_ has left

  505. jjrh has left

  506. jjrh has left

  507. 404.city has left

  508. waqas has left

  509. waqas has joined

  510. jjrh has left

  511. alacer has left

  512. neshtaxmpp has joined

  513. neshtaxmpp has left

  514. neshtaxmpp has left

  515. moparisthebest has joined

  516. neshtaxmpp has joined

  517. ThibG has left

  518. ThibG has joined

  519. lskdjf has left

  520. UsL has left

  521. UsL has joined

  522. mimi89999 has left

  523. lskdjf has left

  524. jjrh has left

  525. jjrh has left

  526. jjrh has left

  527. Nekit has joined

  528. Maranda has left

  529. oli has joined

  530. lskdjf has joined

  531. waqas has left

  532. waqas has joined

  533. oli has left

  534. oli has joined

  535. oli has left

  536. oli has joined

  537. oli has left

  538. oli has joined

  539. l has left

  540. APach has left

  541. oli has left

  542. oli has joined

  543. oli has left

  544. oli has joined

  545. oli has left

  546. oli has joined

  547. moparisthebest has joined

  548. oli has joined

  549. oli has joined

  550. oli has left

  551. oli has joined

  552. igoose has left

  553. oli has left

  554. oli has joined

  555. oli has left

  556. oli has joined

  557. lnj has left

  558. oli has left

  559. oli has joined

  560. oli has left

  561. oli has joined

  562. Maranda has joined

  563. thorsten has left

  564. igoose has joined

  565. oli has joined

  566. lorddavidiii has left

  567. oli has joined

  568. l has joined

  569. oli has left

  570. oli has joined

  571. oli has left

  572. oli has joined

  573. UsL has left

  574. UsL has joined

  575. vanitasvitae

    Happy new year!

  576. oli has left

  577. oli has joined

  578. pep.

    Happy public domain day

  579. jonas’

    happy new year’s from CET https://sotecware.net/images/dont-puush-me/WVeQE5W9eDNjekWpVcI5J0z5i6kPBYXRJTHfxKQ_DF0.png

  580. jonas’

    happy new year from CET https://sotecware.net/images/dont-puush-me/WVeQE5W9eDNjekWpVcI5J0z5i6kPBYXRJTHfxKQ_DF0.png

  581. oli has left

  582. oli has joined

  583. lskdjf has left

  584. MattJ has joined

  585. waqas

    pep.: I didn't realize that was a thing. Looks like "Yes! We Have No Bananas" is now in the public domain, https://www.youtube.com/watch?v=PDd8shcLvHI

  586. waqas

    There seems to be a list here: https://lifehacker.com/these-1923-copyrighted-works-enter-the-public-domain-in-1825241296

  587. lnj has joined

  588. Wiktor has left

  589. oli has left

  590. oli has joined

  591. moparisthebest has joined

  592. marc_ has joined

  593. oli has left

  594. oli has joined

  595. Seve

    Happy new year! :)

  596. oli has joined

  597. oli has joined

  598. l has left

  599. l has left

  600. l has left