Re: xwayland security updates, to mesa- or core-updates or ?

[Efraim Flashner <efraim@flashner.co.il>]

[-- Attachment #1: Type: text/plain, Size: 5333 bytes --]

On Fri, Dec 22, 2023 at 09:19:27AM +0200, Efraim Flashner wrote:
> On Thu, Dec 21, 2023 at 09:18:50PM +0000, John Kehayias wrote:
> > Hi all,
> > 
> > On Mon, Dec 18, 2023 at 12:57 AM, John Kehayias wrote:
> > 
> > > Hi Kaelyn and everyone,
> > >
> > > On Fri, Dec 15, 2023 at 05:25 PM, Kaelyn wrote:
> > >
> > >> On Thursday, December 14th, 2023 at 10:21 PM, John Kehayias
> > >> <john.kehayias@protonmail.com> wrote:
> > >>
> > >>>
> > >>> Hi Guix,
> > >>>
> > >>> In light of (more) CVEs in xwayland, see
> > >>> <https://lists.x.org/archives/xorg-announce/2023-December/003435.html>,
> > >>>
> > >>> with already pending security updates, see
> > >>> <https://issues.guix.gnu.org/67136>, I would like to prioritize
> > >>>
> > >>> getting that fixed in master. The tricky thing is that, according to
> > >>> 67136, the xwayland update needs newer xorgproto, which corresponds to
> > >>> many rebuilds. (The related CVEs in xorg-server have been pushed
> > >>> already as effectively minor version bumps.)
> > >>>
> > 
> > I also updated curl as it was going to be rebuilt and had a new
> > version out (with some security fixes). I hadn't grafted it on master
> > but we could do that if the mesa-updates branch isn't merged to master
> > first.
> > 
> > [snip]
> > 
> > >
> > > I've pushed 3 patches (mesa, xorgproto, xorg-server-xwayland) to
> > > mesa-updates after merging in master. The farm is building away.
> > >
> > 
> > I also had to skip a failing test (unknown reasons) of gtk with these
> > updates.
> > 
> > Finally, I also enabled the zink driver in Mesa (zink is for OpenGL on
> > Vulkan). I remember someone asking about it on #guix recently as well,
> > and we should have it enabled in general, to support devices which may
> > not be able to use OpenGL without it.
> > 
> > > The request for merging is at <https://issues.guix.gnu.org/67875> with
> > > some details. In short, running into some issues with builds "failing"
> > > because they just die or "missing derivation" errors. I'm restarting
> > > what I see that seems higher impact, but is there anyway to restart
> > > all the failed builds or ones with missing dependencies?
> > >
> > 
> > This is still true though I've tried to manually restart lots of
> > builds on x86_64 and i686, which has removed many of the failures. Any
> > idea what is happening to cause this more recently?
> > 
> > [snip]
> > 
> > > Thanks! I saw you had posted the latest version and that's what I
> > > included. On x86_64-linux at least everything has built fine for
> > > those, but the larger world remains to be seen.
> > >
> > > Would still like confirmation from other branches about what they want
> > > to do, but we have some time while things build. And builds get
> > > restarted.
> > >
> > 
> > I haven't seen QA process this branch, so I'm just going with what I
> > see on Berlin. From the branches overview it shows about 61% last I
> > saw, compared to 72% for master. Unfortunately, non x86 architectures
> > are usually better covered by Bordeaux, but I don't know where to get
> > a sense of that coverage. For what it is worth, Efraim has manually
> > built xorgproto and mesa at least on powerpc64le, riscv64, without
> > issues.
> 
> I had berlin build for powerpc64le and that went without any problems.
> Locally I built for riscv64 and powerpc and those both built fine.  I
> ran into an issue locally with curl on aarch64 and test 1477(?) which is
> weird since it's supposed to be skipped but I'm sending it through
> again.  Haven't started armhf yet.
> 
> > Coverage on x86_64 and i686 seems good from what I can tell. I also
> > don't think there are any other branches ready to merge, and would
> > like to give them time to rebuild once these changes hit.
> > 
> > Any thoughts on when to merge?
> > 
> > Thanks everyone!
> > John

I've been having trouble with curl on aarch64 again. Looking at this
snippet from the build log:

test 1477...[Verify that error codes in headers and libcurl-errors.3 are in sync]

 1477: stdout FAILED:
--- log/1/check-expected        2023-12-22 10:53:51.658667071 +0000
+++ log/1/check-generated       2023-12-22 10:53:51.658667071 +0000
@@ -1 +0,0 @@
-Result[LF]

 - abort tests
test 1475...[-f and 416 with Content-Range: */size]
--pd---e--- OK (1247 out of 1472, remaining: 00:45, took 5.310s, duration: 04:11)
test 1474...[HTTP PUT with Expect: 100-continue and 417 response during upload]
--pd---e--- OK (1246 out of 1472, remaining: 00:48, took 22.794s, duration: 04:29)
Warning: test1474 result is ignored, but passed!
...
TESTFAIL: These test cases failed: 1477

It looks like 1474 is passing locally and the ~1474 is telling the test
suite to ignore the result.  If that's how ~<number> is interpreted then
I'd suggest that 1477 is failing hard enough that it's taking the test
suite with it, not merely ignoring the result.  I'll continue poking it
but right now I'm starting to like the hurd plan of disabling the test
instead of merely ignoring the result.

-- 
Efraim Flashner   <efraim@flashner.co.il>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]