15:39:13 anyone wants to have fun with porting?:) https://cgit.freebsd.org/src/commit/?id=2ed9833791f28e14843ac813f90cb030e45948dc 15:54:11 i kinda doubt that porting this is in any significant way easier or quicker than implementing this on our own when we need it :) 15:57:09 ISTR that intel hadn't released all of the specs for TB/USB4 (but could easily be remembering wrong)... so could be helpful from that perspective 15:58:03 There is a USB4 host controller doc, but it does want some more info. 16:12:58 Woodstock no argument there:) 17:35:56 Any distro-runners in the audience? If I've not pinged you already, check your openssl status. Even 3.0.x got bumped. 17:50:48 Even 1.0.2 got bumped for those of us paying for support for ancient releases (hello S10!) 17:51:16 though one of the 3 bugs in today's updates only applies to 64-bit ARM 18:10:36 alanc: _only_ is it? 18:10:39 harrumph 18:11:59 when you write custom assembly for crypto algorithms, you end up with platform-specific CVEs 18:14:33 that one is also in one of the algorithms from the Chinese government that not everyone enables: https://openssl-library.org/news/vulnerabilities/#CVE-2025-9231 18:20:15 alanc: 18:20:29 alanc: I love the SM* ones because I had to google what they were, and I'm still not sure if anyone would wat them 18:21:03 I even asked a friend who had crypto as a special interest, and they said "What?" 18:22:28 and people who care about certifications from other governments, like FIPS in the US, are usually required to disable them 18:35:26 danmcd: are the details still embargoed? 18:35:43 I don't think so. I found out about it in the clear. 18:36:01 @tsoome sent me this: https://cgit.freebsd.org/src/commit/?id=4d6fd774b5b3161314805f4dc6ba260ef977f583 18:49:50 freebsd put out the advisory this morning 18:49:57 with patches, etc. 18:50:06 which in't to say it's not embargoed, but freebsd are usually well behaved 18:50:08 unlike some 19:00:49 gordon tetlow is a man of good manners. 19:18:14 https://github.com/openssl/openssl/releases/tag/openssl-3.5.4 19:44:47 just to ask... in sd.c, there's a number of things that will dispatch things to sd_tq w/ the sd_lun as it's argument... I don't see any obvious mechanism that prevents sddetach() from either waiting for failing while a lun still has outstanding tasks 19:45:08 but i'm wondering if there is in fact one (or at least something that's intended to effectively do that) 19:45:40 (i have a panic where sd_target_change_task is running on a LUN that was detached (so basically use after free) 19:46:05 but i didn't see anything for other instances there taskq_dispatch is called 19:47:06 err where 20:19:47 richlowe: today was the planned end-of-embargo, advisory is published at https://openssl-library.org/news/secadv/20250930.txt 20:48:09 (I suppose that was more correctly for jbk who asked if it was still embargoed) 21:42:24 thanks 21:43:00 i wanted to pass it along if it was public