-
tsoomeanyone wants to have fun with porting?:) cgit.freebsd.org/src/commit/?id=2ed…33791f28e14843ac813f90cb030e45948dc
-
Woodstocki kinda doubt that porting this is in any significant way easier or quicker than implementing this on our own when we need it :)
-
jbkISTR 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
-
rmustaccThere is a USB4 host controller doc, but it does want some more info.
-
tsoomeWoodstock no argument there:)
-
danmcdAny distro-runners in the audience? If I've not pinged you already, check your openssl status. Even 3.0.x got bumped.
-
alancEven 1.0.2 got bumped for those of us paying for support for ancient releases (hello S10!)
-
alancthough one of the 3 bugs in today's updates only applies to 64-bit ARM
-
richlowealanc: _only_ is it?
-
richloweharrumph
-
alancwhen you write custom assembly for crypto algorithms, you end up with platform-specific CVEs
-
alancthat one is also in one of the algorithms from the Chinese government that not everyone enables: openssl-library.org/news/vulnerabilities/#CVE-2025-9231
-
richlowealanc:
-
richlowealanc: I love the SM* ones because I had to google what they were, and I'm still not sure if anyone would wat them
-
richloweI even asked a friend who had crypto as a special interest, and they said "What?"
-
alancand people who care about certifications from other governments, like FIPS in the US, are usually required to disable them
-
jbkdanmcd: are the details still embargoed?
-
danmcdI don't think so. I found out about it in the clear.
-
danmcd@tsoome sent me this: cgit.freebsd.org/src/commit/?id=4d6…774b5b3161314805f4dc6ba260ef977f583
-
richlowefreebsd put out the advisory this morning
-
richlowewith patches, etc.
-
richlowewhich in't to say it's not embargoed, but freebsd are usually well behaved
-
richloweunlike some
-
otisgordon tetlow is a man of good manners.
-
nomad
-
jbkjust 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
-
jbkbut i'm wondering if there is in fact one (or at least something that's intended to effectively do that)
-
jbk(i have a panic where sd_target_change_task is running on a LUN that was detached (so basically use after free)
-
jbkbut i didn't see anything for other instances there taskq_dispatch is called
-
jbkerr where
-
alancrichlowe: today was the planned end-of-embargo, advisory is published at openssl-library.org/news/secadv/20250930.txt
-
alanc(I suppose that was more correctly for jbk who asked if it was still embargoed)
-
jbkthanks
-
jbki wanted to pass it along if it was public