shepherd, fibers, and signals (asyncs)
dear Guix, context: Shepherd stops responding during "guix system reconfigure" https://issues.guix.gnu.org/67538 https://issues.guix.gnu.org/65178 https://issues.guix.gnu.org/67230 i've added a ton of logging and asserts in my fork: https://codeberg.org/attila-lendvai-patches/shepherd which resulted in this report: https://github.com/wingo/fibers/issues/29#issuecomment-1858319291 to which @emixa-d kindly responded: https://github.com/wingo/fibers/issues/29#issuecomment-1858497720 which essentially identifies the following: -- posix signal handlers are async, and shepherd uses the fibers API from inside signal handlers, specifically in at least handle-SIGCHLD. this violates the fibers API, and most probably leads to the root cause of the reconfigure hang: a match-error flying out from service-controller due to losing the value of the parameter called (current-process-monitor), which then makes that fiber exit. i have little experience with posix signal handlers, so i probably won't come up with a fix for this, or at least not without someone's bird's eye view guidance. maybe the solution could be something like packaging up posix signals and delivering them to the fibers universe by some form of polling of an atomic variable? or is there some signal-safe semaphore facility in guile that could be used in accordance with the fibers API? -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Virtue is never left to stand alone. He who has it will have neighbors.” — Confucius (551–479 BC)
Re: bug#67790: New signing key
On Fri, Dec 15, 2023 at 06:06:26AM +, John Kehayias wrote: > I suppose I should have been more specific than "something bad" :) I > merely meant this wasn't an actual security issue of losing control of > a private key, but merely moving to a new one for other reasons. The old key "expired" last summer. I had been faking the date for months to work around that. I did not feel motivated to change the expiration date or to remove the expiration date either :) It was easier to make a new key.
Re: shepherd: hardening error handling
while i found this bug: https://issues.guix.gnu.org/67839 i was reading the discussion under its probable root cause: https://github.com/wingo/fibers/issues/29 and it suggests that Guile before 3.0.5 had important bugs WRT fluids, which are relied upon in shepherd. maybe Guile 2.2 can not be used reliably even for current Shepherd? -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “It is only when compassion is present that people allow themselves to see the truth. […] Compassion is a kind of healing agent that helps us tolerate the hurt of seeing the truth.” — A.H. Almaas (1944–), 'Elements of the Real in Man (Diamond Heart, Book 1)'
Re: xwayland security updates, to mesa- or core-updates or ?
On Thursday, December 14th, 2023 at 10:21 PM, John Kehayias 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.) > > Where is the most efficient branch for this, that could take these > rebuilds to be merged to master soon (whatever soon is for a scope of > something like 22k affected packages)? > > I was thinking to put that update and mesa, since it had a new stable > release after the current one never got updates, on mesa-updates and > merge once builds are done assuming no issues. Again, the potential > sore spot is xorgproto I would say. I could see about any other > pending/urgent related changes, but I'm not aware of any off the top > of my head and want to let this move quickly. I also don't want to > jump the queue sending other branches to rebuild everything again. This doesn't seem unreasonable to me, for picking up both the new mesa release and the latest xwayland security fixes. > I'll test things locally in the meantime, but please chime in. If I > don't hear anything too urgent I'll update the mesa-updates branch to > start builds at least. I've also cc'ed some names I think will be > knowledgeable about some current branches. > > And thanks to Kaelyn (also cc'ed) for the pending xwayland patches! You're welcome! I've been working on updating my patch set to xwayland 23.2.3, but it's been taking a while to build the update because most of the dependency stack on core-updates apparently needed rebuilding locally (presumably from a lack of recent substitutes unrelated to the xorgproto-triggered rebuilds, but that's based on my computer churning away at the build for the past day or so, and not having checked guix weather yet--I even ran into an issue with coreutils-minimal failing a test when /tmp was a btrfs partition, that I got past by mounting a tmpfs on /tmp). Cheers, Kaelyn > > Thanks! > John
