2022-11-01 13:26:03 OpenSSL announcement archive is apparently under load 2022-11-01 13:28:18 haha 2022-11-01 14:27:33 :D 2022-11-01 16:24:30 https://mta.openssl.org/pipermail/openssl-announce/2022-November/000241.html 2022-11-01 16:24:59 This works better: https://www.openssl.org/news/cl30.txt 2022-11-02 12:00:36 new XSAs https://xenbits.xen.org/xsa/ 2022-11-02 12:00:41 but no new releases 2022-11-02 12:01:43 business as usual then eh 2022-11-02 12:05:45 seems to have become the usual business, yeah 2022-11-02 21:25:14 apparently they do point releases every four months ish 2022-11-03 02:32:03 !41001 !41002 2022-11-03 04:46:20 new CVE releases for sudo: https://nvd.nist.gov/vuln/detail/CVE-2022-43995 2022-11-03 04:46:49 patch available, but no new release yet: https://github.com/sudo-project/sudo/commit/bd209b9f16fcd1270c13db27ae3329c677d48050 2022-11-03 08:12:32 sudo fixed now 2022-11-03 08:12:34 thanks 2022-11-03 11:40:33 !41009 !41010 !41011 2022-11-08 02:04:50 hello to all 2022-11-09 22:53:44 so I've been pestering the xen project about their release policies again (something some of them hope will change in the future) 2022-11-09 22:54:20 but from what I've gathered, their stable branches should be very solid 2022-11-09 22:55:43 they push bug fixes, mostly security fixes, to the staging branches and then that will be picked up by CI that will do rigorous testing and, if tests pass, changes will go into the stable branch(es) 2022-11-09 22:57:44 so perhaps it's "fine", for now, to follow the tip of xen stable branches, although we'll sometimes have to add huge patch-files to our aports repo 2022-11-10 09:48:15 the only usual difference between 'git checkout' and 'tarballs' is having to run autoreconf and submodules 2022-11-10 09:48:24 looking at xen autoreconf is ran anyway and the modules are separate 2022-11-10 09:48:31 you could just clone a git commit if it works lol 2022-11-10 09:48:39 better than giant patch files 2022-11-10 09:48:54 dunno, doesn't sound like a terrible idea if the branches are 'that stable', but 2022-11-10 10:29:38 I tried fetching from their gitweb instead 2022-11-10 10:29:47 curl -L "https://xenbits.xen.org/gitweb/?p=xen.git;a=patches;h=e818f4f0dabf83a6138cd77d7464495fab7bfc16;hp=f6e26ce7d9317abc41130ead6dc2443a7e2dde00" -o main/xen/xen-stable-4.15-20221101.patch 2022-11-10 10:29:58 (for our 3.14-stable and 3.15-stable branches) 2022-11-10 10:30:20 but they seem to have a maximum number of patches in the patch view set to 16 2022-11-10 10:30:28 and this diff should be 124 patches 2022-11-10 10:31:28 583k 2022-11-10 12:19:39 so here are two things to do the same thing !41224 !41225 2022-11-10 12:19:49 two ways* 2022-11-10 12:23:19 I dislike the second one less 2022-11-10 12:36:54 those urls are probably not very stable 2022-11-10 12:36:55 hm 2022-11-10 12:45:49 wdym? 2022-11-10 12:46:53 wouldn't the only unexpected thing they could return be 404? 2022-11-10 12:48:35 no, the bottom of the patch has 2.30.2 2022-11-10 12:48:51 which is the git version that generated that 2022-11-10 12:49:04 ah... *sigh* 2022-11-10 12:49:10 and ancient 2022-11-10 12:49:17 funny 2022-11-10 12:49:35 gitlab ones just say 'GitLab', same thing for github 2022-11-10 12:49:42 gitlab though had some change elsewhere at some point 2022-11-10 12:49:47 as did github like a year or so ago 2022-11-10 12:49:51 but now they're mostly ok i guess 2022-11-10 12:50:16 the more annoying part is when both changed some compression header for autotarballs 2022-11-10 12:52:02 I guess the question is if they will update their release policy or their git server version first.. 2022-11-10 12:52:48 i mean there's a github mirror you can just fetch a commit from 2022-11-10 12:52:51 but people balk at that one a little 2022-11-10 12:53:24 yeah, I've thought of that too 2022-11-10 13:00:13 if I could persuade them to bump or remove the patchset limit, perhaps I could persuade them to set the version to something static 2022-11-10 13:01:58 too 2022-11-10 13:59:18 slt 2022-11-10 13:59:58 hi 2022-11-10 14:00:07 juba: hello 2022-11-10 14:00:26 .. 2022-11-15 19:28:43 Incoming! 2022-11-15 19:28:45 https://lists.gnu.org/archive/html/grub-devel/2022-11/msg00059.html 2022-11-15 19:28:57 whoosh 2022-11-15 19:29:16 Grub security fixes due shortly 2022-11-15 19:29:32 though sounds like them mainly are Secure Boot related 2022-11-16 07:31:15 i am not sure we can fix those 2022-11-16 07:31:52 i think other distros has like 100+ patches for grub 2022-11-16 07:31:58 would be better if they could tag a release 2022-11-16 10:19:46 ncopa: It was planned.. uh last month 2022-11-16 10:20:00 I've been bothering the maintainer about this for a while... 2022-11-16 10:58:46 thank you for doing so 2022-11-16 10:59:14 Foxboron: maybe i should help you bothering the maintainer....? 2022-11-16 11:00:18 The issue is that most major distros that look at the above CVEs as actual issues have their own grub forks at this point 2022-11-16 11:00:52 So when us non-Secure Boot distros point out the issue there isn't really any pressure to change this. And Daniel is still just one guy 2022-11-16 11:01:14 Nobody stepped up to help maintain a stable release of grub last year 2022-11-16 11:01:23 :-/ 2022-11-16 11:02:59 It's not a great situation :/ 2022-11-16 11:03:23 its a common problem in open source 2022-11-16 14:10:18 a GRUB 2.12 release is expected "soon": https://lists.gnu.org/archive/html/grub-devel/2022-10/msg00139.html 2022-11-16 14:12:13 however I don't believe all the necessary patches for LUKSv2 "FDE" support in Grub have yet been merged (despite support for this being an advertised GRUB 2.06 feature) 2022-11-18 01:57:02 so there was a release !41224 !41225 2022-11-30 20:31:01 Ugh, A release "Fixes 2 security issues", without mentioning what they are :/